lupienj@hpwadac.hp.com (John Lupien) (02/04/91)
The summary above is the start of the following quote: Better to hold your tongue be thought a fool than to speak out and remove all doubt. This is yet another example of Mr. Giles speaking out. I already had no doubt in my mind, and perhaps this posting is another waste of bandwidth and comp.arch disk space, but this is really bugging me. In article <13252@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <409@bria>, by mike@bria: >> I won't waste much time on this one: if you think that UNIX tools are >> weak, then you don't know how to use them correctly. 'Nuff said there. >Ok, you're the expert. Let's hear how to do asynchronous I/O on UNIX >(not _buffered_ through the system - _real_ asynchronous I/O)? Oh, >that's right, UNIX can't do that. Try reading the manual. Look at the page for "stty(1)", and "termio(7)". Read them carefully. Think about what you see. Don't bother to appologize for your ignorance, just do what you can to alleviate it. This means "learn something". It means an actual effort on your part, and it will do you some good. It may improve your mind. At the least, it may relieve your ignorance. >Well, let's hear how to tell the system not to kill my active processes >when the system goes down? Oh, UNIX doesn't have any automatic crash >recovery. Was this sopposed to make DOS seem superior? Last I checked, DOS had no such support. However, if you are intelligent, persistent, clever, and experienced, it is possible to take a system core dump and find out what went wrong on software faults. If your problem was not a software fault, good luck. You must have one heck of a system if you can restart everything after a hardware fault. >How about reconnect (you know, my modem drops off in the middle of a job >and I want to sign on and reconnect to the job)? Oh, UNIX automatically >kills jobs when connection fails except when the job is 'nohup'ed - but, >even then, you can't reconnect: the only thing you can do with a >'nohup'ed job from a _different_ terminal session is kill it. Yes, that is the way I want it. This is a very good thing. I do not want Mr. Giles to be able to dial up and reconnect to my process. I'd rather have it die (gracefully or otherwise) than risk having someone else gain access to my process, which may well be running as me. Since DOS has no protection features at all, I can understand why this issue is lost on Mr. Giles, who is trying to make ignorance a virtue. >Ok, how about error recovery? Job fails (after, say, an hour of CPU >time) with a divide-by-zero error. I want to go into the 'core' file >and edit out the zero and restart the job from where it left off. Oh, >UNIX can't restart 'core' files. Well, I have done many such restarts in my life, and although I far prefer to fix the software which UNIX has just allowed me the luxury of knowing it was broken, the debuggers are quite capable of exactly what you indicate is not possible. See the manual, try "adb(1)", "dbx(1)", "sdb(1)", and "cbd(1)". >Etc. etc.. Yes, you've really convinced me. UNIX is _really_ useful. >(Heavy sarcasm - in case you don't get it.) The ignorance weighs much more heavily on my mind. >> You're still missing the point about tools, I see. <sigh> The tools >> approach *forces* nothing. You have the freedom do what you want, >> how you want. The price of admission: an IQ exceeding that of a treestump, >> and the interest (and motivation) to learn something new. [...] I have seen no evidence that Mr. Giles lacks the intelligence of a treestump. It seems clear that he lacks the motivation to learn about a subject that he wishes to discuss. As a result, he lacks the ability to discuss it meaningfully. Read the manual. It may take a day, it may take a year, I don't know how long it will take, but I know it is worthwhile. I have read the DOS manuals, they are singularly poor documentation, but I feel better equipped to discuss the matter as a result. >What? NONE of the UNIX tools do anything _NEW_. They are just poorly >designed and hard to use versions of utilities that every system I've >ever seen has versions of. The difference is that most other systems >are _easier_ to learn and to use than the UNIX stuff is. The thing is, >people spend so much time and effort to learn UNIX tools that they get >a feeling of accomplishment from them. This feeling of accomplishment >comes from the complexity of what they've had to learn - not from the >value of it (sort of like winning ZORK - as I've said before). In the >end, they can only do those things which people on other systems can do >easier. Once again, ignorance is not a basis for argument. How can you say what the UNIX tools lack, when you do not know what they are, and what they can do? Read the manual. If for nothing else, do it as an exercise in humility. Then think about what you read. It won't hurt you much, and you may become wiser as a result. >Things are improving on UNIX. Most workstations now come with GUI's >and other high-level interfaces whic conceal or bypass the usual UNIX >tools stuff. The problem with these is: once they are in place it >becomes possible to provide them _instead_ of the UNIX stuff - in fact >you don't need UNIX itself anymore. Now, that _would_ be a step forward. Please don't try to tell me what I need or don't need - that has little to do with you. I use the tools that get the job done, and I try to learn what tools exist in order to be able to make informed decisions regarding their use. The step forward that I look for is that of learning: when I learn new things, I have improved myself. My mind thus becomes more valuable to me, and I am able to better understand and appreciate the world around me. It offends me that someone would try to tell me that I am foolish in wanting to learn, but I have very little trouble rejecting such arguments since they serve to highlight the ignorance of the espousers thereof. --- John R. Lupien lupienj@hpwarq.hp.com
mcdonald@aries.scs.uiuc.edu (Doug McDonald) (02/04/91)
The > system is a mess. JDM is me, JL is John Lupien, and JG is Jim Giles. JL>This is yet another example of Mr. Giles speaking out. JL>I already had no doubt in my mind, and perhaps this JL>posting is another waste of bandwidth and comp.arch JL>disk space, but this is really bugging me. JG>Ok, you're the expert. Let's hear how to do asynchronous I/O on UNIX JG>(not _buffered_ through the system - _real_ asynchronous I/O)? Oh, JG>that's right, UNIX can't do that. > JL>Try reading the manual. Look at the page for "stty(1)", and "termio(7)". JL>Read them carefully. Think about what you see. Don't bother to appologize JL>for your ignorance, just do what you can to alleviate it. This means JL>"learn something". It means an actual effort on your part, and it will JL>do you some good. It may improve your mind. At the least, it may relieve JL>your ignorance. > Th last quote above does indeed show the ignorance of JL. JL, do you know what "asynchronous IO" means in the context of JG's flame? It is for DISK (or equivalent) IO. I'll try to explain. The most general method means that you call a system subroutine with a pointer parameter to a buffer, and a file descriptor of some sort, and a size, and a function pointer to a "completion routine". YOUR PROGRAM CONTINUES RUNNING. IT DOES NOT BLOCK. The system them has the disk drive read the data into the buffer. (Mr. Giles wanted "no buffering". This implies that if the computer has cycle-stealing DMA or a double path to memory for the IO system that the data goes directly from the disk hardware to memory while computing continues. Some modern disk systems have track buffers in them and with those it is often faster to wait till the track buffer fills up and read it as shared memory with orfinary instructions.) WHEN THE BUFFER GETS FILLED THE COMPLETION ROUTINE GETS CALLED. Thus the original program can contine processing WHILE the IO gets done. If it has lots of work to do the completion routine will get called while the original routine still is working. Presumably it can tell that the IO was finished because the completion routine sets a global flag that it periodically tests. If the original routine runs out of things to do then it call "yield()", which does not return to the main routine. The completion routine can do that when it is entered, or it can complete and exit by calling "wake_up(main_routine)". This process allows one program to utilize ALL the CPU power of a computer and most or all of the IO power at the same time. One of the original DESIGN GOALS of Unix was to prevent this. My old PDP-11 laboratory computers used this mechanism for storing data on the disks. There are other exact ways to achieve this. The above works on RT-11 or VMS. IBM mainframes, God bless their poor demented souls, have another way, but have it they do. There are modern Unix semi-lookalikes that can do it. >Since DOS has no >protection features at all, I can understand why this issue is lost on >Mr. Giles, who is trying to make ignorance a virtue. > I seriously doubt that DOS was what JG was thinking of. JG has a several good points made. I can't be sure that the thing I explained above is EXACTLY what he wanted, but I'll bet it will satisfy him as an example. Doug McDonald
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (02/05/91)
In article <1991Feb4.154607.8606@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: | I'll try to explain. The most general method means that you call a system | subroutine with a pointer parameter to a buffer, and a file descriptor of some | sort, and a size, and a function pointer to a "completion routine". | | YOUR PROGRAM CONTINUES RUNNING. IT DOES NOT BLOCK. | [ stuff ] | WHEN THE BUFFER GETS FILLED THE COMPLETION ROUTINE GETS CALLED. This stuff seems to be in V.4 and venix, and perhaps HP-UX. JG is complaining about the things UNIX doesn't do, which it wasn't intended to do. He probably complains that his bicycle doesn't squeeze oranges or fry fish, too. Instead of trying to explain that UNIX can do some of these things, tell him he doesn't understand the use of UNIX. He won't be satisfied with an orange squeezing frying pan on his bike, and he'll keep dreaming up other things UNIX isn't trying to do as long as people keep accepting these bizarre ideas as goals of UNIX. JG has been asked several time to take this to alt.religion.computers, but has continued to post his stuff here. He does not understand the uses of UNIX, hardware, software, or this group. This group is for computer architecture, alt.religion.computers is for why your computer, or some mythical computer, or some real computer which doesn't do what you think it does, is better than some other computer. We don't discuss that here! Go away! -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "I'll come home in one of two ways, the big parade or in a body bag. I prefer the former but I'll take the latter" -Sgt Marco Rodrigez
bsy+@cs.cmu.edu (Bennet Yee) (02/05/91)
>Well, let's hear how to tell the system not to kill my active processes >when the system goes down? Oh, UNIX doesn't have any automatic crash >recovery. I have normal Unix code that runs at the user level that periodically checkpoints running processes. Have had for years. Runs on Vaxes, RTs, Sun3s, Sun4s. Recently spent half an hour and ported it to my (new) pmax. You just change the name of main to _main, relink, and you're done. It saves the registers, the data, and stack segments every 15 minutes and restores them on restart (from a file); I/O descriptors have to be handled separately (with IPC, this can be very ugly). With rcrun(8cmu) which runs my ~/.rc from /etc/rc (and handles the security aspects, etc), I've ran a poor little uVax3 ragged for a week, surviving several reboots. Automatically with no kernel support. Ho hum. So you lose at most 15 minutes of computation. If you want to handle _file_ descs, just remember the seek positions for read-only and write-only files, and copy the read/write ones (this could be expensive). >How about reconnect (you know, my modem drops off in the middle of a job >and I want to sign on and reconnect to the job)? Oh, UNIX automatically >kills jobs when connection fails except when the job is 'nohup'ed - but, >even then, you can't reconnect: the only thing you can do with a >'nohup'ed job from a _different_ terminal session is kill it. Look at CMU ptys (distributed with Mach 2.5, I believe). Allows disconnects. Prompts for a reconnect after successful login. CMU ptys has been around long before I came here. Again, ho hum. BTW, is this suppose to be ``software architecture'' or something? Why is this in comp.arch? How about moving this to alt.unix.flammage or something? -bsy -- Bennet S. Yee, +1 412 268-7571 School of Cucumber Science, Cranberry Melon, Pittsburgh, PA 15213-3890 Internet: bsy+@cs.cmu.edu Uunet: ...!seismo!cs.cmu.edu!bsy+ Csnet: bsy+%cs.cmu.edu@relay.cs.net Bitnet: bsy+%cs.cmu.edu@carnegie
archer@elysium.esd.sgi.com (Archer (Mr. Slug) Sully) (02/05/91)
As long as we have this subject line I should put in my two cents... :-)
In <1991Feb4.154607.8606@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes:
*
*Th last quote above does indeed show the ignorance of JL. JL, do you know
*what "asynchronous IO" means in the context of JG's flame? It is for
*DISK (or equivalent) IO.
*
*
*I'll try to explain. The most general method means that you call a system
*subroutine with a pointer parameter to a buffer, and a file descriptor of some
*sort, and a size, and a function pointer to a "completion routine".
*
*YOUR PROGRAM CONTINUES RUNNING. IT DOES NOT BLOCK.
*
I've implemented this in UNIX (well, SGI multiprocess UNIX, really).
It worked okay, but because of the nature of the disk controller and
the system (symmetric shared memory multiprocessor), it wasn't an
improvement over the normal file system. Performance differences ranged
from a 1% gain to a 5% loss on real life code. Generally we found that
when accessing a file sequentially the kernel did a better job of figuring
everything out than the program itself could.
Async i/o wins when the disk has very long seek time and slow transfer
rates. And it has to be slower than SCSI in order to win. All IMHO,
of course.
*
*JG has a several good points made. I can't be sure that the thing I explained
*above is EXACTLY what he wanted, but I'll bet it will satisfy him as an
*example.
*
Oh, its what he was talking about all right, it just doesn't make sense to
do it on the kind of disks and controllers we use today.
*
*Doug McDonald
--
"The only problem with poetic justice is that it doesn't know when to quit"
-- Barry Hughart
<archer@sgi.com> Archer Sully jlg@lanl.gov (Jim Giles) (02/05/91)
From article <3175@crdos1.crd.ge.COM>, by davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr): > [...] > This stuff seems to be in V.4 and venix, and perhaps HP-UX. JG is > complaining about the things UNIX doesn't do, which it wasn't intended > to do. He probably complains that his bicycle doesn't squeeze oranges or > fry fish, too. This is a typical "UNIX speak" type of answer. The implication is that anything UNIX doesn't do is somehow inappropriate for use in a computing system. So we get analogies of bicycle/kitchenware combos. The problem with this argument is that a number of features are so common and so familiar to computer users that it doesn't seem like a whole computer without them. Every mainframe of any note for the last 30 years has had asynchronous I/O (at least as an option). For the last 20 years - its been a standard feature. For most minis, the feature has been common for over a decade. It's even showing up on (plans at least) microcomputers. Now, you're pretending that this kind of feature is somehow strange or out-of-the-ordinary for a system to support? To keep the bicycle analogy, a system without asynchronous I/O is like a bike with only one speed - _NOBODY_ makes them like that any more! J. Giles
vladimir@Eng.Sun.COM (Vladimir G. Ivanovic) (02/05/91)
About the modem reconnect problem, I believe that VMS solves it by requiring a
password and then resumes the process at the point of disconnection.
-- Vladimir
--
==============================================================================
Vladimir G. Ivanovic Sun Microsystems, Inc
(415) 336-2315 2550 Garcia Ave., MTV12-33
vladimir@Sun.COM Mountain View, CA 94043-1100
Disclaimer: I speak for myself.
==============================================================================mcdonald@aries.scs.uiuc.edu (Doug McDonald) (02/05/91)
In article <1991Feb4.210853.22139@odin.corp.sgi.com> archer@elysium.esd.sgi.com (Archer (Mr. Slug) Sully) writes: >As long as we have this subject line I should put in my two cents... :-) > >In <1991Feb4.154607.8606@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: > >* >*Th last quote above does indeed show the ignorance of JL. JL, do you know >*what "asynchronous IO" means in the context of JG's flame? It is for >*DISK (or equivalent) IO. >* >* >*I'll try to explain. The most general method means that you call a system >*subroutine with a pointer parameter to a buffer, and a file descriptor of some >*sort, and a size, and a function pointer to a "completion routine". >* >*YOUR PROGRAM CONTINUES RUNNING. IT DOES NOT BLOCK. >* > >I've implemented this in UNIX (well, SGI multiprocess UNIX, really). >It worked okay, but because of the nature of the disk controller and >the system (symmetric shared memory multiprocessor), it wasn't an >improvement over the normal file system. Performance differences ranged >from a 1% gain to a 5% loss on real life code. Generally we found that >when accessing a file sequentially the kernel did a better job of figuring >everything out than the program itself could. > >Async i/o wins when the disk has very long seek time and slow transfer >rates. And it has to be slower than SCSI in order to win. All IMHO, >of course. > >Oh, its what he was talking about all right, it just doesn't make sense to >do it on the kind of disks and controllers we use today. > For general purpose sorts of computing that can normally be done on Unix you are quite right indeed, these days. But for special cases - real time stuff - it can still make a big difference. The point is that async IO wins when you simply CAN'T stop your computing (CPU use) to wait for a disk transfer. OR when you try to get the absolute most performance out of a machine running only ONE program (i.e. a Cray doing a weather simulation.) Doug McDonald
kenw@skyler.arc.ab.ca (Ken Wallewein) (02/05/91)
In article <3175@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: >... > JG has been asked several time to take this to alt.religion.computers, > but has continued to post his stuff here. He does not understand the > uses of UNIX, hardware, software, or this group. > > This group is for computer architecture, alt.religion.computers is for > why your computer, or some mythical computer, or some real computer > which doesn't do what you think it does, is better than some other > computer. We don't discuss that here! Go away! > -- > bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1! Problem is, Bill, that he's sucked you all in. This whole thread has been not worth participating in -- none of you has been particularly constructive, or willing to concede a point. And your biases are showing, to boot. -- /kenw Ken Wallewein A L B E R T A kenw@noah.arc.ab.ca R E S E A R C H (403)297-2660 C O U N C I L
yar@cs.su.oz (Ray Loyzaga) (02/05/91)
In article <1991Feb5.020456.1119@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: > > In article <1991Feb4.210853.22139@odin.corp.sgi.com> archer@elysium.esd.sgi.com (Archer (Mr. Slug) Sully) writes: > >As long as we have this subject line I should put in my two cents... :-) > > > >In <1991Feb4.154607.8606@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: > > For general purpose sorts of computing that can normally be done on Unix > you are quite right indeed, these days. But for special cases - > real time stuff - it can still make a big difference. The point is that async IO > wins when you simply CAN'T stop your computing (CPU use) to wait for > a disk transfer. OR when you try to get the absolute most performance > out of a machine running only ONE program (i.e. a Cray doing > a weather simulation.) > > > Doug McDonald 2 processes, shared memory, semaphores.
cgy@cs.brown.edu (Curtis Yarvin) (02/05/91)
In article <13632@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <3175@crdos1.crd.ge.COM>, by davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr): >> [...] >> This stuff seems to be in V.4 and venix, and perhaps HP-UX. JG is >> complaining about the things UNIX doesn't do, which it wasn't intended >> to do. He probably complains that his bicycle doesn't squeeze oranges or >> fry fish, too. > >This is a typical "UNIX speak" type of answer. The implication is that >anything UNIX doesn't do is somehow inappropriate for use in a computing >system. So we get analogies of bicycle/kitchenware combos. I doubt that anyone on this net would claim that UNIX is appropriate for all computing systems. Specifically, it lacks support for the following applications: (1) Batch-processed number-crunching (no asynchronous disk I/O, too much task switching, etc). (2) Heavy-duty transaction processing (weak I/O system, poor crash recovery, etc). If this is what you do at lanl, Mr. Giles -as your complaints indicate- far be it from me to tell you what operating system to use. Crawl back under your rock and write fluid flow simulations in FORTRAN. But it is important to recognize that these fields represent a rapidly-shrinking percentage of computer applications. Users these days want graphical interfaces, networking, workstations, and a fluid, application-oriented environment. None of which Unix was designed for, but all of which it is flexible enough to accommodate. Ever try to write a GUI for VM/CMS? Have you ported X to the VAX? >The problem with this argument is that a number of features are so common >and so familiar to computer users that it doesn't seem like a whole >computer without them. Every mainframe of any note for the last 30 >years has had asynchronous I/O (at least as an option). I can just hear the users clamor... "Geez! My Mac doesn't have asynchronous I/O! Doesn't seem like a whole computer without it!" Sorry to stretch the analogies, but every steam locomotive for the last 100 years has had a smokestack. Does this mean my car needs one? Remember, I'm not claiming my car can do the job of a locomotive... just that it's not intended to. >It's even showing up on (plans >at least) microcomputers. Hmm... I'd be interested in seeing you cite something on this (translate: "OH BOY! You mean I can run CMS on my PC?" >To keep the bicycle analogy, a system without asynchronous >I/O is like a bike with only one speed - _NOBODY_ makes them like that >any more! The reason that nobody makes them like that any more is that nobody makes them any more. The last proprietary operating system released was OS/2. Anyone care to eulogize it? Curtis "I tried living in the real world Instead of a shell But I was bored before I even began." - The Smiths
chesnutt@adobe.com (Stan Chesnutt) (02/05/91)
In article <13632@lanl.gov> jlg@lanl.gov (Jim Giles) writes: [about another correspondent's comments of Unix design philosophy] >This is a typical "UNIX speak" type of answer. The implication is that >anything UNIX doesn't do is somehow inappropriate for use in a computing >system. So we get analogies of bicycle/kitchenware combos. > >The problem with this argument is that a number of features are so common >and so familiar to computer users that it doesn't seem like a whole >computer without them. Every mainframe of any note for the last 30 >years has had asynchronous I/O (at least as an option). For the last >20 years - its been a standard feature. For most minis, the feature >has been common for over a decade. It's even showing up on (plans >at least) microcomputers. Now, you're pretending that this kind of >feature is somehow strange or out-of-the-ordinary for a system to >support? To keep the bicycle analogy, a system without asynchronous >I/O is like a bike with only one speed - _NOBODY_ makes them like that >any more! > >J. Giles Thanks, Jim, for pointing this out. I'll add my own anecdote here. About a year ago, a friend was excitedly telling me about the new SunOS (4.0?) features of file mapping (mmap()) and having "shared" library files that would exist in memory once as shared clients of multiple executables. Somewhat of a dynamically-linked system, but with many restrictions. After my colleague had finished, I mentioned one of the previous incarnations of this design: the Multics operating system that I used in college. When my friend expressed disbelief, I handed over my copy of Organick's "The Multics System" Case closed. We will be seeing a lot more of this Unix monomania in the future, I fear. This is because progressively more of the university computer centers are becoming homogenous Unix sites. While this is not necessarily bad, not exposing students to a wide variety of system design concepts is very, very bad. ----------------------------------------------------------------------------- Stan Chesnutt, Adobe Systems chesnutt@adobe.com {sun|decwrl}!adobe!chesnutt "Hearts full of youth, hearts full of truth. Six parts gin to one part vermouth"
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (02/05/91)
Overlap of i/o and CPU is certainly possible with standard UNIX, shbundle does it, for instance. What is missing from most versions is an async i/o system call. Having written most of my life on systems which *only* had asysnc i/o and forced you to issue a 'wait for i/o' if you wanted something else, I used to be bothered by that. I'd still like the system call, but having learned to use the system I can now get the effect, so I'm able to do it if I really must. UNIX writes usually overlap CPU, since the system buffers them. Async makes little difference in run time for an i/o bound job or a CPU bound job, it's only in the case where i/o and CPU time are roughly equal that a major improvement is seen. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "I'll come home in one of two ways, the big parade or in a body bag. I prefer the former but I'll take the latter" -Sgt Marco Rodrigez
archer@elysium.esd.sgi.com (Archer (Mr. Slug) Sully) (02/06/91)
In <1991Feb5.020456.1119@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes:
*
*For general purpose sorts of computing that can normally be done on Unix
*you are quite right indeed, these days. But for special cases -
*real time stuff - it can still make a big difference. The point is that async IO
*wins when you simply CAN'T stop your computing (CPU use) to wait for
*a disk transfer. OR when you try to get the absolute most performance
*out of a machine running only ONE program (i.e. a Cray doing
*a weather simulation.)
*
*
Have you actually done benchmarks and performance comparisons that prove
this?
--
"The only problem with poetic justice is that it doesn't know when to quit"
-- Barry Hughart
<archer@sgi.com> Archer Sully mccalpin@perelandra.cms.udel.edu (John D. McCalpin) (02/06/91)
> On 5 Feb 91 17:25:29 GMT, archer@elysium.esd.sgi.com (Archer Sully) said: Archer> In <1991Feb5.020456.1119@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: Doug> [....] The point is that async IO *wins when you simply Doug> CAN'T stop your computing (CPU use) to wait for *a disk Doug> transfer. Archer> Have you actually done benchmarks and performance comparisons Archer> that prove this? The people at Thinking Machines told me about a problem that they were working on --- the solution of a 100,000x100,000 dense system of linear equations. Yes, they were actually solving a matrix with 10^10 entries! They used a multi-level block-mode algorithm (not to be confused with a multi-level multi-grid algorithm) and staged the data from tape to disk to RAM. If I recall correctly, they were claiming sustained performance of over 1000 MFLOPS for the week or so that the job took to complete. Perhaps someone out there has the correct numbers? Anyway, this is clearly an example for which fully overlapped asynchronous I/O has an important impact on the total job turnaround.... -- John D. McCalpin mccalpin@perelandra.cms.udel.edu Assistant Professor mccalpin@brahms.udel.edu College of Marine Studies, U. Del. J.MCCALPIN/OMNET
mcdonald@aries.scs.uiuc.edu (Doug McDonald) (02/06/91)
In article <1991Feb5.172529.11162@odin.corp.sgi.com> archer@elysium.esd.sgi.com (Archer (Mr. Slug) Sully) writes: >In <1991Feb5.020456.1119@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: > >* >*For general purpose sorts of computing that can normally be done on Unix >*you are quite right indeed, these days. But for special cases - >*real time stuff - it can still make a big difference. The point is that async IO >*wins when you simply CAN'T stop your computing (CPU use) to wait for >*a disk transfer. OR when you try to get the absolute most performance >*out of a machine running only ONE program (i.e. a Cray doing >*a weather simulation.) >* >* > >Have you actually done benchmarks and performance comparisons that prove >this? > Not exactly benchmarks and performance comparisons. The major use I had for this was in data collectiom using a PDP-11/73 to collect data from an interferometer to a disk file. This mechanical device had a 0.6 second period during which it pumped data into the computer and an alternate 0.2 second period during which the computer had to process the data and display it on the graphics screen of the computer. The CPU was occupied for about 80% of the time during the 0.6 second with actually taking data (40 microseconds to take data, stuff it into semiconductor memory, and perform the necessary sequencer calculations -- and 10 microseconds to sit in an idle loop waiting for the next data point, which had a few microseconds jitter.) The processing took about 0.17 second. Which left no time during which the computer could stop for a disk write. It had no problem, however, starting the disk transfer, which proceeded by DMA while the data collected. No comparison was possible because the thing simply could not have run without async IO. Not enough cycles. For "large calculation" style computing, comebody mentioned using two processes, shared memory, and semaphores. Sure. That is just simulating async IO and in the absence of really BAD context switch times will of course work fine. It is just somewhat messier. That you COULD benchmark. Doug McDonald
jlg@lanl.gov (Jim Giles) (02/06/91)
From article <1991Feb4.210853.22139@odin.corp.sgi.com>, by archer@elysium.esd.sgi.com (Archer (Mr. Slug) Sully): > [...] > Async i/o wins when the disk has very long seek time and slow transfer > rates. And it has to be slower than SCSI in order to win. All IMHO, > of course. You're tying yourself down within the spectrum of available hardware. The fastest SCSI disk you've ever seen will still be too slow to efficiently drive a _really_ fast CPU. Times change. Technology advances irregularly. If CPU speed outpaces mass storage speeds, asynchronous I/O becomes important. An Operating System which wants to last across several different machines and over a long time period should include (hooks at least) for asynchronous I/O. If you have hardware where such a thing doesn't gain - disable it. The user can go on blithly thinking it's there - and code accordingly. > [...] > Oh, its what he was talking about all right, it just doesn't make sense to > do it on the kind of disks and controllers we use today. Not _everyone_ uses the kind of disks and controllers you use. Yet, _everyone_ is being encouraged (sometimes forced) to use UNIX. The NSF won't fund non-UNIX software anymore, even though they'd often get better code if UNIX was _not_ used. People who are NSF funded can't choose the _best_ system for their needs - they must choose UNIX. J. Giles
archer@elysium.esd.sgi.com (Archer (Mr. Slug) Sully) (02/06/91)
In <13754@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
*From article <1991Feb4.210853.22139@odin.corp.sgi.com>, by archer@elysium.esd.sgi.com (Archer (Mr. Slug) Sully):
*> [...]
*> Async i/o wins when the disk has very long seek time and slow transfer
*> rates. And it has to be slower than SCSI in order to win. All IMHO,
*> of course.
*
*You're tying yourself down within the spectrum of available hardware.
*The fastest SCSI disk you've ever seen will still be too slow to
*efficiently drive a _really_ fast CPU. Times change. Technology
*advances irregularly. If CPU speed outpaces mass storage speeds,
*asynchronous I/O becomes important. An Operating System which wants
*to last across several different machines and over a long time period
*should include (hooks at least) for asynchronous I/O. If you have
*hardware where such a thing doesn't gain - disable it. The user
*can go on blithly thinking it's there - and code accordingly.
*
One of the peripherals specialists was telling me the other day that
SCSI ends up being far more efficient than IPI for the transfer sizes
used by most systems.
*> [...]
*> Oh, its what he was talking about all right, it just doesn't make sense to
*> do it on the kind of disks and controllers we use today.
*
*Not _everyone_ uses the kind of disks and controllers you use. Yet,
*_everyone_ is being encouraged (sometimes forced) to use UNIX. The
*NSF won't fund non-UNIX software anymore, even though they'd often
*get better code if UNIX was _not_ used. People who are NSF funded
*can't choose the _best_ system for their needs - they must choose
*UNIX.
*
UNIX doesn't dictate or limit the utilization of hardware. Plus many
UNIX systems these days allow (easily) the implementation of in user
level code of features that formerly had to be in the kernel. I say
this with a fair degree of confidence after implementing async i/o and
a driver for a vme device purely in user code, without adding any kernel
support.
SVR4 and OSF (Mach) both have all of the necessary hooks to support
async I/O from user level code. Many versions of SVR3 have had the
necessary support added.
The biggest problem for UNIX right now is that there are too many people
clammering for NEW! IMPROVED!!! features to be added to an already bloated
system.
--
"The only problem with poetic justice is that it doesn't know when to quit"
-- Barry Hughart
<archer@sgi.com> Archer Sully davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (02/07/91)
In article <1991Feb5.172529.11162@odin.corp.sgi.com> archer@elysium.esd.sgi.com (Archer (Mr. Slug) Sully) writes: | Have you actually done benchmarks and performance comparisons that prove | this? You can do this as a "thought experiment." I previously said that AsIO is a win when CPU and IO time are roughly equal. Let's consider a program which runs 90 sec CPU, and 60 sec IO. Without async IO the job runs 90+60=150 sec. With AsIO it runs 90 (more or less). Since UNIX buffers write to disk files, all output of that type is AsIO, and that's why some programs run much faster in UNIX than DOS on the same hardware. Some versions of UNIX also do read ahead on input, making that AsIO, too. And some versions of UNIX allow the user to request AsIO explicitly. AsIO is standard on output in all UNIX versions and available for input or explicit user call for a number. Another strawman. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "I'll come home in one of two ways, the big parade or in a body bag. I prefer the former but I'll take the latter" -Sgt Marco Rodrigez
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (02/07/91)
In article <13754@lanl.gov> jlg@lanl.gov (Jim Giles) writes: | Not _everyone_ uses the kind of disks and controllers you use. Yet, | _everyone_ is being encouraged (sometimes forced) to use UNIX. The | NSF won't fund non-UNIX software anymore, even though they'd often | get better code if UNIX was _not_ used. People who are NSF funded | can't choose the _best_ system for their needs - they must choose | UNIX. UNIX isn't the best solution, it's the only solution. Or is there another o/s which runs on multiple hardware and vendor platforms? NFS has a requirement to be able to move software to other platforms, and I don't see any competition. The golden rule: "he who has the gold, rules." If NFS pays for it they get their needs satisfied first. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "I'll come home in one of two ways, the big parade or in a body bag. I prefer the former but I'll take the latter" -Sgt Marco Rodrigez
bsy+@cs.cmu.edu (Bennet Yee) (02/07/91)
In article <1991Feb5.020456.1119@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: (DM2) >In article <1991Feb4.210853.22139@odin.corp.sgi.com> archer@elysium.esd.sgi.com (Archer (Mr. Slug) Sully) writes: (AS) >>In <1991Feb4.154607.8606@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: (DM1) DM1>.... The most general method means that you call a system DM1>subroutine with a pointer parameter to a buffer, and a file descriptor of DM1>some sort, and a size, and a function pointer to a "completion routine". DM1> DM1>YOUR PROGRAM CONTINUES RUNNING. IT DOES NOT BLOCK. AS>I've implemented this in UNIX ..., it wasn't an AS>improvement over the normal file system. Performance differences ranged AS>from a 1% gain to a 5% loss on real life code. Generally we found that AS>when accessing a file sequentially the kernel did a better job of figuring AS>everything out than the program itself could. ... DM2>For general purpose sorts of computing that can normally be done on Unix DM2>you are quite right indeed, these days. But for special cases - DM2>real time stuff - it can still make a big difference. The point is that DM2>async IO wins when you simply CAN'T stop your computing (CPU use) to wait DM2>for a disk transfer. OR when you try to get the absolute most performance DM2>out of a machine running only ONE program (i.e. a Cray doing DM2>a weather simulation.) It seems to me that this computation model is not that good. It's sort of continuation style, but not really. A better one, perhaps, is one where your task has two (or more) threads, of which one can be CPU bound and the other handle your (slow) disk I/O, blocking if nec'y. It's more general, and the kernel does NOT have to understand the calling conventions of your language implementation to invoke the completion routine. To emulate the style advocated by DM, the I/O thread is just created at the call and terminated after it invokes the completion routine. Another possible method would be more Unix-y, with signals to indicate I/O completion. Hardware jocks may like the signals more tho, cuz of the analogy to interrupts. The signal handler is your completion routine. This is inferior in that you need to either disambiguate or have a different signal per outstanding I/O request. [ Isn't this newsfroup supposed to be moderated or something? Is SOFTWARE architecture really appropriate? Would the moderator care to comment? Should this entire thread be moved to comp.unix, comp.os.research, or maybe alt.religion.os.flame.war? ] -bsy -- Bennet S. Yee, +1 412 268-7571 School of Cucumber Science, Cranberry Melon, Pittsburgh, PA 15213-3890 Internet: bsy+@cs.cmu.edu Uunet: ...!seismo!cs.cmu.edu!bsy+ Csnet: bsy+%cs.cmu.edu@relay.cs.net Bitnet: bsy+%cs.cmu.edu@carnegie
Bruce.Hoult@bbs.actrix.gen.nz (02/07/91)
Jim Giles writes: >An Operating System which wants >to last across several different machines and over a long time period >should include (hooks at least) for asynchronous I/O. If you have >hardware where such a thing doesn't gain - disable it. The user >can go on blithly thinking it's there - and code accordingly. Interesting you should say that, because that's almost exactly the situation on the Macintosh. The Mac file manager has always had async i/o, and it actually *does* async i/o with floppy disks, serial ports, appletalk, and network mounted disks (such as AppleShare). You can code async i/o for local hard disks, but the current SCSI manager (for reasons known only to Apple) actually performs it synchronously. I'm not, of course, arguing that async i/o on SCSI disks wouldn't be nice (and SCSI has provision for it), but just that you can code for it now, and it will work when/if it becomes available. -- Bruce.Hoult@bbs.actrix.gen.nz Twisted pair: +64 4 772 116 BIX: brucehoult Last Resort: PO Box 4145 Wellington, NZ "And they shall beat their swords into plowshares, for if you hit a man with a plowshare, he's going to know he's been hit."
mcdonald@aries.scs.uiuc.edu (Doug McDonald) (02/08/91)
In article <1991Feb6.175555.18281@cs.cmu.edu> bsy+@cs.cmu.edu (Bennet Yee) writes: >In article <1991Feb5.020456.1119@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: (DM2) [I describe one version of async IO] >It seems to me that this computation model is not that good. Really, ist is just fine. > >A better one, perhaps, is one where your task has two (or more) threads, of >which one can be CPU bound and the other handle your (slow) disk I/O, >blocking if nec'y. It's more general, and the kernel does NOT have to >understand the calling conventions of your language implementation to invoke >the completion routine. > >To emulate the style advocated by DM, the I/O thread is just created at the >call and terminated after it invokes the completion routine. > Yep, that is just fine too, and nicely extensible. > >[ Isn't this newsfroup supposed to be moderated or something? No. Doug McDonald
fetter@cos.com (Bob Fetter) (02/12/91)
In article <1652@hpwala.wal.hp.com> lupienj@hpwadac.UUCP (John Lupien) writes: >In article <13252@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >>How about reconnect (you know, my modem drops off in the middle of a job >>and I want to sign on and reconnect to the job)? Oh, UNIX automatically >>kills jobs when connection fails except when the job is 'nohup'ed - but, >>even then, you can't reconnect: the only thing you can do with a >>'nohup'ed job from a _different_ terminal session is kill it. > >Yes, that is the way I want it. This is a very good thing. I do not want >Mr. Giles to be able to dial up and reconnect to my process. I'd rather >have it die (gracefully or otherwise) than risk having someone else gain >access to my process, which may well be running as me. Since DOS has no >protection features at all, I can understand why this issue is lost on >Mr. Giles, who is trying to make ignorance a virtue. Well, the issue of reconnection to disconnected processes is still a good one (IMHO). In that there is a (very valid) security concern as to leaving the process directly tied to the dial-in line, the question comes to mind as to why a disconnected process (process group) *should* remain tied to the dial-in line if 'nohup'ed. On Multics, it was possible to set a process attribute "reconnect_ok", which would mark a process as one to be preserved if a line disconnect occurred. Now, this preservation would *not* keep the association of the communication line <--> process, but would mark the process as 'disconnected', placing it in a suspended state *and freeing the communication line for other use*. If the user logged back on the system within a site-configurable period of time, then *after* the UserId/Password validation, they would be told that there were (N) disconnected processes (if there were any) and be given the option to reconnect, start a new login process (not affecting the disconnected one(s)), etc. BTW - after the site-selected time was reached for a disconnected process, it would be reaped, freeing up whatever resources was being used (memory, etc). For Unix, I would think that this would require the ability to reassign what would be the base /dev/tty for a 'disconnected' process (group) if reconnection was requested. This above senario removes the security aspect, as the user must be re-established (userid/password) *prior* to any reconnection being allowed. Is there anything like this in the Unix world today? I would guess that there would be a need to collectively tie together all processes which were children of the initial login 'process' and treat them as a 'group', so that reassociation of them as a unit to a new /dev/tty could be accomplished. Or is this something currently deemed "not a good thing" by the community? -Bob-
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (02/12/91)
In article <43615@cos.com> fetter@cos.UUCP (Bob Fetter) writes:
[ reconnect under UNIX? ]
acf3% telnet kramden
Trying...
Connected to KRAMDEN.ACF.NYU.EDU.
Escape character is '^]'.
SunOS UNIX (kramden)
login: brnstnd
Password:
[ random login notices, deleted from this script ]
session p1 sigler 2768 master 1380 slave 1381
session p1 disconnected
Reconnect to session (return to ignore): p1
reconnect: p1 set, will reconnect after p3 drops
pty: reconnecting to /dev/ttyp1
pty: successfully reconnected to /dev/ttyp1
kramden% jobs
[1] + Stopped rn
kramden%
[ now I type ^] and disconnect ]
telnet> quit
Connection closed.
The modem connection conveniently died while I was typing this article,
so I dialed back in, logged into a different machine, made the above
typescript, and then reconnected again to finish typing.
Here's what my .login does to perform these dastardly deeds:
sesslist
sesslist | grep -s disconnected \
&& ( echo -n 'Reconnect to session (return to ignore): '; \
set reconnect="$<"; \
if ( a"$reconnect"b != ab ) exec sess reconnect "$reconnect"; \
)
The pty package (which includes sess, reconnect, etc.) should work
without too much angst on any BSD-based system; I'm willing to port it
to any machine I can get my hands on. I just completed draft 9 of
``The Design, Implementation, and Use of a Pseudo-Terminal Manager,''
which describes the pty interface (and lots of gory BSD tty bugs) in
detail, and illustrates some neat tricks (like suddenly deciding to
record a talk session already in progress) that you simply can't do
under most systems with reconnect facilities. The package is available
via anonymous ftp from 128.122.128.22; the paper is available from me
directly.
---Dankenw@skyler.arc.ab.ca (Ken Wallewein) (02/13/91)
In article <43615@cos.com> fetter@cos.com (Bob Fetter) writes: > Well, the issue of reconnection to disconnected processes is still a > good one (IMHO). > > ... > > On Multics, it was possible to set a process attribute > "reconnect_ok", which would mark a process as one to be preserved if a > line disconnect occurred. Now, this preservation would *not* keep the > association of the communication line <--> process, but would mark the > process as 'disconnected', placing it in a suspended state *and > freeing the communication line for other use*. > > If the user logged back on the system within a site-configurable > period of time, then *after* the UserId/Password validation, they > would be told that there were (N) disconnected processes (if there > were any) and be given the option to reconnect, start a new login > process (not affecting the disconnected one(s)), etc. > BTW - after the site-selected time was reached for a disconnected > process, it would be reaped, freeing up whatever resources was being > used (memory, etc). > > ... > > This above senario removes the security aspect, as the user must > be re-established (userid/password) *prior* to any reconnection being > allowed. > > Is there anything like this in the Unix world today? I would guess > that there would be a need to collectively tie together all processes > which were children of the initial login 'process' and treat them as a > 'group', so that reassociation of them as a unit to a new /dev/tty > could be accomplished. Or is this something currently deemed "not a > good thing" by the community? > > -Bob- I don't know about Unix, but it has been in VMS for some time. Works rather nicely. You know, Bob, it's a bit amusing, the number of "OS experts" who pompously debate their preconcieved versions of techniques (like shells that know command syntax) without bothering to see how it's already done on (gasp) non-Unix OSes. /kenw -- /kenw Ken Wallewein A L B E R T A kenw@noah.arc.ab.ca R E S E A R C H (403)297-2660 C O U N C I L
tom@stl.stc.co.uk (Tom Thomson) (02/14/91)
>Async i/o wins when the disk has very long seek time and slow transfer >rates. And it has to be slower than SCSI in order to win. All IMHO, >of course. > >* >*JG has a several good points made. I can't be sure that the thing I explained >*above is EXACTLY what he wanted, but I'll bet it will satisfy him as an >*example. >* > >Oh, its what he was talking about all right, it just doesn't make sense to >do it on the kind of disks and controllers we use today. > Here we have Archer Sully demonstrating yet again that the JGs and Rubins of this world are absolutely correct when they claim the "standard Unix or nothing" brigade have nothing to offer to us on software architecture. Mr Sully wants to put synchronous IO in my way, ie conceal from me the fact that the hardware allows IO and processing to procede in parallel; he claims that with today's discs it isn't needed. I suggest he goes and tells that to all the independent database vendors who spend so much effort in getting round this particular piece of Unix stupidity in their Unix ports. Perhaps he can afford for the machine to sit idle for 10 ms every time he moves the disc heads - he maybe has never been involved in a time-critical or performance-critical application. Or maybe he has some discs I haven't heard about yet - with seek and head settle time plus half a revolution coming out way below 10 ms? Or maybe he thinks the level of multiprogramming is so high that performance in one process (elapsed time for one process) doesn't matter at all (in every conceivable application)? Or maybe all IO is serial, so the OS can predict where the next block will be and do the transfer in advance (I'd like to see it do that for writes, mind; would make data consistency a little difficult)? In the real world, asynchronous disc io is a necessity. Fortunately IO hardware design hasn't got as bad as processor design - - no-one is yet proposing to stop the CPU running whenever an IO device has been asked to do a transfer just because Unix (and Cobol, and a few more) impose that view on the poor benighted user. Tom Thomson
tom@nw.stl.stc.co.uk (02/14/91)
In article <3177@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: >UNIX writes usually overlap CPU, since the system buffers them. Async >makes little difference in run time for an i/o bound job or a CPU bound >job, it's only in the case where i/o and CPU time are roughly equal that >a major improvement is seen. >-- >bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) Might as well point out the several problems with this: (i) buffering writes in the OS means I don't know when a transfer has terminated. That's a real pain if I'm trying to maintain some sort of consistency and recoverability for the data. (ii) buffering writes in the OS means an extra copy. Usually lots of extra slave misses, waste cache space, etc, as well as waste store and bus bandwidth; we can't always afford to throw away performance like this. (iii) Async io can make enormous differences in run time for io bound jobs - bd's conventional "wisdom" is an example of the rubbish that so-called software architects have foisted off on an unsuspecting world as knowledge. It's simple, really: if I am reading from 5 different discs, I can overlap the seek times, search times, and even channel times if they are split over two or more channels. Without asynch IO I can't get any of this overlap - the parallelism between discs, between controllers, and between channels has been stolen from me. So async io gives me maybe a 5 times speed up fro this hypothetical five disc job, if it's io bound. (iv)The speed up for cpu bound jobs may be less spectacular, but it's there; if some elapsed time is critical, a 1% reduction may matter. The argument is crazy anyway: BD is suggesting that because I'm CPU bound I can afford to use synchronous IO and let the CPU stand idle while I wait for some macroscopic mechanical events - chuck away some of precisely that resource I'm short of. Tom Thomson
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (02/14/91)
In article <4033@stl.stc.co.uk> tom@nw.stl.stc.co.uk writes: | (i) buffering writes in the OS means I don't know when a transfer has | terminated. That's a real pain if I'm trying to maintain some sort of | consistency and recoverability for the data. True. Ordered write and wait for io cover this. Async i/o by itself doesn't help, and may hinder on this problem, since the order of completion of async i/o is indeterminate. You have to wait for completion (sync) at intervals. | (ii) buffering writes in the OS means an extra copy. Usually lots of extra | slave misses, waste cache space, etc, as well as waste store and bus bandwidth; | we can't always afford to throw away performance like this. What you say is true, as long as the "always" is noted. The price for async i/o is twofold; in code complexity and in that you have to buffer the data in the block size used by the hardware. There are cases where the hardware is marginal for the task, and this makes sense. In general programs may not find it convenient to do i/o in sector size, particularly since that means changing the code depending on which disk is being used, or using a fairly large buffer. It also should be noted that the overhead of the user moving stuff into a buffer is probably a lot higher than the library routines making a call and passing a buffer of fairly large size to the o/s. And that if the hardware supports it the buffer may not be copied, but simply dropped from the user's address space, to be copied and remapped if the user program accesses it before the i/o is complete. So in many cases the larger part of the overhead is still present. The summary of my answer to this is that the savings may not justify the effort, and that the copy by the o/s helps the realtime performance greatly, while using very little processor. I typically see 4-7% system cpu usage on my UNIX systems, so that's the upper bound on what I could save (on those systems). | (iii) Async io can make enormous differences in run time for io bound jobs - | bd's conventional "wisdom" is an example of the rubbish that so-called software | architects have foisted off on an unsuspecting world as knowledge. It's simple, | really: if I am reading from 5 different discs, I can overlap the seek times, | search times, and even channel times if they are split over two or more | channels. Without asynch IO I can't get any of this overlap - the parallelism | between discs, between controllers, and between channels has been stolen from | me. So async io gives me maybe a 5 times speed up fro this hypothetical | five disc job, if it's io bound. This is true if you are designing a system for running a single job which reads from five disks. That's not typical. By the time a system gets to be large enough to have five drive, it's unlikely to have only a single job running. While you could save something if you could get the whole resources of the machine, under load you would wait long enough for the i/o to be queued that you might not see any improvement at all. See below for comments on special cases. | (iv)The speed up for cpu bound jobs may be less spectacular, but it's there; | if some elapsed time is critical, a 1% reduction may matter. The argument is | crazy anyway: BD is suggesting that because I'm CPU bound I can afford to use | synchronous IO and let the CPU stand idle while I wait for some macroscopic | mechanical events - chuck away some of precisely that resource I'm short of. You can always come up with a special case to justify anything. Vendors will sell you solutions to these special cases, but why try to convince people that the solutions to atypical problems need to be thrust upon the average user? This was originally a discussion of the hypothetical shortcomings of UNIX i/o, and since there are versions which allow async i/o, and versions which have lightweight processes, and versions which allow shared memory (so a another process can issue the i/o into your buffers), I think solutions are clearly available for UNIX. I spent a decade programming on systems which did async i/o, and all the users used routines which made it look just like traditional UNIX, because non-programmers don't think clearly about multiple threads. Sure, when I wrote the device interface I had three printers, a punch, and a card reader, with a total of six buffers for all of them, and smooth shift from double buffering to single buffering as the number of devices in use increased, but the users didn't know or care about it. And even the kernel hackers thought it was a bit complex ;-) -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "I'll come home in one of two ways, the big parade or in a body bag. I prefer the former but I'll take the latter" -Sgt Marco Rodrigez
pcg@cs.aber.ac.uk (Piercarlo Grandi) (02/15/91)
On 13 Feb 91 20:38:27 GMT, tom@stl.stc.co.uk (Tom Thomson) said: tom> Here we have Archer Sully demonstrating yet again that the JGs and tom> Rubins of this world are absolutely correct when they claim the tom> "standard Unix or nothing" brigade have nothing to offer to us on tom> software architecture. Well, the usual ones don't; but Mach for example has something to offer, even if it is not Unix (just like most decent Unix implementations for modern machines, it emulates Unix quite closely). tom> Mr Sully wants to put synchronous IO in my way, ie conceal from me tom> the fact that the hardware allows IO and processing to procede in tom> parallel; he claims that with today's discs it isn't needed. This is 80% true, i.e. billjoysm. It is a true that the optimal multiprogramming level is N+M, where N is the number of CPUs and M is the maximum number of concurrent IO operations, and that on common timeshared machines N+M is rarely larger than 4, so that even a small degree of timesharing will achieve optimal *overall* thruput. tom> I suggest he goes and tells that to all the independent database tom> vendors who spend so much effort in getting round this particular tom> piece of Unix stupidity in their Unix ports. But database people have a very particular problem: their databases are, in effect, OSes in their own right, and have their own scheduler, disk access subsystem, and so. The problem they have is that the virtual machine or process in which they run gets blocked by the underlying OS in its entirety, because the underlying OS has no notion of the fact that it is running multiple database threads. This happens for IO, but also for paging, and signaling, and so on. Why do database choose to reimplement almost all the facilities of an OS in the batabase server? For *portability*. tom> Perhaps he can afford for the machine to sit idle for 10 ms every tom> time he moves the disc heads - he maybe has never been involved in tom> a time-critical or performance-critical application. But during that time another Unix process will be scheduled, and overall system thrupu will not be impacted. Note that Unix IO *is* asynchronous, as seen by UNIX systems. The problem that people have is that it is not asynchronous with respect to one of the threads inside a database server. But this is a problem with *both* the database server *and* Unix; the problem with database servers is that they are implemented as monolithic OS reimplementations, and the problem with Unix is that it does not make it efficient or easy to have database servers implemented any other way. Since Unix is not the only operating system around that supports only the monolithic program model, *portability* demands that vendors that want to port their server to a variety of platforms assume it as minimum common denominator. Too bad. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
pcg@cs.aber.ac.uk (Piercarlo Grandi) (02/15/91)
On 13 Feb 91 21:16:38 GMT, news@stl.stc.co.uk (News admin c/o dww) said:
news> In article <3177@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com
news> (bill davidsen) writes:
davidsen> UNIX writes usually overlap CPU, since the system buffers
davidsen> them. Async makes little difference in run time for an i/o
davidsen> bound job or a CPU bound job, it's only in the case where i/o
davidsen> and CPU time are roughly equal that a major improvement is
davidsen> seen.
True, but only true for the 80% of cases where you have a sufficiently
high multiprogramming level at the Unix process level.
news> Might as well point out the several problems with this:
news> (i) buffering writes in the OS means I don't know when a transfer
news> has terminated.
This is an easily remedied deficiency. It has been remedied, with things
like fsync(2). Badly, let me add, but it has been remedied.
news> (ii) buffering writes in the OS means an extra copy.
Another easily remedied deficiency. Virtual memory helps a lot here.
news> (iii) Async io can make enormous differences in run time for io
news> bound jobs - bd's conventional "wisdom" is an example of the
news> rubbish that so-called software architects have foisted off on an
news> unsuspecting world as knowledge. It's simple, really: if I am
news> reading from 5 different discs, I can overlap the seek times,
news> search times, and even channel times if they are split over two or
news> more channels.
This can be easily achieved under Unix if you arrange your application
as five separate processes. Unix will overlap IO from different
processes. I readily concede that this may be abominably complicated
and inefficient in most current implementations. But the right solution
is not to add asynchronous IO to a single process, it is to make
splitting an application into multiple processes easy and efficient.
This means that what (most) software architects have foisted upon you is
not the lack of async IO, which is a poor hack in response to a
bogosity; it is the lack of suitable OS level abstractions, and o
efficient implementations of these.
The specific bogosity is the lack of multithreading, and this is one of
the consequences of having a monolithic program/process model, straight
out of the sixties (early sixties, because in the late sixties there was
Multics, at least). Adding asynchronous IO just perpetuates this ancient
and inappropriate architecture.
All your concerns are resolved, in the right way, without the
complications and insecurities of asynchronous IO, if you can have
proper multithreading, especially with threads that can move among
address spaces, and lightweight and persistent address spaces. Second
best is proper multithreading with efficient lightweight IPC among
address spaces.
Architecture is all about providing minimal and orthogonal abstractions,
so that you get decomposability and reusability, and thus efficient and
flexible system. Monolithic programs/processes, whether connected by
(inefficient) glue like pipes or sockets, or "enriched" with ad hoc
extensions ike asynchronous IO, are a poor abstraction.
--
Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uklamaster@pioneer.arc.nasa.gov (Hugh LaMaster) (02/15/91)
In article <3200@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: >In article <4033@stl.stc.co.uk> tom@nw.stl.stc.co.uk writes: >| (iii) Async io can make enormous differences in run time for io bound jobs - > This is true if you are designing a system for running a single job >which reads from five disks. That's not typical. By the time a system >gets to be large enough to have five drive, it's unlikely to have only a >single job running. While you could save something if you could get the Actually, jobs like this are very, very typical in our environment. As CPU speed increases, all those CPU bound jobs turn into I/O bound jobs (not an original thought on my part :-) ). Your second observation usually applies during the daytime. Often at night, even modest minicomputers and servers are used to run long jobs. Often, these jobs are I/O bound. > You can always come up with a special case to justify anything. True. But, this is not really a question of a special case. Anyone using a system for "data processing" applications, as opposed to "text processing", terminal/screen/user-interface/etc. processing, runs up against the fact that disks are, and have always been, slow, when doing *random* I/O. It is amusing to see that what were always considered the traditional uses of computers are now considered "special cases". But, that is only true if you approach computing from a text-processing viewpoint. What is, in fact, happening, is that Unix machines, once considered suitable *only* for text processing, have now "grown up", and are being used for data processing as well: including scientific data processing, image processing, transaction processing, general DBMS uses, etc. For many of these purposes, asynch. I/O is important. > This was originally a discussion of the hypothetical shortcomings of >UNIX i/o, and since there are versions which allow async i/o, and I agree. There are now versions of Unix which have async I/O. These versions were made available because a lot of mainstream computer users needed it. More versions of Unix will include async I/O in the future. (Is this prophecy?) > I spent a decade programming on systems which did async i/o, and all >the users used routines which made it look just like traditional UNIX, >because non-programmers don't think clearly about multiple threads. Your users must be different from our users. Many of our users have always been intensely interested in optimizing programs for both CPU time and I/O time, and have often gone to considerable lengths to write their programs to be very efficient wrt I/O, including the use of async I/O as appropriate. ******* Fault tolerance, an O/S issue or an Architecture issue? ************ To follow up on Jim Giles original posting: It is an open question as to whether what used to be called "recovery of rolled jobs", "user checkpointing", etc. really makes sense anymore. It was a good idea when the MTBF of a CPU was four hours, and we had on-site C.E.'s to fix the hardware in a hurry. With MTBF's of *months* on many systems, I'm not sure it is a good idea. How many people frequently have a long running job die in a hardware related crash now? How many of those jobs hadn't modified any files yet? There are a lot of subtleties to doing it right. And, to provide *real* fault tolerance, if you need it, *is* a major hardware/software/architectural issue. Hugh LaMaster, M/S 233-9, UUCP: ames!lamaster NASA Ames Research Center Internet: lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 With Good Mailer: lamaster@george.arc.nasa.gov Phone: 415/604-6117
jlg@lanl.gov (Jim Giles) (02/15/91)
From article <1991Feb14.195906.5726@news.arc.nasa.gov>, by lamaster@pioneer.arc.nasa.gov (Hugh LaMaster): > [...] > It is an open question as to whether what used to be called "recovery of > rolled jobs", "user checkpointing", etc. really makes sense anymore. It > was a good idea when the MTBF of a CPU was four hours, and we had on-site > C.E.'s to fix the hardware in a hurry. With MTBF's of *months* on many > systems, I'm not sure it is a good idea. How many people frequently have > a long running job die in a hardware related crash now? [...] Admittedly, this is not very frequent. However, the machine may go down for _scheduled_ maintenence of dedicated time on a daily basis. Automatic crash recovery is an important feature of the system which allows the systems people to bring the machine down at will and not lose anything belonging to the users (except time). > [...] How many of those > jobs hadn't modified any files yet? [...] On our system, NONE of the dropfiles are out of sync with their I/O. The dropfile is the system's swap image - if this even _can_ be out of sync with the files open to the process, not even the system would be able to safely use them. That's the advantage of dropfiles: they make a feature, that the system is already providing, directly available to the user. They are updated every time the program swaps. They can be left behind as restartable images after the program fails - just patch the cause of the failure and restart it. They don't require extra disk space since the system has to allocate space for a swap image anyway. J. Giles
fetter@cos.com (Bob Fetter) (02/15/91)
In article <KENW.91Feb12142939@skyler.arc.ab.ca> kenw@skyler.arc.ab.ca (Ken Wallewein) writes: > You know, Bob, it's a bit amusing, the number of "OS experts" who >pompously debate their preconcieved versions of techniques (like shells >that know command syntax) without bothering to see how it's already done on >(gasp) non-Unix OSes. That's interesting, in that I've had similar feelings. While I've fallen into the trap before of believing in a "one true OS", and I can understand the alure of it, more importantly I can now see the value in *contrast* and *alternative solutions* one only really sees in different OSes. To me, Unix is one of those "different OSes". Hey, I'm just as bigoted as the next guy in having what I think is "the best solution", and I'll even argue myself into a corner on occasion on a topic or two but, when the dust settles, I find that I've learned something (on occation in spite of myself). Keep in mind, though, that I (and probably you) have an advantage, in that I've had a chance to work within and watch the computer industry grow from tab shops through batch through timesharing into PCs and workstations. I used to think that nobody really *knew* programming until they had to debug assembler using a front panel -- nowadays I find that I'm really hurting without a decent symbolic debugger (and one that understands unions at that!). Huh. Me, an old fart at 37. Who would'a thunk it? Having been an OS kernal hacker for a while (non-Unix), I can understand the methods and means used in the Unix community today (to an extent -- some of it is beyond what I was involved with then), but still, some of the basic ideas, like async i/o, conserving context switches, dynamic reallocation of i/o_assignments, working with mapped segmented memory, shared libraries/dynamic linking, etc., doesn't *seem* new (I remember these things from the middle 70s), but appears new in the Unix arena. Ok, maybe not "new", but surely not "standard" in Unix product releases. But, hey, who can expect everyone to know of everything done earlier? Major things, sure, I can hope that they aren't lost. But "minor" things like command line syntax parsing? Hey, that's a religion. We all have our biases on that (boy, would I have fun writing the "one true shell", and boy, would nobody use it but me, but I digress). But stuff like "hey, we can do run time linking now, and so Unix is again 'state of the art'" just gives me a case of the smiles. But, now its a standard -- POSIX -- so I really should just deal with things as they are, work towards injecting what I can that I have worked with in the past that "was good", and do what's important: use the system as a tool to provide solutions to problems. And, there *is* a whole lot of -->new and improved things<-- in the Unix environment coming out nowadays. So, the world maybe doesn't always get better, but it sure does keep getting more interesting. [Soliloquy mode off -- maybe the above is nothing earth shaking, but it sure feels good sitting here and saying it] -Bob-
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (02/15/91)
In article <14696@lanl.gov> jlg@lanl.gov (Jim Giles) writes: [ dropfiles ] > They don't require extra disk space > since the system has to allocate space for a swap image anyway. This is another Jimism that I'm getting sick of hearing again and again. If you have a machine with N bytes of memory, forced dropfiles waste N bytes of disk space. This will remain true no matter how many times Jim insists otherwise. Dropfiles also make the system much slower in the common case that you don't do much swapping. Would it be useful for processes to survive through crashes? Maybe. I just don't want to slow my system down and waste 16 or 128 megabytes of disk space to get that reliability. If a user thinks his computation is truly critical, he can easily checkpoint it himself, wasting a lot less memory and time than forced swaps ever will. ---Dan
bwhite@inmet.inmet.com (02/16/91)
In a note from Feb 11, 1991 by fetter@cos.com: > ... Long discussion of why disconnect/reconnect is valuable ... > Is there anything like this in the Unix world today? I would guess > that there would be a need to collectively tie together all processes > which were children of the initial login 'process' and treat them as a > 'group', so that reassociation of them as a unit to a new /dev/tty > could be accomplished. Or is this something currently deemed "not a > good thing" by the community? > > -Bob- Actually, there is a program which does something like this. It is called screen. I use it as a sort of poor-man's windowing system. It is really quite clever. It allows one to manage several virtual terminals simultaneously. For instance, I am running vi to write this note, but on another virtual screen I have emacs running waiting for me to get back to the paper I'm writing. When I leave this evening, I will disconnect my screen process and recover it at home. It even works when I go from my current 9600 baud connection to my 1200 home connection. (If I log in from home, disconnect and reconnect at work, some parameter is not set properly, and the screen is jerky. I suspect that some pty somewhere is set to 1200 baud internally, that is causing something to throw pauses in for tabs and new lines, but I don't know exactly.) This program can be obtained from uunet.uu.net, but I don't know where. Peace, Bill White <bwhite@inmet.inmet.com>
torek@elf.ee.lbl.gov (Chris Torek) (02/16/91)
(I have no idea what all this is doing in comp.arch, but I have no better place to put it, so I will try to keep this short...) In article <43686@cos.com> fetter@cos.UUCP (Bob Fetter) writes: > But, now its a standard -- POSIX -- so I really should just deal >with things as they are, work towards injecting what I can that I have >worked with in the past that "was good", and do what's important: use >the system as a tool to provide solutions to problems. This is a fine sentiment. There is, however, a trap lying in wait: things that `were good' are not necessarily good in all contexts. Indeed, one of the problems with this whole pro/anti Unix flamefest here in comp.arch is that many of the points made for and against various features make implicit assumptions as to the surrounding system. To put it another way, a system (whether it be Unix, VMS, NOS, TSO, VSPC, CP/M, ...) is not just made up of a series of parts, but also of a set of interactions.% In particular, Unix `parts' tend to have different interactions than most other systems. ----- I.e., the whole is, as always, the sum of the parts plus their exact positions and momenta. :-) -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
tom@nw.stl.stc.co.uk (02/19/91)
> But, now its a standard -- POSIX -- so I really should just deal
Yeah, great, it's a standard.
But the standard explicitly says that you can still claim conformance even
if you don't provide any of the things specified in it - - all you have to
do is deliver "not supported" error codes.
The reason it's like that is that the "if fewer that 99.95% of Unix
workstation users will be totally prevented from making progress if
the system won't do it, then it would be criminal to include it" people
are still getting their way. Pity, isn't it. Posix could have meant
something.
Tombrnstnd@kramden.acf.nyu.edu (Dan Bernstein) (02/19/91)
In article <2983:Feb1213:30:1791@kramden.acf.nyu.edu> I foolishly wrote: > I just completed draft 9 of > ``The Design, Implementation, and Use of a Pseudo-Terminal Manager,'' [ ... ] > the paper is available from me > directly. The paper is available as pub/hier/pty/paper.9 on 128.122.128.22. Sorry I can't respond to everyone individually; my keyboard's warranty doesn't last that long. :-) ---Dan