Date: Mon, 8 Feb 2010 11:54:26 +0100 From: Pieter de Goeje <pieter@service2media.com> To: freebsd-questions@freebsd.org Cc: alex <alex@mailinglist.ahhyes.net> Subject: Re: FreeBSD's UFS vs Ext4 Message-ID: <201002081154.26064.pieter@service2media.com> In-Reply-To: <4B6F970F.3060909@mailinglist.ahhyes.net> References: <4B6ED119.2060308@mailinglist.ahhyes.net> <201002080224.01343.pieter@degoeje.nl> <4B6F970F.3060909@mailinglist.ahhyes.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 08 February 2010 05:46:07 alex wrote: > Pieter de Goeje wrote: > > The fact that the limit is 86MB/sec (which is very low for a raid0 array) > > makes me think the box suffers from sub optimal network performance > > during a simple stream test like yours. This could be due to FreeBSD > > having a poor network driver for your particular NIC or could be due to > > insufficient tuning of the TCP parameters for this particular test. > > Hi Pieter. > > You are right about there being a number of possibilities, however: > > *The same machine, which over the years has had a number of revisions of > freebsd on it (have buildworlded the thing from 7-> 7.1 -> 7.2 -> 8), > the performance was always roughly the same amongst the versions, I dont > agree with the possibility of the ftp server being 'slow' as I am the > only person who copies data to that machine, and the machine is always > under a very low (almost non existent) load. That's no reason to rule out inefficient design in the FTP server. I could write a program that sends 1b/sec over the network which serves one user and uses no cpu. > > * Network card is an Intel Pro 1000, on the server. This is a PCI card > (not pci-e), so I believe PCI bus bandwidth limitations may be > responsible for me not being able to achieve the maximum 100MB/s network > rate (as you mention that 86MB/s is slow for raid0) > > * The intel network card driver on freebsd and linux are both fairly > rock solid and well written. I dont see it being an issue with NIC > drivers (they are not vastly different). Solid does not mean high performance. For example, to get maximum performance out of my em nics I have to increase the number of tx and rx descriptors from 256 (default on FreeBSD) to 4096. > > * Both OS's were stock standard installs, no jumbo frames enabled, no > fiddling with sysctl network values. So you haven't tried to improve the performance. Nor have you tried to find out why performance is sub optimal. > > I am happy with 86MB/s anyway, It's a huge improvement of the 60MB/s > barrier I could never get past when that machine was running FreeBSD. > To get the rest of the speed, I'd probably have to install a pci-e card on > the server. > > I do suspect personally that the ext4 filesystem is the reason for the > difference here, since ext4 has a number of features such as deferred > disk writes etc. Ok, what did you actually test? File upload? Download? How big was the testfile? Was the file in cache?. > Even deleting a large file off that raid array I can > see a difference, prior to reformatting, i deleted a 190GB file off the > raid, under UFS the delete took quite some time (well over 10 seconds), > under ext4 the deletion of the same size file took about 3 seconds. File deletion speed is relevant how? > > But what I said with ext4 being faster then the aging UFS still rings > true in my mind, look at the recent Phoronix benchmarks for yourself and > see (10 pages of benchmarks). > > http://www.phoronix.com/scan.php?page=article&item=freebsd8_benchmarks&num= > 1 (skip to page 7 of the benchmarks if you want to see the I/O stuff > relating to disk performance) The phoronix disk benchmarks are of little value in this case. I'll be happy to explain why if you're interested. Further discussion is useless unless you go back and redo the tests, this time trying to isolate the cause instead of making baseless assumptions about the performance of various FreeBSD subsystems. -- Pieter de Goeje
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201002081154.26064.pieter>