Yahn found this one - realtime is only integrated once per sever frame. Game frame is called once per server tick. When you run something that uses 100% CPU the server gets starved, then tries to make up the time all in one frame. It's a little more complex than that because there's a cap on the sim time it will try to execute in one frame, but ignoring that:
The first GameFrame() has the complete update to realtime, then the subsequent calls don't change because you're still running ticks to catch up. So in this example: > >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 Frame 2 has a 49ms jump in realtime, and frame 3 has the realtime the same because each tick is 15 ms, so you need to run multiple ticks to catch up. We can change it to make it more incremental, but you're not actually losing any time (at least I can't see any in this data). Jay > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Wednesday, April 12, 2006 9:06 PM > To: hlcoders@list.valvesoftware.com > Subject: RE: [hlcoders] gpGlobals->realtime standing still > > 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: 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 > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
