Using the 100% cpu method that always breaks rather easily, I get results as
follows, from the code below. It usually occurs in groups of 2 or 3. The
long-term slowdown may take several days to repro again. In this case you see
realtime being frozen for 2 milliseconds, calling GameFrame 3 times with the
same value:
odd realtime 11168195898843186 105.437195 105.486000 0.015000
odd realtime 11168195901330214 105.486000 105.486000 0.015000
odd realtime 11168195904200006 105.486000 105.486000 0.015000
-----
void CServerGameDLL::GameFrame( bool simulating )
{
#if defined(DEBUG)
static float last_realtime = 0;
if (
(gpGlobals->realtime - last_realtime < gpGlobals->frametime / 3)
|| (gpGlobals->realtime - last_realtime > gpGlobals->frametime * 3)
) {
LARGE_INTEGER PerformanceCount;
assert(QueryPerformanceCounter(&PerformanceCount));
Msg("odd realtime %I64d %f %f %f\n", PerformanceCount, last_realtime,
gpGlobals->realtime, gpGlobals->frametime);
}
assert(gpGlobals->frametime >= 0.0);
assert(gpGlobals->frametime < .03);
last_realtime = gpGlobals->realtime;
#endif
At 2006/04/12 12:14 PM, Jay Stelly wrote:
>The master game clock is driven by QueryPerformanceCounter() on win32
>and gettimeofday() on linux.
>
>Still, we have had reports of clock issues with QPC() (not this
>particular issue however) on AMD x2 systems that were fixed by forcing
>affinity. Also, for winxp/xp64 there is a chipset driver update that
>AMD recommends installing to address some timing issues. I don't have
>the info from AMD handy, but someone has written about it here (and
>provides links to downloads):
>http://ucguides.savagehelp.com/Quake4/FAQ_DualCore.htm#AMD
>
>RDTSC is used for the +showbudget panel. There are some issues with
>that on AMD x2 systems, but that is limited to the profiling code.
>
>Jay
>
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of
>> Jeffrey "botman" Broome
>> Sent: Wednesday, April 12, 2006 6:36 AM
>> To: hlcoders@list.valvesoftware.com
>> Subject: Re: [hlcoders] gpGlobals->realtime standing still
>>
>> Jay Stelly wrote:
>> > What platform? (linux/win32)? On linux realtime is just
>> accumulating
>> > changes from repeated calls to gettimeofday() Have you compared
>> > gpGlobals->realtime to the output of Plat_FloatTime() ?
>> Are they both
>> > slow/stopped or just realtime?
>> >
>> > Has anyone else encountered this problem?
>>
>> ...also, what CPU (Intel or AMD)? Are you running multiple
>> cores and/or CPUs? I remember recently reading about an AMD
>> problem with multiple cores (or was it multiple CPUs) where
>> the RDTSC instruction's time wasn't syncronized between
>> CPUs/cores so when called once by code, it would return the
>> ticks from core 0, when called again, it would return the
>> ticks from core 1 (which could be different). This would
>> make the system appear to jump ahead in time and/or go back
>> in time. If HL2 is using RDTSC instead of
>> QueryPerformanceCounter(), it could get odd results on AMD
>> multi-CPU systems. If memory serves correctly, Windows
>> forces QueryPerformanceCounter() to always run on CPU 0, so
>> you don't get any discrepancy between calls.
>>
>> --
>> Jeffrey "botman" Broome
>>
>> _______________________________________________
>> To unsubscribe, edit your list preferences, or view the list
>> archives, please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
>>
>
>_______________________________________________
>To unsubscribe, edit your list preferences, or view the list archives, please
>visit:
>http://list.valvesoftware.com/mailman/listinfo/hlcoders
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
