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
