Hi, There seems to be some serious degradation in performance. Under 7.0 I get about 90 MB/s (on write), while, on the same machine under 7.1 it drops to 20! Any ideas? thanks, danny
> There seems to be some serious degradation in performance. > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > under 7.1 it drops to 20! > Any ideas?Can you compare performanc with tcp? -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare
On Fri, Sep 26, 2008 at 10:04:16AM +0300, Danny Braniss wrote:> Hi, > There seems to be some serious degradation in performance. > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > under 7.1 it drops to 20! > Any ideas?1) Network card driver changes, 2) This could be relevant, but rwatson@ will need to help determine that. http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045109.html -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
On Fri, 2008-09-26 at 10:04 +0300, Danny Braniss wrote:> Hi, > There seems to be some serious degradation in performance. > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > under 7.1 it drops to 20! > Any ideas?The scheduler has been changed to ULE, and NFS has historically been very sensitive to changes like that. You could try switching back to the 4BSD scheduler and seeing if that makes a difference. If it does, toggling PREEMPTION would also be interesting to see the results of. Gavin
On Friday 26 September 2008 03:04:16 am Danny Braniss wrote:> Hi, > There seems to be some serious degradation in performance. > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > under 7.1 it drops to 20! > Any ideas? > > thanks, > dannyPerhaps use nfsstat to see if 7.1 is performing more on-the-wire requests? Also, if you can, do a binary search to narrow down when the regression occurred in RELENG_7. -- John Baldwin
David,
You beat me to it.
Danny, read the iperf man page:
-b, --bandwidth n[KM]
set target bandwidth to n bits/sec (default 1 Mbit/sec). This
setting requires UDP (-u).
The page needs updating, though. It should read "-b, --bandwidth
n[KMG]. It also does NOT require -u. If you use -b, UDP is assumed.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080926/f2199d43/attachment.pgp
Danny Braniss wrote:
> Grr, there goes binary search theory out of the window,
> So far I have managed to pinpoint the day that the changes affect the
> throughput:
> 18/08/08 00:00:00 19/08/08 00:00:00
> (I assume cvs's date is GMT).
> now would be a good time for some help, specially how to undo changes, my
> knowledge of csup/cvs are close to zero.
So you've nailed to down to this 24-hour window:
http://www.secnetix.de/olli/FreeBSD/svnews/?day=2008-08-18&p=/stable/7
I'm afraid that r181822 by rwatson is the most likely
candidate that might be causing the regression.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
"C is quirky, flawed, and an enormous success."
-- Dennis M. Ritchie.