Processes' memory
|
Prev: GPS resolutio (was Re: SYSENTER/SYSEXIT_vs._SYSCALL/SYSRET)
Next: F r e e C I S C O C e r t i f i c a t i o n s
From: Anne & Lynn Wheeler on 27 Jan 2010 09:58 nmm1(a)cam.ac.uk writes: > I was closely involved with that. It was a bigger job than you might > think. A multi-user version was infesible, because even CMS couldn't > handle the interrupt rate needed for a WIMP GUI (i.e. one of the sort > produced by Xerox, Apple, X Windows and PM). It was a major problem > (and still is) even with Unix and Windows 3 - and the latter got its > performance (such as it was) by running everything in kernel mode! re: http://www.garlic.com/~lynn/2010c.html#4 Processes' memory http://www.garlic.com/~lynn/2010c.html#5 Processes' memory http://www.garlic.com/~lynn/2010c.html#14 Processes' memory http://www.garlic.com/~lynn/2010c.html#15 Processes' memory http://www.garlic.com/~lynn/2010c.html#17 Processes' memory i was young and brash ... i had done lots of cp67 pathlength optimization as undergraduate in the 60s ... that is less than anything doing stuff like mouse and other stuff today. the original cp67 group was focused on efficient operation of lightweight microkernel (for virtual machine emulation). I've periodically commented that growing bloat with vm370/cms was bringing in developers with much more traditional operating system backgrounds. in the mid-70s, I did stripped down vm370 kernel that ran relatively well on 256kbytes 370/125 (it wasn't quite back to the efficiency of what I had done on cp67 ... but getting close) .... so nearly decade later vm370/cms was having significant problems working in 384kbytes .... and required 512kbytes. Part of the issue was that there had been growing reliance on leveraging real storage to somewhat offset disks thruput limitations ... but xt/370 had neither the real storage nor the disk thruput ... and many of the CMS applications were becoming increasingly bloated regarding both real storage (aka number of virtual pages needed resident in real storage) and disk i/o. -- 42yrs virtualization experience (since Jan68), online at home since Mar1970
From: nmm1 on 27 Jan 2010 10:18 In article <m3mxzzmw6p.fsf(a)garlic.com>, Anne & Lynn Wheeler <lynn(a)garlic.com> wrote: > >> I was closely involved with that. It was a bigger job than you might >> think. A multi-user version was infesible, because even CMS couldn't >> handle the interrupt rate needed for a WIMP GUI (i.e. one of the sort >> produced by Xerox, Apple, X Windows and PM). It was a major problem >> (and still is) even with Unix and Windows 3 - and the latter got its >> performance (such as it was) by running everything in kernel mode! > >i was young and brash ... i had done lots of cp67 pathlength >optimization as undergraduate in the 60s ... that is less than anything >doing stuff like mouse and other stuff today. > >the original cp67 group was focused on efficient operation of >lightweight microkernel (for virtual machine emulation). I've >periodically commented that growing bloat with vm370/cms was bringing in >developers with much more traditional operating system backgrounds. Yes, that's the point. With a line-level interaction model, you have two context switches per line, and need deliver only a 0.25 second response time. Character reflection can be offloaded or done in a really stripped down interrupt routine. With curses-style interaction, you have two context switches per character, and need to deliver a 0.1 second response time. With a modern WIMP GUI, you have between 12 and 80 context switches per character or mouse click, and still need to deliver a 0.1 second response time. Once you bring in dragging, line drawing etc., you are talking many dozens or even hundreds of context switches a second, and need to deliver a 0.02 second response time. Regards, Nick Maclaren.
From: Anne & Lynn Wheeler on 27 Jan 2010 10:32 nmm1(a)cam.ac.uk writes: > Yes, that's the point. With a line-level interaction model, you > have two context switches per line, and need deliver only a 0.25 > second response time. Character reflection can be offloaded or > done in a really stripped down interrupt routine. > > With curses-style interaction, you have two context switches per > character, and need to deliver a 0.1 second response time. > > With a modern WIMP GUI, you have between 12 and 80 context switches > per character or mouse click, and still need to deliver a 0.1 second > response time. > > Once you bring in dragging, line drawing etc., you are talking many > dozens or even hundreds of context switches a second, and need to > deliver a 0.02 second response time. re: http://www.garlic.com/~lynn/2010c.html#4 Processes' memory http://www.garlic.com/~lynn/2010c.html#5 Processes' memory http://www.garlic.com/~lynn/2010c.html#14 Processes' memory http://www.garlic.com/~lynn/2010c.html#15 Processes' memory http://www.garlic.com/~lynn/2010c.html#17 Processes' memory http://www.garlic.com/~lynn/2010c.html#18 Processes' memory its is little bit easier with faster processor than 360/67 ... this is recent post that given the change in processor speed and real memory sizes between 360/67 and 3081k ... that things should have gone from 80 users to 4000 users ... instead of typical 300 users found on 3081k in early 80s (i.e. 300/80 is about the ratio in change in disk performance). http://www.garlic.com/~lynn/2010c.html#1 "The Naked Mainframe" (Forbes Security Article) thread discussing being able to handle the routes lookup part for all airline reservations in the world ... changing both the implementation paradigm as well as moving off mainframe (at the same time) .... including if raw MIP rate was the only consideration ... that the whole process could be run on a single TREO http://www.garlic.com/~lynn/2010b.html#79 Happy DEC-10 Day http://www.garlic.com/~lynn/2010b.html#80 Happy DEC-10 Day -- 42yrs virtualization experience (since Jan68), online at home since Mar1970
From: Mike on 27 Jan 2010 11:16 <nmm1(a)cam.ac.uk> wrote in message news:hjp12i$lp9$1(a)smaug.linux.pwf.cam.ac.uk... | In article <Vr6dnYyTD7AcKsLWnZ2dnUVZ_qWdnZ2d(a)earthlink.com>, | Mike <mike(a)mike.net> wrote: | > | >I have often wonder how modern systems would have evolved in an | >alternate universe where IBM did not fund MicroSoft and OS/2 but | >instead chose to implement Presentation Manager to provide a GUI on | >top of VM/CMS and compete in the micro and workstation arena with a | >370 instruction set chip. | | I was closely involved with that. It was a bigger job than you might | think. A multi-user version was infesible, because even CMS couldn't | handle the interrupt rate needed for a WIMP GUI (i.e. one of the sort | produced by Xerox, Apple, X Windows and PM). It was a major problem | (and still is) even with Unix and Windows 3 - and the latter got its | performance (such as it was) by running everything in kernel mode! A GUI would not work over a network but it would have run on a dedicated local cpu like a PC/370 | The original variant of 'Presentation Manager' that was designed for | CMS was text-only (i.e. the 3270 equivalent of curses). That would | have worked (and did). Multiple windows and graphics display would | have been fairly easily addable (they were in the design), but not | the killer features like dragging with the mouse. It might just | have survived with a single user and no background tasks or daemons, | but that would have put the existing mainframe users off completely. | | What would have happened would have been a new lease of life for the | 'full screen' interfaces of the 3270/curses variety, but sooner or | later GUIs would have come up from outfield and taken over. | | > In 1984 IBM had a PC/370 but decided it | >370 instruction set chip. In 1984 IBM had a PC/370 but decided it | >would eat mainframe revenue and limited software licenses to machines | >connected to mainframes thus killing their attraction. | | Did they? Despite being VERY close to IBM, I never tracked that down, | and think that it was an urban myth. Yes, there was a design, and it | may even have reached silicon, but (as far as I know) it never reached | the stage of actually running a full-blown System/370 operating system, | even in-house. If I recall, they had a PC/AT with an Intel cpu emulating a channel processor and a modified Motorola 68000 providing the /370 instruction set. It ran VM/CMS and could run essentially any mainframe application program and almost any system program. The announced price was about $5,400 but they would only license the software if it was attached to a mainframe with a VM/CMS license. | | >Your suggestion of a portable version of CMS is an intriguing | >alternate especially if combined with a portable GUI. Just think, an | >industrial strength GUI on 370, 801, and S/38 and on PC's to compete | >with Windows 3.1. | | If anyone had delivered a viable form of Unix at an affordable price, | that would have eliminated Windows 3.1. They didn't, until far too | late, and that was marketing and not technical. I doubt that IBM | could have moved fast enough to convert CMS to such a very different | style of use. Why do you think it would have been slower to migrate AIX to the Intel PC than it took to develop OS/2? For that matter wouldn't it have been cheaper and faster to do all of the above than develop OS/2 and there by fund MicroSoft backroom development of Windows 3.1? Mike
From: Mike on 27 Jan 2010 11:23
<nmm1(a)cam.ac.uk> wrote in message news:hjplfk$5om$1(a)smaug.linux.pwf.cam.ac.uk... | In article <m3mxzzmw6p.fsf(a)garlic.com>, | Anne & Lynn Wheeler <lynn(a)garlic.com> wrote: | > | >> I was closely involved with that. It was a bigger job than you might | >> think. A multi-user version was infesible, because even CMS couldn't | >> handle the interrupt rate needed for a WIMP GUI (i.e. one of the sort | >> produced by Xerox, Apple, X Windows and PM). It was a major problem | >> (and still is) even with Unix and Windows 3 - and the latter got its | >> performance (such as it was) by running everything in kernel mode! | > | >i was young and brash ... i had done lots of cp67 pathlength | >optimization as undergraduate in the 60s ... that is less than anything | >doing stuff like mouse and other stuff today. | > | >the original cp67 group was focused on efficient operation of | >lightweight microkernel (for virtual machine emulation). I've | >periodically commented that growing bloat with vm370/cms was bringing in | >developers with much more traditional operating system backgrounds. | | Yes, that's the point. With a line-level interaction model, you | have two context switches per line, and need deliver only a 0.25 | second response time. Character reflection can be offloaded or | done in a really stripped down interrupt routine. | | With curses-style interaction, you have two context switches per | character, and need to deliver a 0.1 second response time. | | With a modern WIMP GUI, you have between 12 and 80 context switches | per character or mouse click, and still need to deliver a 0.1 second | response time. | | Once you bring in dragging, line drawing etc., you are talking many | dozens or even hundreds of context switches a second, and need to | deliver a 0.02 second response time. | Which argues for memory mapped video and a local CPU but still leaves open a whole range of OS choices. Mike |