Peter Pentchev wrote:
On Fri, Dec 09, 2005 at 08:05:37PM -0800, Jin Guojun [VFFS] wrote:
David Xu wrote:
Gustavo A. Baratto wrote:
Since the last post just had freebsd numbers, I'm re-posting it
including
Linux as well. Both linux and freebsd numbers were taken from the
same box:
...
Can you try TSC timer on FreeBSD ? someone reported that using TSC
timer boosts performance of super-smack significantly.
David Xu
"TSC" can be a few 100 times faster than gettimeofday(), but one needs
to know
how to calibrate and convert it to timer because TSC is counter, not timer.
Also, if FreeBSD uses TSC to compare with Linux using gettimeofday,
it does not sound a fun.
gettimeofday is a very expensive function on all systems.
http://dsd.lbl.gov/DIDC/papers/imc-2003.pdf
tells how much it costs on some common systems, especially FreeBSD and
Linux.
So, if both systems use gettimeofday, then slow may be somewhere else.
Errrr... I think David might have meant that the original poster should
simply set kern.timecounter.hardware to 'TSC', not i8254 or something
else. This would not change whether MySQL uses gettimefday() or not,
it would simply change the in-kernel method of obtaining the actual
time of day - at least that's how I understand it :)
G'luck,
Peter
Very brave guess, but this is not the reality we discuss :-)
That is why I point to the paper, where the work was done 13 years ago,
but published 10 years later because most users do not understand
where is the cost, and do not know where to look for the information.
Below is the data (watch the method for timestamp -- gettimeofday),
and notice that TSC cost is almost constant. Even though gettimeofday
is impacted by different methods (from about 3.4 us to 7.9 us : 132%
better),
comparing to TSC cost (5000%~11888% better), the improvement is nothing.
So, just tweaking the knob kern.timecounter.hardware will have less
improvement
for this problem depending on what is the percentage of gettimeofday used
(10% use of gettimeofday implies about 5% improvement by tweaking to TSC).
Also notice that TSC has a negtive quality (-100), which may cause
system time
drift (probably due to no tick correction).
kern.timecounter.choice: TSC(-100) PIIX(0) i8254(0) dummy(-1000000)
% FreeBSD 6.0 on 465MHz PIII
[233] Belkin: bm -e
2 us for timestamp (min 1, max 3) method "TSC"
timestamp measured by tsc = 3417.077858 ns
tsc cost = 66.874630 ns
1 us for 1 sub-call => 3 (see avg result)
main Pid 64348
avg 1800 subone-math => 7 ns (1800 Yes)
avg 1800 subone-calls => 15 ns
avg 1800 tvdiff-calls => 18 ns
avg 1800 sub-calls => 1664 ns
avg 1800 syscalls (ers 0) => 1626 ns
avg 1800 write-calls (err 0) => 3606 ns
avg 1800 read-calls (err 0) => 2033 ns
avg sys-calls => 2421 ns
[234] Belkin: bm -e
4 us for timestamp (min 3, max 5) method "PIIX"
timestamp measured by tsc = 6139.522464 ns
tsc cost = 66.874630 ns
...
[235] Belkin: bm -e
5 us for timestamp (min 5, max 8) method "i8254"
timestamp measured by tsc = 7968.867176 ns
tsc cost = 66.874630 ns
...
_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
