I noticed earlier today that, by default, Panda (under Windows, at least) sets the processor affinity of its process such that it will only execute on the first CPU (or core) of a multi-CPU (or multi-core) machine.
A bit of poking around and I found the “lock-to-one-cpu” configuration directive that controls this behaviour. The documentation indicates that this is due to QueryPerformanceCounter calls behaving incorrectly when a process is spread across cores.
Although I imagine that Panda’s performance won’t benefit greatly/at all from being able to span cores (at least, perhaps, until some of the threading-related stuff in CVS gets switched on), I do run multiple instances of Panda on one machine during development, and having them not all sit on the same core would be a benefit.
To that end, I toggled the configuration option and so far I haven’t seen anything break. But to be fair, I haven’t tested all that much. Also, a Google search turned up some rumblings that the hotfix at support.microsoft.com/?id=896256 might(?) fix the underlying issue, and a quick check indicates that I do indeed have that hotfix installed.
Basically, wondering if anyone can give more details on this switch and excatly what it will/could break to have it turned off. Are there any gotchas I should be on the lookout for?
The fundamental nature of this problem is that globalClock.getRealTime() will return consecutive values that are not necessarily increasing. The clock seems to go backwards and forwards in time. The symptom is most obvious when watching animations play; animations will jump erratically backwards and forwards in their cycles.
The actual cause is that the low-level Windows QueryPerformanceCounter() call might sample a different timer on each CPU that the process might be running on. When the OS decides to migrate the process to another CPU, suddenly the timer jumps wildly.
This problem only affected certain versions of Windows running on certain dual-core motherboards. I believe the hotfix you linked does solve the problem reliably. You would notice if bad things were happening with the clock; if you can disable this hack and Panda seems to be running normally, you should be good.
I’ve been running with this switched all day and haven’t seen any global clock weirdness, so I think it’s safe to say that it works fine on my machine.
I think I’ll leave this at default on release versions of our code though, since I don’t trust that other people will have the hotfix installed.
Turns out there’s a new config variable that one of our programmers added, which I didn’t learn about until more recently.
client-cpu-affinity n
where n is the CPU index you wish the process to be locked to, or -1 to not lock to any particular CPU. There’s also:
client-cpu-affinity-mask m
where m is the bitmask of CPU’s you wish the process to be locked to, or -1 to not lock to any particular CPU. This overrides client-cpu-affinity if it is set.
Might either of these be set in your particular case?