Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!think!snorkelwacker!bloom-beacon!eru!luth!sunic!mcsun!ukc!dcl-cs!aber-cs!rupert!pcg From: pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.unix.xenix Subject: Re: What's new on adaptex Message-ID: Date: 5 Feb 90 19:40:03 GMT References: <21800001@adaptex> <1458@eutrc3.urc.tue.nl> <25c97303:579.6comp.unix.xenix;1@nstar.UUCP> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 33 In-reply-to: larry@nstar.UUCP's message of 2 Feb 90 11:51:02 GMT Posting-Front-End: GNU Emacs 18.47.1 of Wed Mar 15 1989 on rupert (berkeley-unix) In article <25c97303:579.6comp.unix.xenix;1@nstar.UUCP> larry@nstar.UUCP (Larry Snyder) writes: >So ESDI users should not feel like they missed a great opportunity by not >starting off with SCSI. I agree that SCSI may be better from a conceptual I agree 100%. Many times I've seen ESDI subsystems exceed throughput of SCSI ones. I agree 70%. :-) Throughput in sequential reads from the disc is not the only measure, and there are funny consequences. Latency may be important; a multithreaded SCSI controller with two drives can overlap seeks and transfers. Random access may be important, for example for directory tree scans, databases. Read ahead may slow down random accesses. Writing may be important, even if reading is prevalent. Track buffering, nairvely implemented, may slow down writes. I/O thru the filesystem may be important, actually is, usually. There are already wide variations between buffered and raw disc accesses; file system accesses have a different profile again. SCSI is more sophisticated, and will keep better performance is less favourable conditions. MSDOS, single user UNIX, editing and compiles, tend not to exploit the advantages of SCSI. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk