Re: [hlds_linux] HLDS and SRCDS system time-sensitive?
This has nothing about how accurate the time is... Its more how long time it takes to get information from gettimeofday(). Let say they uses gettimeofday every tick, it will add up to a lot of calls. If the server do 100 calls per second and it takes 10+ms to get answer from gettimeofday it will be a problem on the server. I thought it was using a easier sequence. /Bjorn On Tue, 6 Jun 2006, Stuart Stegall wrote: None of this matters squat, as hlds/srcds are developed for Microsoft's x86 Win32 platform and Linux's x86 platform. gettimeofday shouldn't be THAT much of a problem for hlds/srcds unless you are not running ntpd. You should be running it on Win32, Linux, or any other production system. If you're having problem with ntpd delivering accurate enough time, then you are having a problem with faulty hardware. There are some mainboards that have had this problem. (usually they didn't put the proper resistors somewhere.) Steven Hartland wrote: kama wrote: Maybe finally I have found something that can explain why I get strange chokes on my servers every now and then? Its a known fact gettimeofday is significantly heavier on freebsd than it is on linux which uses a cheap version. There are various proposed fixes none of which have been released yet but if you have a look in the mail archives you'll find a number of them you might want to try. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [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
Re: [hlds_linux] HLDS and SRCDS system time-sensitive?
I just made the test again today with a fresh updated 6.1 server. I now get much better results... the highest number is down to 2.5ms. average highest number is now 0.8ms. This is when hlds is running. Never the less it still does not perform as well as 4.x in the low and average account. And the count of amount of calls that get over 20us are still aprox 7500-8000 when hlds is run. Well, time for me to upgrade all my servers... just to be on the safe side. /Bjorn On Tue, 6 Jun 2006, kama wrote: On Tue, 6 Jun 2006, Martin Zwickel wrote: -- On Tue, 06 Jun 2006 05:31:19 -0400 Gary [EMAIL PROTECTED] bubbled: gettimeofday() replaced times(), at least on freebsd. also, gettimeofday()'s results will change, depending on if your OS uses ACPI, TSC, HPET, 8254 etc.. gettimeofday replaces times? from man 3 times DESCRIPTION This interface is obsoleted by getrusage(2) and gettimeofday(2). The times() function returns the value of time in CLK_TCK's of a second since 0 hours, 0 minutes, 0 seconds, January 1, 1970, Coordinated Universal Time. from man 7 clocks The clock reported by times(3). This is a virtual clock with a frequency that happens to be 128. Its actual frequency is given by the macro CLK_TCK (deprecated; don't use) and by sysconf(SC_CLK_TCK) and by sysctl(3). Note that its frequency may be different from CLOCKS_PER_SEC. Don't use times(3) in new programs under FreeBSD. It is feeble compared with gettimeofday(2) together with getrusage(). It is provided for POSIX conformance. It is implemented by calling gettimeofday() and getrusage() and throwing away information and resolution. The two functions are for a different behaviour. The one is for the system time, the other for the process time. Also gettimeofday uses nanoseconds and times uses clock ticks. So according to the pages, you will have a greater accuracy with gettimeofday(). instead of 128th of a second you get a 100th of a second. Never the less.. I wrote a simple C program that meassured the diff off gettimeofday() and the diff where quite high in FreeBSD 6.1. I dont know if its an accurate measurement, but I spammed 2 millions gettimeofday as fast as possible and stored them in an array and then calculated the diffs. I runned this at 100 times so its 200 millions gettimeofday calls. It went from 0.03s (3us) to 0.041022s (41ms) between the calls. And 40ms of a gettimeofday call should cause problem on a high tickrate server. Not all the 100 times showed 40+ms, the standard was more 10-12ms, which is extremely high. The average of the calls where low. 0.04s (4us) on all the test. aprox 300 of all of the 2 millions calls where over a threshhold of 0.2 seconds ( 0.02ms ). The highest number was at a random position so the problem if it was the first or last call that caused the problem is not an issue. This test was done on a server that does not run anything but the OS + sshd. When I started hlds ( two empty servers ) and runned the same test when the initial startup have gone. I get aprox 20 times more that goes over the threshold. The average started to diff between 0.04 (4us) and 0.06 (6us) and the highest number was 0.053430s (53ms) The result are similar on different hardware. (same arch though p4 xeon) If I run this on FreeBSD 4.x I get a lower highest number. it sits at aprox 0.001 (1ms) Which I still think is high for a systemcall, but is anyhow only a 40-50th of the later versions of FreeBSD. The lowest number was 0.01s (1us) and a average of 0.01 (1 us). The servers I still have 4.x installed on are quite old. running p3 xeon instead of p4 xeon. And note that these tests where made in FreeBSD without the use of linuxemulator. I'll see if I can make a linux version and try that through the emulator and se if there are even higher numbers. I will also do a couple of more tests on different versions of FreeBSD. (4.11, 5.5 and 6.1) And then hand them over to freebsd, if they can make something out of the information. Take this test as it is... I dont know if my program is actually a good way to check this. I have not really written any benchmarkning programs before. Maybe finally I have found something that can explain why I get strange chokes on my servers every now and then? /Bjorn ___ 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
Re: [hlds_linux] HLDS and SRCDS system time-sensitive?
-- On Sun, 4 Jun 2006 12:13:47 -0700 Alfred Reynolds [EMAIL PROTECTED] bubbled: 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. Isn't gettimeofday a little bit out of accuracy? times is much better for this kind of issue! At least I always use it for time measurement in my video server. It also isn't affected by a time change. Or RDTSC for Intel like processors. Maybe someone should change the hl linux codes to not use gettimeofday. -- MyExcuse: manager in the cable duct Martin Zwickel [EMAIL PROTECTED] Research Development TechnoTrend AG http://www.technotrend.de -- [ signature.asc of type application/pgp-signature deleted ] -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] HLDS and SRCDS system time-sensitive?
gettimeofday() replaced times(), at least on freebsd. also, gettimeofday()'s results will change, depending on if your OS uses ACPI, TSC, HPET, 8254 etc.. I don't think RDTSC will work on SMP machines. Personally, I think gettimeofday() is alot better than what microsoft has for timekeeping. At 05:08 AM 6/6/2006, Martin Zwickel wrote: Isn't gettimeofday a little bit out of accuracy? times is much better for this kind of issue! At least I always use it for time measurement in my video server. It also isn't affected by a time change. Or RDTSC for Intel like processors. Maybe someone should change the hl linux codes to not use gettimeofday. -- MyExcuse: manager in the cable duct Martin Zwickel [EMAIL PROTECTED] Research Development TechnoTrend AG http://www.technotrend.de -- [ signature.asc of type application/pgp-signature deleted ] -- ___ 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
Re: [hlds_linux] HLDS and SRCDS system time-sensitive?
-- On Tue, 06 Jun 2006 05:31:19 -0400 Gary [EMAIL PROTECTED] bubbled: gettimeofday() replaced times(), at least on freebsd. also, gettimeofday()'s results will change, depending on if your OS uses ACPI, TSC, HPET, 8254 etc.. gettimeofday replaces times? The two functions are for a different behaviour. The one is for the system time, the other for the process time. Also gettimeofday uses nanoseconds and times uses clock ticks. I don't think RDTSC will work on SMP machines. Well, SMP Linux should syncronize the RDTSC of the cores on boot. Any I don't believe anyone runs the cores with different speeds. So this shouldn't be a problem?! But I could be wrong, I never coded time stuff on SMP machines. Personally, I think gettimeofday() is alot better than what microsoft has for timekeeping. No clue what Microsoft offers for timekeeping. -- MyExcuse: Telecommunications is downshifting. Martin Zwickel [EMAIL PROTECTED] Research Development TechnoTrend AG http://www.technotrend.de -- [ signature.asc of type application/pgp-signature deleted ] -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] HLDS and SRCDS system time-sensitive?
In a bold display of creativity, Martin Zwickel wrote: Personally, I think gettimeofday() is alot better than what microsoft has for timekeeping. No clue what Microsoft offers for timekeeping. Sundials, is the inevitable answer ;) -- Eric (the Deacon remix) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] HLDS and SRCDS system time-sensitive?
On Tue, 6 Jun 2006, Martin Zwickel wrote: -- On Tue, 06 Jun 2006 05:31:19 -0400 Gary [EMAIL PROTECTED] bubbled: gettimeofday() replaced times(), at least on freebsd. also, gettimeofday()'s results will change, depending on if your OS uses ACPI, TSC, HPET, 8254 etc.. gettimeofday replaces times? from man 3 times DESCRIPTION This interface is obsoleted by getrusage(2) and gettimeofday(2). The times() function returns the value of time in CLK_TCK's of a second since 0 hours, 0 minutes, 0 seconds, January 1, 1970, Coordinated Universal Time. from man 7 clocks The clock reported by times(3). This is a virtual clock with a frequency that happens to be 128. Its actual frequency is given by the macro CLK_TCK (deprecated; don't use) and by sysconf(SC_CLK_TCK) and by sysctl(3). Note that its frequency may be different from CLOCKS_PER_SEC. Don't use times(3) in new programs under FreeBSD. It is feeble compared with gettimeofday(2) together with getrusage(). It is provided for POSIX conformance. It is implemented by calling gettimeofday() and getrusage() and throwing away information and resolution. The two functions are for a different behaviour. The one is for the system time, the other for the process time. Also gettimeofday uses nanoseconds and times uses clock ticks. So according to the pages, you will have a greater accuracy with gettimeofday(). instead of 128th of a second you get a 100th of a second. Never the less.. I wrote a simple C program that meassured the diff off gettimeofday() and the diff where quite high in FreeBSD 6.1. I dont know if its an accurate measurement, but I spammed 2 millions gettimeofday as fast as possible and stored them in an array and then calculated the diffs. I runned this at 100 times so its 200 millions gettimeofday calls. It went from 0.03s (3us) to 0.041022s (41ms) between the calls. And 40ms of a gettimeofday call should cause problem on a high tickrate server. Not all the 100 times showed 40+ms, the standard was more 10-12ms, which is extremely high. The average of the calls where low. 0.04s (4us) on all the test. aprox 300 of all of the 2 millions calls where over a threshhold of 0.2 seconds ( 0.02ms ). The highest number was at a random position so the problem if it was the first or last call that caused the problem is not an issue. This test was done on a server that does not run anything but the OS + sshd. When I started hlds ( two empty servers ) and runned the same test when the initial startup have gone. I get aprox 20 times more that goes over the threshold. The average started to diff between 0.04 (4us) and 0.06 (6us) and the highest number was 0.053430s (53ms) The result are similar on different hardware. (same arch though p4 xeon) If I run this on FreeBSD 4.x I get a lower highest number. it sits at aprox 0.001 (1ms) Which I still think is high for a systemcall, but is anyhow only a 40-50th of the later versions of FreeBSD. The lowest number was 0.01s (1us) and a average of 0.01 (1 us). The servers I still have 4.x installed on are quite old. running p3 xeon instead of p4 xeon. And note that these tests where made in FreeBSD without the use of linuxemulator. I'll see if I can make a linux version and try that through the emulator and se if there are even higher numbers. I will also do a couple of more tests on different versions of FreeBSD. (4.11, 5.5 and 6.1) And then hand them over to freebsd, if they can make something out of the information. Take this test as it is... I dont know if my program is actually a good way to check this. I have not really written any benchmarkning programs before. Maybe finally I have found something that can explain why I get strange chokes on my servers every now and then? /Bjorn ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] HLDS and SRCDS system time-sensitive?
kama wrote: Maybe finally I have found something that can explain why I get strange chokes on my servers every now and then? Its a known fact gettimeofday is significantly heavier on freebsd than it is on linux which uses a cheap version. There are various proposed fixes none of which have been released yet but if you have a look in the mail archives you'll find a number of them you might want to try. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] HLDS and SRCDS system time-sensitive?
None of this matters squat, as hlds/srcds are developed for Microsoft's x86 Win32 platform and Linux's x86 platform. gettimeofday shouldn't be THAT much of a problem for hlds/srcds unless you are not running ntpd. You should be running it on Win32, Linux, or any other production system. If you're having problem with ntpd delivering accurate enough time, then you are having a problem with faulty hardware. There are some mainboards that have had this problem. (usually they didn't put the proper resistors somewhere.) Steven Hartland wrote: kama wrote: Maybe finally I have found something that can explain why I get strange chokes on my servers every now and then? Its a known fact gettimeofday is significantly heavier on freebsd than it is on linux which uses a cheap version. There are various proposed fixes none of which have been released yet but if you have a look in the mail archives you'll find a number of them you might want to try. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [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
RE: [hlds_linux] HLDS and SRCDS system time-sensitive?
hence the question to alfred... /Bjorn On Sun, 4 Jun 2006, Gary wrote: Some OS's have very expensive gettimeofday calls.. At 04:04 PM 6/4/2006, 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
RE: [hlds_linux] HLDS and SRCDS system time-sensitive?
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
RE: [hlds_linux] HLDS and SRCDS system time-sensitive?
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
Re: [hlds_linux] HLDS and SRCDS system time-sensitive?
Erik Hollensbe wrote: Are the daemons time-sensitive with regard to the system time? The reason is, we had a few servers that were out of sync, and I resynced them manually, then the inevitable flood of support requests came in. I can confirm this problem exists. It's not just a simple frame that isn't being rendered ok but whole servers crash/hang. When you run an NTPd everything is fine though. -- Mike Noordermeer [EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
[hlds_linux] HLDS and SRCDS system time-sensitive?
Are the daemons time-sensitive with regard to the system time? The reason is, we had a few servers that were out of sync, and I resynced them manually, then the inevitable flood of support requests came in. I guess my second question could be: is there a reason this limitation exists? -- 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
Re: [hlds_linux] HLDS and SRCDS system time-sensitive?
Erik Hollensbe wrote: Are the daemons time-sensitive with regard to the system time? The reason is, we had a few servers that were out of sync, and I resynced them manually, then the inevitable flood of support requests came in. I guess my second question could be: is there a reason this limitation exists? Not that I know of but how far off? I'm guessing you had users complain about stats? If days off it could throw a wrench in that. -- - m0gely http://quake2.telestream.com/ Q2 | Q3A | Counter-strike ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] HLDS and SRCDS system time-sensitive?
On Jun 4, 2006, at 9:42 AM, m0gely wrote: Erik Hollensbe wrote: Are the daemons time-sensitive with regard to the system time? The reason is, we had a few servers that were out of sync, and I resynced them manually, then the inevitable flood of support requests came in. I guess my second question could be: is there a reason this limitation exists? Not that I know of but how far off? I'm guessing you had users complain about stats? If days off it could throw a wrench in that. No, servers flat-out crashed. And yes, some of them were off by a significant amount of time. -- 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
Re: [hlds_linux] HLDS and SRCDS system time-sensitive?
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. At 03:02 AM 6/4/2006, Erik Hollensbe wrote: Are the daemons time-sensitive with regard to the system time? The reason is, we had a few servers that were out of sync, and I resynced them manually, then the inevitable flood of support requests came in. I guess my second question could be: is there a reason this limitation exists? -- 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
Re: [hlds_linux] HLDS and SRCDS system time-sensitive?
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
RE: [hlds_linux] HLDS and SRCDS system time-sensitive?
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
RE: [hlds_linux] HLDS and SRCDS system time-sensitive?
I don't see how it could cause a crash, but with the complexity of the simulation engine in Source I guess this is possible. Get a better clock in your server. - Alfred Ondrej Hošek wrote: So much for Monday... ;) How can a server actually crash when the time is reset? Is there any part of Valve code that could bungle the server if system time is adjusted? Or is the blame on some plug-in? Maybe I should experiment a bit... ~~ Ondra 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
RE: [hlds_linux] HLDS and SRCDS system time-sensitive?
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
Re: [hlds_linux] HLDS and SRCDS system time-sensitive?
On Jun 4, 2006, at 2:27 PM, Alfred Reynolds wrote: I don't see how it could cause a crash, but with the complexity of the simulation engine in Source I guess this is possible. Get a better clock in your server. Yeah, these machines had been long-neglected and I was doing a time sync on them, that's what caused it. Thanks again for all your help Alfred. -- 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
RE: [hlds_linux] HLDS and SRCDS system time-sensitive?
Some OS's have very expensive gettimeofday calls.. At 04:04 PM 6/4/2006, 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
