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 1000000th 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.000003s (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.000004s (4us) on all the test. aprox > 300 of all of the 2 millions calls where over a threshhold of 0.00002 > 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.000004 (4us) and > 0.000006 (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.000001s (1us) and a average of 0.000001 (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
