Processes' memory
in [Unix Programming]
|
From: nmm1 on 27 Jan 2010 11:33 In article <m6mdncE4PpxT-_3WnZ2dnUVZ_hCdnZ2d(a)earthlink.com>, Mike <mike(a)mike.net> wrote: > >| >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? Er, I suggest that you reread what I posted. I didn't say that at all. AIX is a sort-of Unix, after all. >| 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. What does that have to do with context switches? The issue I am talking about has nothing to do with how the graphics are displayed. Regards, Nick Maclaren.
From: Anne & Lynn Wheeler on 27 Jan 2010 12:19 Anne & Lynn Wheeler <lynn(a)garlic.com> writes: > 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. re: http://www.garlic.com/~lynn/2010c.html#18 Processes' memory boeblingen had done 115/125 370 ... it was nine-position shared memory bus ... but typically only had 4-5 microprocessors in configuration. 115 had all identical 800kip microprocessors ... microcode load would determine personality of each microprocessor ... and 370 microcode load was about 10:1 so 115 was about 80kip 370 (about the same as xt/370). 125 was nearly identical to 115, but had a 1000kip processor for 370 .... about 100kip 370. I spent some time doing 5-way SMP vm370 125 .... loading up the remaining (typically empty) four slots with 1000kip microprocessor running 370 microcode. big difference nearly decade later for xt/370 was vm370, cms and the applications got a lot more bloated ... so needed more than twice the real storage ... and the 125 disks were a lot faster than the pc/xt disks. re: http://www.garlic.com/~lynn/2010c.html#14 Processes' memory with regard to http://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor about the time of xt/370, boeblingen had 3 chipset 370 running about the speed of 168-3 (3mips) ... that I wanted to use in the above. For the 801, I would have liked to use blue iliad ... 1st 32bit 801 chip ... really big and really hot ... ran about 20mips ... and was never finished (next 32bit 801 chip was six chipset RIOS) however at the time, real storage and disks for practical configurations were outside the price range of desktop market. -- 42yrs virtualization experience (since Jan68), online at home since Mar1970
From: Anne & Lynn Wheeler on 27 Jan 2010 12:44 "Mike" <mike(a)mike.net> writes: > 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. the other scenario was that late 70s & early 80s ... there was the 801 Iliad chip scenario ... that was targeted at using 801s to replace the large number of different corporate microprocessors with 801s. The follow-on to 4341 was going to be an iliad-based 801 microprocessor; I contributed to white paper that killed that ... based on technology had gotten to the point that majority of 370 could be directly implemented in silicon (in part, demonstrated by the boeblingen 3chipset 370). Originally the s/38 as/400 follow-in was also going to be a 801 microprocessor ... when that floundered there was crash effort to do a CISC for as/400 (although the next decade, as/400 did migrate to 801 power/pc). misc. old email mentioning 801 http://www.garlic.com/~lynn/lhwemail.html#801 past posts mentioning 801, risc, iliad, romp, rios, power, power/pc, somerset, etc http://www.garlic.com/~lynn/subtopic.html#801 other posts in this thread: 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 http://www.garlic.com/~lynn/2010c.html#19 Processes' memory http://www.garlic.com/~lynn/2010c.html#20 Processes' memory -- 42yrs virtualization experience (since Jan68), online at home since Mar1970
From: Anne & Lynn Wheeler on 28 Jan 2010 10:53 "Mike" <mike(a)mike.net> writes: > 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. unrelated to pc/370 (originally xt/370 and then at/370): there was a card emulating channel processing that was done originally by the 3800 printer group in Boulder ... for 3800 testing there was a card done in ykt that attached to channel and emulated a controller. this was packaged in an rack-mount, industrial PC/AT and sold as "8343" for use with vm370 tcp/ip support. later the vm370 tcp/ip support was migrated to MVS ... by a hack that emulated some vm370 "diagnose" instructions (in MVS). internal use of the ykt "controller card", initially was software emulation of terminal emulation ... but over LAN interface. prior terminal emulation was via real 327x controller, real 327x coax cable, PC card that emulated 327x terminal ... file upload/download was emulated screen input/output ... and ran into various bottlenecks. There were two versions ANR (original 3277) and DCA (newer 3274/3278). 3274/3278 moved a lot of electronics back into controller (compared to 3277) reducing terminal manufacturing costs ... but resulted in a lot more coax chatter. As a result DCA was significantly slower than ANR for all sorts of stuff. MYTE using LAN interface for terminal emulation was much faster than either ANR or DCA (for just about everything ... especially noticable in file upload/download speed). I would need to look up what the "M" stood for ... but YTE was "yorktown terminal emulation". For TCP/IP, "8343" wasn't changed a lot ... basically a LAN bridge (rather than a router) ... as a result the host TCP/IP had to do all protocol translation between tcp/ip and LAN. As a result on, vm370 tcp/ip 8343 thruput got around 44kbytes/sec sustained thruput using a 3090 processor. I then did the modifications to vm370 tcp/ip to support rfc1044 .... and in some testing at cray research between 4341 and cray ... got 1mbyte/sec sustrained (4341 channel media) using only modest amount of 4341 processor (around factor of 500 times improvement in bytes moved per instruction executed). misc. past posts mentioning 1044 support http://www.garlic.com/~lynn/subnetwork.html#1044 the trip to cray research was notable since the plane departed SFO 20 mins late ... but 5 mins before the earthquake hit. there were internal efforts to try and package the 8343 hardware at about 1/10th the price (of the 8343), with significantly improved host pathlength support ... but that encountered huge internal political problems. attempt was oriented to positioning mainframe as major player in distributed processing with the mainframe as a major data/file server. misc. past posts in this thread (mostly pc/370 stuff) 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 http://www.garlic.com/~lynn/2010c.html#19 Processes' memory http://www.garlic.com/~lynn/2010c.html#20 Processes' memory http://www.garlic.com/~lynn/2010c.html#21 Processes' memory -- 42yrs virtualization experience (since Jan68), online at home since Mar1970
From: Anne & Lynn Wheeler on 28 Jan 2010 11:32
Anne & Lynn Wheeler <lynn(a)garlic.com> writes: > there was a card done in ykt that attached to channel and emulated a > controller. this was packaged in an rack-mount, industrial PC/AT and > sold as "8343" for use with vm370 tcp/ip support. later the vm370 tcp/ip > support was migrated to MVS ... by a hack that emulated some vm370 > "diagnose" instructions (in MVS). re: http://www.garlic.com/~lynn/2010c.html#24 Processes' memory "8343"->"8232" for some reason, every since i worked on credit/debit payment card network ISO standards (8583) ... I tend to fat finger the 8232 number. -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 |