Date: Fri, 17 Nov 1995 10:29:26 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: babkin@hq.icb.chel.su (Serge A. Babkin) Cc: terry@lambert.org, hackers@freebsd.org Subject: NFS benchmarking: iosize granularity? Message-ID: <199511171729.KAA05706@phaeton.artisoft.com> In-Reply-To: <199511170535.KAA29102@hq.icb.chel.su> from "Serge A. Babkin" at Nov 17, 95 10:35:39 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > After latest experiments I have found (with Bruce Evans) the problem due to > > > which DOS cients give terribly bad performance with FreeBSD. The problem > > > is that typical DOS transfer is one sector, 512 bytes while the FreeBSD > > > FFS block size is 8K, so when the file is written sequentially FreeBSD > > > needs to rewrite each block 16 times. The results with SCO or Linux are > > > better because they use 1K blocks. HP-UX results are good too although it > > > has UFS but it divides each block into fragments of 1K and can work with > > > them separately. > > > > This is interesting, but hard to believe in the vmio case. There is a > > bitmap in the buffer cacch for page sized buffers which should result in > > devbsize-based I/O for partial pages. Basically, if I have a dirty write > > to a small record, (512 bytes in this case), the maximum span should be > > two devbsize blocks of the page. > > If it is so then obvioulsly my conclusion was wrong. > > > This may in fact be a bug in the VM system that you have found instead of > > a bug in the way I/O is intended to be done. The worst you should see is > > ~350k/s, not 200k/s, except that the write commits must return before the > > next write can be done on the client. And much of that is due to using > > sync I/O to guarantee ordering. > > May be. Actually I have experimented with a SCO client mounting FreeBSD disks > with different [rw]size and executing dd with different block sizes. The > numbers I got are: > > [rw]size=8192 dd bs=100k: 150K/s write 705K/s read > [rw]size=8192 dd bs=1k: 122K/s write 705K/s read > [rw]size=8192 dd bs=512: 28K/s write 688K/s read > > [rw]size=2048 dd bs=100k: 53K/s write 316K/s read > [rw]size=2048 dd bs=1536: 40K/s write > [rw]size=2048 dd bs=1234: 33K/s write > [rw]size=2048 dd bs=1025: 28K/s write > [rw]size=2048 dd bs=1k: 52K/s write 307K/s read > [rw]size=2048 dd bs=512: 28K/s write > > [rw]size=1024 dd bs=100k: 27K/s write 691K/s read > [rw]size=1024 dd bs=1k: 27K/s write 690K/s read > [rw]size=1024 dd bs=512: 28K/s write 651K/s read > > With DOS Tsoft's client I got 12K/s write and 200K/s read independently of > [rw]size when testing with sysinfo (I'm not shure was it Norton's or > PC-tools). I think you will find that the optimal write size for an NetBIOS based NFS client will be 512 bytes because of the way DOS does file I/O. For Win95, the optimal size will be 512b, followed closely by 32k (32k is highly typical of VFAT). I would be extremely iterested in your SCO/FreeBSD numbers for 4096, as opposed to 8192 or 2048. 4096 is the natural page size for both systems and would seem the correct and logical choice, barring use of NE2000 or similar network cards with an imbalance in read/write buffering in the FreeBSD driver itself. > The network was not empty so I carried out every test several times and > took the best one but the fluctuations are still possible. It is best to run this sort of test on an isolated network... hard to do when you are using production hardware. On the other hand, it's unlikely to get done with any frequency if it requires special staging. A real Catch-22. Bummer. > The network was Ethernet, all network cards are 3c509B except the on in SCO > server which was 3c579. The DOS client was connected through a 3COM TP hub, > FreeBSD and SCO are on thin Ethernet. > > The results are looking like there is some problem with write requests of > 512 bytes size. What is the FS block and frag size on the boxes? It could be that the FS can only do I/O in units of 1k? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511171729.KAA05706>