The value of QPC() isn't as useful as the value of Plat_FloatTime(). Plat_FloatTime() is making this call, but it also uses the initial state of the clock and the initial performance frequency. So it would be more useful to see the output of that function than just raw QPC(). At least that would tell me whether the problem is there or in the code that pushes time through the frameloop.
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Wednesday, April 12, 2006 8:46 PM > To: hlcoders@list.valvesoftware.com > Subject: RE: [hlcoders] gpGlobals->realtime standing still > > 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 > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
