So BK, It would be best for all of us working on MP based mod's to find and replace every instance of realtime with curtime?
Adam --- [EMAIL PROTECTED] wrote: > 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 > > -------- My Website http://www.ammahls.com Lead Programer NightFall http://www.nightfallmod.net Developer of CST and ZHLT 3.0 http://www.zhlt.info Team Lead - Prime - http://www.nigredostudios.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
