Re: mysql benchmarks

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@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscribe@xxxxxxxxxxx"