Date: Tue, 13 Dec 2005 20:32:21 -0800 From: "Jin Guojun [VFFS]" <j_guojun@lbl.gov> To: Peter Pentchev <roam@ringlet.net> Cc: freebsd-performance@freebsd.org, David Xu <davidxu@freebsd.org>, "Gustavo A. Baratto" <gbaratto@superb.net> Subject: Re: mysql benchmarks Message-ID: <439FA055.5040509@lbl.gov> In-Reply-To: <20051213134218.GB1142@straylight.m.ringlet.net> References: <032801c5fd32$df28c3b0$6400a8c0@garrincha> <439A4301.5030404@freebsd.org> <439A5411.8090005@lbl.gov> <20051213134218.GB1142@straylight.m.ringlet.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?439FA055.5040509>