Under linux 2.4 and earlier the gettimeofday() call has around a 10msec increments between updates (i.e it has nanosecond resolution but the OS only changes the time once per scheduler update). The larger the wall clock time between updates to the clock value the worse the server will perform, and if the clock value isn't monotonically increasing (i.e never goes backwards) you could see bad effects (choke could be one of them).
- Alfred kama wrote: > Not as much a bad hardware clock as a OS related issue. > > Lets say gettimeofday() uses X ts (time slices) in OS A that counts > as a > extremely accurate call. If OS B uses 2X-7X ts in a random fashion, > could > this cause any choke problems? > > /Bjorn > > On Sun, 4 Jun 2006, Alfred Reynolds wrote: > >> In theory as the network system uses the gettimeofday() value to work >> out network usage, but you would need a really really bad clock. >> >> - Alfred >> >> kama wrote: >>> Could this cause choke if the gettimeofday() is really choppy and >>> time consuming? >>> >>> /Bjorn >>> >>> On Sun, 4 Jun 2006, Alfred Reynolds wrote: >>> >>>> Both server engines use the gettimeofday() call to work out elpased >>>> time. If that time moves significantly during a frame then the next >>>> frame will not run properly (you would see a one frame glitch on >>>> the server). If your clock is adjusted once per day then this >>>> won't be noticable but if your clock is constantly wandering the >>>> effects could be seen. >>>> >>>> - Alfred >>>> >>>> Erik Hollensbe wrote: >>>>> On Jun 4, 2006, at 11:37 AM, Gary wrote: >>>>> >>>>>> If you are talking about cumulative clock drifting, yes. As far >>>>>> as it's interaction to hlds etc, I don't know :) >>>>>> I know the quartz is sensitive to temperatures and if it gets too >>>>>> warm/BIOS issue, it will drift more. >>>>> >>>>> Sorry, I meant the daemons. The clock drift isn't the issue, >>>>> safely updating the time on the box is. :) >>>>> >>>>> Hopefully Alfred can chime in on this topic monday. >>>>> >>>>> -- >>>>> Erik Hollensbe >>>>> [EMAIL PROTECTED] >>>>> >>>>> _______________________________________________ >>>>> To unsubscribe, edit your list preferences, or view the list >>>>> archives, please visit: >>>>> http://list.valvesoftware.com/mailman/listinfo/hlds_linux >>>> >>>> _______________________________________________ >>>> To unsubscribe, edit your list preferences, or view the list >>>> archives, please visit: >>>> http://list.valvesoftware.com/mailman/listinfo/hlds_linux >>>> >>> >>> _______________________________________________ >>> To unsubscribe, edit your list preferences, or view the list >>> archives, please visit: >>> http://list.valvesoftware.com/mailman/listinfo/hlds_linux >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list >> archives, please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlds_linux >> > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list > archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
