Date: Tue, 3 Jun 1997 17:18:42 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: gibbs@plutotech.com (Justin T. Gibbs) Cc: toor@dyson.iquest.net, hackers@FreeBSD.ORG Subject: disk scheduling (was Re: DMA for IDE drives ?) Message-ID: <199706031518.RAA26456@labinfo.iet.unipi.it> In-Reply-To: <199706031502.JAA04331@pluto.plutotech.com> from "Justin T. Gibbs" at Jun 3, 97 09:58:39 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Do the newer IDE drives support any concept similar to tagged queueing? don't know. Does someone has a reference to IDE/EIDE/ATA/EATA command sets specifications available on the net ? > Perhaps via EATA? Supporting DMA is only half the battle in my mind as you Yes it is half the battle but since even the cheapest IDE disks I can buy now support a sustained transfer rate in the 3..5 MB/s and more (measured with iozone for large files, no caching effect) I think the advantage would be significant, especially in terms of responsiveness of the system. My QUANTUM FIREBALL_TM3200S 300X with a 2940A Ultra SCSI does a mere 3MB/s writing (iozone 64 8192), on a PPRO-200. Not impressive, considering a WDC AC21600H does 4.9MB/s on the same hardware (in both cases, a P5-133 gives almost the same results, it is not cpu-limited). The WDC AC21600H has a lower price-per-gigabyte, despite the FIREBALL_TM3200S is one of the cheapest SCSI units available. > won't get anywhere near the throughput of a SCSI drive if you can't > schedule and have the drive reorder multiple transactions at a time. This is only true if (i) your application really needs this, and (ii) you trust the firmware of the drive to implement such scheduling effectively. Let's say that (i) is true (although when you are using FreeBSD on a personal workstation, this is not necessarily true in many cases), I wonder why a disk vendor should go through the effort and cost of implementing complex scheduling policies in the firmware for a disk which will be used in 99% of the cases under Windows95 and with broken chipsets. Really, if you go for IDE, you are probably going for a cheap solution and you give up something in term of performance. Probably, thanks to the tagged queueing you were mentioning, SCSI compared to DMA-IDE can give you better response when handling concurrent requests, but not faster raw speed -- there's no reason why: same mechanics, same electronics, only the interface is different. One more thing: it is true that the disk drive can generally schedule requests better than the OS because it has more info on the real geometry of the drive, but the OS can handle a larger cache and more concurrent requests. Both can do a good job, it all depends on what is the dominant parameter in the access time, whether the rotational latency or the track-to-track head movement. If it is the former (which is likely, since speeds are increasing from 3600 to 7200rpm or more, corresponding to about 4ms avg. for the fastest drives), then the OS does not have a lot of chances with variable geometries. But perhaps future drives might have multiple heads [1] and then rotational latencies will drop to sub-millisecond, and then leaving the OS do the real scheduling will make sense again. [1] I know it is a tough problem to have multiple heads, because they will not be automatically aligned with each other as in the case of a single head, thus there will be significant tracking problems. But they can be solved; e.g. with one write head, multiple read heads one could use the same tracking solutions which are used on CDs. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706031518.RAA26456>