Date: Tue, 12 Sep 1995 17:58:58 +1000 From: Bruce Evans <bde@zeta.org.au> To: gibbs@freefall.freebsd.org, hackers@freebsd.org Subject: Re: higher density diskettes Message-ID: <199509120758.RAA15898@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>We've got one of the fastest floppy disk drivers. :-) It's even about >>10 % faster than Linux (for sequential reads), i've heard that old >>Xenix' are as fast, and it's way faster than all commercial Unices >>i've seen. (For sequential reads, and i consider them the most >>typical _unix_ usage [tar floppy], we get 30 KB/s, that's 2/3 of the >>raw data rate, and basically proves that we don't use revolutions.) 30K is what you get for naive sequential reads when you waste one revolution out of every 3. The slip occurs every time the cylinder number is increased. It is more or less guaranteed by the head settle delay if sectors are read sequentially. The FreeBSD driver uses a head settle delay of hz/16 ticks, i.e., between 50 and 60 ms. This is much longer than necessary. I think the spec is 15 msec. This would be met by a timeout of 3 ticks (between 20 and 30 ms). Any delay that when combined with the step time is larger than the index gap time guarantees missing a revolution after seeking. In Minix-1.5 or later, the floppy driver misses only 1-3 sectors per step when doing sequential reads. It does this by keeping track of the drive position and reordering i/o for speed. This gives times like the following on identical hardware: Minix-1.6.25++ FreeBSD-current fd0.1440, 1K reads 39000 bytes/sec 30500 bytes/sec rfd0.1440, 1K reads ? 30000 fd0.1440, 18K reads 41000 30720 rfd0.1440, 18K reads ? 30720 fd1.1200, 1K reads ? 30000 fd1.1200, 18K reads 30720 30000 rfd1.1200, 1K reads ? 30000 rfd1.1200, 18K reads ? 30720 The 1200K Minix times are low because the driver was tuned for a faster drive. Some 1200K drives can be accessed with a slippage of <= 1 sectors/rev, so they have a speed of >= 45 * 14/15 K/sec. >The reason most people "think" our floppy I/O is slow is that they >are doing msdosfs things with them. Msdosfs is a real dog in FreeBSD. I think too much buffering and clustering is left to the file system. This loses big when the file system doesn't do any buffering or clustering. Random access is sure to be slow if writes are synchronous. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509120758.RAA15898>