Oh yea forgot to say it's an intel p4 single proc with HT enabled.
Here's one that repeated 6 times lasting 5 ms...
odd realtime 11172032919604142 1479.026855 1479.368408 0.015000
odd realtime 11172032923627014 1479.368408 1479.368408 0.015000
odd realtime 11172032926027614 1479.368408 1479.368408 0.015000
odd realtime 11172032930865690 1479.368408 1479.368408 0.015000
odd realtime 11172032932857506 1479.368408 1479.368408 0.015000
odd realtime 11172032936032430 1479.368408 1479.368408 0.015000
odd realtime 11172032937616626 1479.368408 1479.368408 0.015000
At 2006/04/12 10:45 PM, [EMAIL PROTECTED] wrote:
>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: [email protected]
>>> 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
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
