FYI all, since dumping ->realtime in favor of ->curtime I have not seen the serious form of this repro. The bug was intermittent, so it could be luck, but it's been about 2 weeks, so it's looking like that was the only bug.
Just a heads-up to anyone thinking of using realtime for anything other than maybe perf testing, don't. (And even that use is questionable.) -bk At 2006/04/18 06:42 PM, [EMAIL PROTECTED] wrote: >No, I do not need real time accuracy. I just need to know how the game thinks >time is advancing each tick. To give an example, I'm using >gpGlobals->realtime to set a stamp and change the weird feature where you can >switch weapons over and over almost limitlessly fast in HL2 DM. > >I left it running overnight with curtime and didn't get any odd curtimes >(well, except for the level changes, but that's ok.) Thanks again - this >seems resolve the second biggest SDK issue I know of, which has been a source >of user complaints for a quite a while. > >-bk > >At 2006/04/17 11:36 PM, Yahn Bernier wrote: >>Yes. Curtime is the server's clock, which is bounded by the tick >>interval and smoothly increases in each call to GameFrame. If the >>actuall time for a frame takes longer than one tick interval, then you >>can have multiple calls to GameFrame (with advancing curtime) but only >>get a single update to gpGlobals->realtime. If you need sub-frame clock >>accuracy (only useful for perf. Analysis really), then use >>Plat_FloatTime() which is independent of gpGlobals->realtime and >>->curtime. Otherwise, if you need a clock, ->curtime is good enough, >>but does reset between levels. gpGlobals->realtime does not, but, >>again, it only gets advanced at the start of a frame (as opposed to each >>tick). >> >>Yahn >> >>-----Original Message----- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED] On Behalf Of >>[EMAIL PROTECTED] >>Sent: Monday, April 17, 2006 8:16 PM >>To: [email protected] >>Subject: RE: [hlcoders] gpGlobals->realtime standing still >> >>Thanks much. When you say curtime "will reflect the 0.015 increments >>per tick", it sounds like you're saying that realtime is broken in this >>regard and I should use curtime instead? That's ok, but please confirm, >>as I will need to do a lot of search and replace. >> >>I've run a few tests and curtime always seems consistent and monotonic, >>however it seems that curtime doesn't start moving until the map loads, >>and is reset on map load. Is that the expected behavior? >> >>-bk >> >>At 2006/04/13 12:33 PM, Yahn Bernier wrote: >>>gpGlobals->curtime will reflect the 0.015 increments per tick. >>>Plat_FloatTime() will resample the high perf clock. >>> >>>Yahn >>> >>>-----Original Message----- >>>From: [EMAIL PROTECTED] >>>[mailto:[EMAIL PROTECTED] On Behalf Of Jay Stelly >>>Sent: Thursday, April 13, 2006 10:21 AM >>>To: [email protected] >>>Subject: RE: [hlcoders] gpGlobals->realtime standing still >>> >>>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: [email protected] >>>> 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: [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 >>>> >>>> >>> >>>_______________________________________________ >>>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 _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
