So I've been running a Transfusion server for a while, and I've been plagued constantly by high CPU load. Sometimes the load literally reaches 100% and players complain, why it lag. Finally I know why.

Before I concluded that there's a regression in the Transfusion QC, I noticed two ways the DarkPlaces engine wastes processor time.

First, it checks for console input on every main loop iteration. This is a tremendous waste for such an unimportant task. Checking once per second is sufficient, since input is buffered between each read.

Second, it hogs the CPU if it doesn't sleep at regular intervals. DarkPlaces spends much of its time sleeping or checking the time to schedule more sleeping, and the sleep schedule is very sensitive to timer accuracy. Two sources of time are supported on Windows: timeGetTime and QueryPerformanceCounter. Neither of these works well for me, as timeGetTime is inaccurate, QueryPerformanceCounter has a ridiculous amount of overhead, and only the time stamp counter in the CPU is both fast and accurate. So I patched DarkPlaces to use the TSC.

I'm just mentioning this stuff in case someone finds it useful. None of the changes I made to the QC in 2013 were merged into the Transfusion repository, and I hope termit found the Transfusion HUD patch because it was never merged into the DarkPlaces repository either.

Again, it's probably a case of me not looking in the right places, but do you report these engine patches over at icculus? or do you have a thread at one of the multiplayer game forums that use darkplaces? A patch that cuts cpu cycles is surely of interest to all involved in maintaining dp. If tfn isn't the main site you link your work to, I do apologize un advance.

Haven't mentioned it on any other forum since the main problem I was having was Transfusion chewing the CPU, and most of the load was caused by a bug that's specific to Transfusion.

The TSC patch is of interest only if someone insists on running DarkPlaces-WinQuake on a Windows server with an unreliable interrupt timer, a broken performance counter, and an invariant time stamp counter. So basically, Amazon EC2 or similar virtualization on something like a Xeon E5.

I tried sys_usetimestampcounter on a Core 2 Duo and it had all the problems described in the DarkPlaces documentation: unstable across processor cores and throttled by power saving. I expect the default choice of timeGetTime is best except in special circumstances.