jxf@altair.cis.ksu.edu (Jerry Frain) (01/16/91)
[ Note: subject was changed because this thread is inappropriately named ] heksterb@Apple.COM (Ben Hekster) writes: > Have you ever >experienced mouse operations in preemptive multitasking environments? My >experience with X Window on high-performance workstations (various window >managers), for instance has been that feedback is frequently so *awful* >(intermittent, or no reaction to mouse movements at all for periods on the >order of many seconds) as to make complicated interactions extremely >difficult. (No flame on X intended, just an observation on the workstation >environment) I always find this argument quite humorous, since I do all of my work at work on a Sun workstation using X, while I do all of my work at home on a Mac SE/30. I really have no problems with mouse/pointer movement on the Sun workstation I use at work. If there are fewer than ninety existing processes, and four or more actually wanting to do something at that time, then I may start to feel it. I just renice my X server, and everything is fine until the load climbs up quite a bit more. Shove a floppy in your disk drive on your Mac and move your mouse around and tell me how your Mac is *so* responsive (IIfx owners may be exceptions to this test). My point is, a preemptive scheduler on a single-user system is really not a problem -- at least no more than cooperative, especially when an intelligent scheme is used to assign priorities properly. Regards, --Jerry -- Jerry Frain -- Systems Programmer Kansas State University Department of Computing & Info Sciences Internet : jxf@cis.ksu.edu Manhattan, Kansas UUCP : ...!rutgers!ksuvax1!jxf
heksterb@Apple.COM (Ben Hekster) (01/17/91)
I wrote: > Have you ever > experienced mouse operations in preemptive multitasking environments? My > experience with X Window on high-performance workstations (various window > managers), for instance has been that feedback is frequently so *awful* > (intermittent, or no reaction to mouse movements at all for periods on the > order of many seconds) as to make complicated interactions extremely > difficult. (No flame on X intended, just an observation on the workstation > environment) jxf@altair.cis.ksu.edu (Jerry Frain) responds: > I always find this argument quite humorous, since I do all of my work > at work on a Sun workstation using X, while I do all of my work at home > on a Mac SE/30. > > I really have no problems with mouse/pointer movement on the Sun > workstation I use at work. If there are fewer than ninety existing > processes, and four or more actually wanting to do something at that > time, then I may start to feel it. I just renice my X server, and > everything is fine until the load climbs up quite a bit more. I find it surprising that you find my observation humorous. Being the sole interactive user on an HP 9000/400 (I think?) running X, and hpterm to emulate a non-graphic VT100-type terminal, response was often absolutely unbearable. Using this very terminal program from a mainframe VAX (no graphics involved, except on the Mac end) to write this article, I have feedback problems when scrolling, for instance. It may just be a question of throwing more raw processing power at it --which is what workstations are good at-- but I don't think the answer to the multitasking question is to make everyone buy IIfx-es. > Shove a floppy in your disk drive on your Mac and move your mouse around > and tell me how your Mac is *so* responsive (IIfx owners may be exceptions > to this test). I'm not sure I understand what point you're trying to make here. Presumably the assumption is that when a user inserts a disk, he wants to mount the volume, and at that time doesn't really care for his Mandelbrot background task to run for another 1000 iterations. Since the disk-mounting is alredy running at the highest priority possible (nothing is preempting it) I'm not sure I understand what good a preemptive scheduler would do here. The underlying premise is that getting the disk mounted as quickly as possible is more important than moving the mouse. > My point is, a preemptive scheduler on a single-user system is really > not a problem -- at least no more than cooperative, especially when an > intelligent scheme is used to assign priorities properly. It may or may not be a *problem* (compatibility issues have already been raised)--but that does not signify whether it is *desirable*. As an aside--how many of those ninety processes were running to support the multitasking? _______________________________________________________________________________ Ben Hekster | "I've had my fun Student intern | but now it's time AppleLink: heksterb | to serve your conscience Internet: heksterb@apple.com | overseas" BITNET: heksterb@henut5 | --Orange Crush, R.E.M. (Green)
jxf@orion.cis.ksu.edu (Jerry Frain) (01/17/91)
Before you read my article, let me just say that I _do_ like the Macintosh. I own one, and I like it. The important thing to keep in mind here is that there is _always_ room for improvement. If everyone was so against improvement, we (as a Mac community) would still be using Finder 1.0 on the original Mac. Now, if you are not completely bored and tired of endless discussion over the prospect of preemptive scheduling for the Mac, then please read on, otherwise hit "n" now. heksterb@Apple.COM (Ben Hekster) writes: >jxf@altair.cis.ksu.edu (Jerry Frain) responds: [ Ben complains about his mouse not moving fast on his workstation ] >> I always find this argument quite humorous, since I do all of my work >> at work on a Sun workstation using X, while I do all of my work at home >> on a Mac SE/30. >I find it surprising that you find my observation humorous. I was surprised that a person who has used a preemptive scheduling environment would not like it more than its cooperative counterpart. [ explanation of poor performance on HP 9000 workstation ] Sounds like your system needs to be reconfigured. Anything that has difficulty doing what you described ought to be fixed or junked. >> Shove a floppy in your disk drive on your Mac and move your mouse around >> and tell me how your Mac is *so* responsive (IIfx owners may be exceptions >> to this test). >I'm not sure I understand what point you're trying to make here. How about "mouse response on the Mac goes away during volume recognition." > Presumably >the assumption is that when a user inserts a disk, he wants to mount the >volume, and at that time doesn't really care for his Mandelbrot background >task to run for another 1000 iterations. I don't have a mandelbrot background. I have a mouse. Perhaps I have inserted the floppy so that I may copy a file to the floppy disk. Haven't you ever tried to open the folder that the file is in while the Mac is trying to figure out what the name of your disk is? The jerkiness of the mouse caused by volume recognition is just damn _unnecessary_, and irritating. > Since the disk-mounting is alredy >running at the highest priority possible (nothing is preempting it) I'm not >sure I understand what good a preemptive scheduler would do here. Gee, isn't that entirely against the philosophy of the Mac's cooperative scheduler? Isn't the interactive user supposed to get good response time *no matter what*? Your argument above is what most people use to argue *against* preemptive scheduling, the idea that the interactive user might not get prompt responses! You cannot tell me that during the time period that volume mounting is taking place, that the CPU is _really_ busy. Probably less than 1/1000 of the delay experienced is actually due to the fact that the CPU is too busy to move your mouse. > The underlying premise is that getting the disk mounted as quickly as >possible is more important than moving the mouse. I think that *both* mouse responsiveness and volume mounting should be provided at the same time. It can be done. Why do you not desire this? > As an aside--how many of those ninety processes were running to >support the multitasking? What? Are you kidding? The answer is "none." The scheduler is part of the operating system, which is not represented as a process. There are, at this very moment, 126 processes on this workstation I am posting from. Most of these processes (73) are concerned with network services provided by this machine. Nfs, yellow pages, etc. The rest of the processes (53) are user processes. There are currently six users logged on this machine. The responsiveness of my mouse pointer (or anything else for that matter) is instantaneous. Just like my Mac. Have a nice day. --Jerry -- Jerry Frain -- Systems Programmer Kansas State University Department of Computing & Info Sciences Internet : jxf@cis.ksu.edu Manhattan, Kansas UUCP : ...!rutgers!ksuvax1!jxf
heksterb@Apple.COM (Ben Hekster) (01/17/91)
jxf@orion.cis.ksu.edu (Jerry Frain) responds to my latest posting: > Before you read my article, let me just say that I _do_ like the Macintosh. > I own one, and I like it. Hey, I like workstations (although I don't own one). > The important thing to keep in mind here is that there is _always_ room > for improvement. If everyone was so against improvement, we (as a Mac > community) would still be using Finder 1.0 on the original Mac. No argument here. I *do* have an argument as to where this improvement is significant or worthwhile. >>[ explanation of poor performance on HP 9000 workstation ] > > Sounds like your system needs to be reconfigured. Anything that has > difficulty doing what you described ought to be fixed or junked. It was already suggested to me that it could probably use some more memory to cut down on swapping. However, even at times when I was the only user response was never (as you say it is in your case) "instantaneous". > How about "mouse response on the Mac goes away during volume recognition." Yes, but I mean, how does that relate to (or improve under) different types of multitasking? > I don't have a mandelbrot background. I have a mouse. Perhaps I have > inserted the floppy so that I may copy a file to the floppy disk. Haven't > you ever tried to open the folder that the file is in while the Mac is > trying to figure out what the name of your disk is? > > The jerkiness of the mouse caused by volume recognition is just damn > _unnecessary_, and irritating. I'm not familiar with details of the Disk Driver, but I always assumed that since the CPU (on machines other than the IIfx) is doing the transfer, it would not be possible to enable mouse interrupts as well without losing some of the sector. Since disk accesses are so time-critical the CPU cannot afford to lose *any* time. Note that this would mean having to wait for the media to complete an entire rotation in order to attempt the read again. I also suspect it would have a significant impact on the ability to quickly read (or cache?) consecutive sectors. I obviously haven't tried enabling mouse interrupts, but I would suspect it wouldn't be too difficult to slow disk accesses down to a crawl by moving the mouse continuously. > Gee, isn't that entirely against the philosophy of the Mac's cooperative > scheduler? Isn't the interactive user supposed to get good response > time *no matter what*? No, no, no, that is *certainly* not what a cooperative, or any sort of scheduler presumes or can do. The response time is fundamentally limited to the hardware. No scheduler can make the hardware itself run faster. If, assuming that it is indeed the case that the CPU is not significantly faster than the drive, any sort of scheduling will make disk access significantly slower. Having the OS preempt the Disk Driver while it is in the process of mounting will not make it any faster. > Your argument above is what most people use to > argue *against* preemptive scheduling, the idea that the interactive > user might not get prompt responses! The argument I am making for non-preemptive scheduling is that it is up to the programmer to decide at what points it is useful or desirable to give up time to other tasks. Presumably the implementers of the Disk Driver thought that getting the disk access over with as quickly as possible was more useful than making the mouse move. A preemptive scheduler makes this decision *for* you, how well, depending on the scheduler used. > You cannot tell me that during the time period that volume mounting is > taking place, that the CPU is _really_ busy. Probably less than 1/1000 > of the delay experienced is actually due to the fact that the CPU is > too busy to move your mouse. But the mouse is also not completely disabled during the *entire* mount. Probably, I would suspect, only at times when actual disk accesses are taking place. I agree that the time required to move the mouse may not be incredibly much (although, with multiple screens with different depths it may not be that easy, either), but then the timing constraints of disk drives are somewhat stringent. > I think that *both* mouse responsiveness and volume mounting should be > provided at the same time. It can be done. Why do you not desire this? But I do. That's why I like my IIfx so much. It can be done, but it requires hardware support. Because the IIfx's IOPs relieve the CPU from doing the disk accessing it is free to handle mouse movement stuff. > What? Are you kidding? The answer is "none." The scheduler is part of > the operating system, which is not represented as a process. I don't mean the scheduler per se, I mean system processes like daemons which are not directly related to user programs. Perhaps my question was badly phrased, it was really just as a matter of interest. > The responsiveness of my mouse pointer (or anything else for that matter) > is instantaneous. Just like my Mac. > Have a nice day. You too! _______________________________________________________________________________ Ben Hekster | "I've had my fun Student intern | but now it's time AppleLink: heksterb | to serve your conscience Internet: heksterb@apple.com | overseas" BITNET: heksterb@henut5 | --Orange Crush, R.E.M. (Green)
francis@uchicago.edu (Francis Stracke) (01/17/91)
Before you read my article, let me just say that I _do_ like the Macintosh. I own one, and I like it. Good. Otherwise, we would have to shoot you. :-) [lots of stuff cut] I think that *both* mouse responsiveness and volume mounting should be provided at the same time. It can be done. Why do you not desire this? > As an aside--how many of those ninety processes were running to >support the multitasking? What? Are you kidding? The answer is "none." The scheduler is part of the operating system, which is not represented as a process. There are, at this very moment, 126 processes on this workstation I am posting from. Most of these processes (73) are concerned with network services provided by this machine. Nfs, yellow pages, etc. The rest of the processes (53) are user processes. There are currently six users logged on this machine. The responsiveness of my mouse pointer (or anything else for that matter) is instantaneous. Just like my Mac. What the **!@#? kind of machine are your running? I'm on a Sun 3/60, with 3 users, running X; if I click the mouse once--not holding it down or anything--the menu appears & disappears: this takes nearly 3 seconds (yes, I timed it). Almost nothing is going on in the background. There are a total of 53 processes, 8 of which are dead or something. -- ============================================================================== | Francis Stracke | My opinions are my own. I don't steal them.| | Department of Mathematics |=============================================| | University of Chicago | Until you stalk and overrun, | | francis@zaphod.uchicago.edu | you can't devour anyone. -- Hobbes | ==============================================================================
jxf@altair.cis.ksu.edu (Jerry Frain) (01/17/91)
francis@uchicago.edu (Francis Stracke) writes: > Before you read my article, let me just say that I _do_ like the Macintosh. > I own one, and I like it. >Good. Otherwise, we would have to shoot you. :-) :-) > [lots of stuff cut] [ ditto ] [ the workstation I am using has 126 processes, and six interactive users, many network services processes (and a preemptive scheduler :-), but I still get good response time ] >What the **!@#? kind of machine are your running? I'm on a Sun 3/60, >with 3 users, running X; if I click the mouse once--not holding it >down or anything--the menu appears & disappears: this takes nearly 3 >seconds (yes, I timed it). Almost nothing is going on in the >background. I am not suprised, with a Sun 3/60. Ours are dogs, too, if more than one person is logged in doing anything terribly productive. Not too bad, if used for a single-user machine, however. I am using a Sun SPARCstation 1. It's verra nice indeed. A SPARC chip against a 68020 might seem a little unfair (or maybe not), but the Sun 3/80 has a 68030 (like my Mac), and its response time is very good; just one step below that of the SPARC. [ Oops, sounds like this thread better die here or follow-ups had better start going to a more appropriate newsgroup ] > There are a total of 53 processes, 8 of which are dead >or something. "Zombies," I think, is the term you are looking for. --Jerry -- Jerry Frain -- Systems Programmer Kansas State University Department of Computing & Info Sciences Internet : jxf@cis.ksu.edu Manhattan, Kansas UUCP : ...!rutgers!ksuvax1!jxf
wwtaroli@rodan.acs.syr.edu (Bill Taroli) (01/17/91)
In article <48184@apple.Apple.COM> heksterb@Apple.COM (Ben Hekster) writes: >jxf@orion.cis.ksu.edu (Jerry Frain) responds to my latest posting: > >> How about "mouse response on the Mac goes away during volume recognition." > >Yes, but I mean, how does that relate to (or improve under) different types >of multitasking? Exactly. Disk access in the Mac would not be improved if preemtive multi- tasking were used. Since all disk operations generate interrupts, you're going to get jerky mouse movement anyway. >> [...] Haven't >> you ever tried to open the folder that the file is in while the Mac is >> trying to figure out what the name of your disk is? >> >> The jerkiness of the mouse caused by volume recognition is just damn >> _unnecessary_, and irritating. > >I'm not familiar with details of the Disk Driver, but I always assumed that >since the CPU (on machines other than the IIfx) is doing the transfer, it >would not be possible to enable mouse interrupts as well without losing some >of the sector. Correct. However, again the assumption is made that preemptive multitasking will solve this problem... WRONG! What will solve this problem is if Apple's development team gets DMA transfers going. I understand the only reason they weren't available in the IIfx is that the Virtual Memory and DMA teams did something incompatible with one another, so they had to drop one in System 7. So, DMA hardware sits on the IIfx motherboard pretty much useless. Thus, if it's disk access interrupts that this guy is griping about, have him get a job with Apple with both hardware and software teams so that he can help speed the development of DMA... [More misconceptions on multitasking and DMA hardware.] >> You cannot tell me that during the time period that volume mounting is >> taking place, that the CPU is _really_ busy. Probably less than 1/1000 >> of the delay experienced is actually due to the fact that the CPU is >> too busy to move your mouse. Sure we can! The CPU in the Mac deals with every aspect of disk transfers. So, if a disk is accessed, the CPU is involved all the way. True, you could probably get situations where the CPU sat idle for a relatively long amount of time waiting for a disk transfer to complete (esp. for floppies), but this is what DMA is designed to solve -- completely free the CPU from doing the intensive parts of disk access. Again, this is a hardware and OS problem. >> I think that *both* mouse responsiveness and volume mounting should be >> provided at the same time. It can be done. Why do you not desire this? > >But I do. That's why I like my IIfx so much. It can be done, but it requires >hardware support. Because the IIfx's IOPs relieve the CPU from doing the disk >accessing it is free to handle mouse movement stuff. Yes and no. DMA isn't even fully supported in System 7. It is DMA that would really give you the capability that you describe. You're just working with one extremely high-power system. -- ______ Bill Taroli -- Syracuse University | "The only thing necessary for \ PT / | the triumph of evil is for \ / Internet: wwtaroli@rodan.acs.syr.edu | good men to do nothing." \/ BITNET: wwtaroli@sunrise.acs.syr.edu | -- Edmund Burke