Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!iuvax!pur-ee!uiucdcs!uxc.cso.uiuc.edu!ccvaxa!aglew From: aglew@ccvaxa.UUCP Newsgroups: comp.unix.wizards Subject: Re: rdump, Ethernet slowness Message-ID: <57900004@ccvaxa> Date: 11 Dec 87 05:17:00 GMT References: <788@hsi.UUCP> Lines: 33 Nf-ID: #R:hsi.UUCP:788:ccvaxa:57900004:000:1364 Nf-From: ccvaxa.UUCP!aglew Dec 10 23:17:00 1987 ..> Speed of dump vs. rdump You're all talking around the problem of synchronous I/O, if your network has sufficient thruput but excessive latency to use synchronously. In 4.3 dump has been changed to use multiple processes and acheive a facsimile of asynchronous I/O, but I doubt that rdump has. What we really need are asynchronous I/O facilities in UNIX, so that the person who wants to do things at the maximum thruput rate can do so without having to mess with multiple processes. HP's contention that asynch I/O isn't needed because it can be acheived with multiple processes and shared memory doesn't hold water (especially if you're me, and do a lot of I/O intensive work, and are always pressing against your process limits). Asynchronous I/O primitives should basically look like this: IOtransT aread(fd,buf,n) - initiate a read IOtransT awrite(fd,buf,n) - initiate a write iowait(n,iolist) - wait for ios to complete With operations to guarantee sequentiality, or sometimes not. Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801 aglew@mycroft.gould.com ihnp4!uiucdcs!ccvaxa!aglew aglew@gswd-vms.arpa My opinions are my own, and are not the opinions of my employer, or any other organisation. I indicate my company only so that the reader may account for any possible bias I may have towards our products.