At the time, those were the only computers out there. The "personal computer" was the myth of the day. Go back and look at the prices IBM and DEC were charging for their gear. Even in the modern context, that hardware was more expensive than the rediculously inflated prices of housing in Vancouver. --lyndon

On Sat, Jun 16, 2018 at 2:36 AM, Dave Horsfall <dave(a)horsfall.org> wrote: ​I sent Dave's comment to the chief designer of the Model 50 (my friend Russ Robelen). His reply is cut/pasted below. For context he refers to a ver rare book called: ‘IBM’s 360 and Early 370 Systems’ by Pugh, Johnson & J.H.Palmer . A book and other other IBMers like Russ is considered the biblical text on 360: As to Dave’s comment: I'll bet that my iPhone has more power than our System-360/50, but it has nowhere near the sheer I/O throughput of a mainframe. The ratio of bits of I/O to CPU MIPS was very high back in those days, Particularly for the Model 50 which was considered a ‘Commercial machine’ vs a ‘Scientific machine’. The machine was doing payroll and inventory management, high on I/O low on compute. Much different today even for an iPhone. The latest iPhone runs on a ARMv8 derivative of Apple's "Swift" *dual core *architecture called "Cyclone" and it runs at 1.3 GHz. The Mod 50 ran at 2 MHz. The ARMv8 is a 64 bit machine. The Mod 50 was a 32 bit machine. The mod 50 had no cache (memory ran at .5 Mhz). Depending on what instruction mix you want to use I would put the iPhone at conservatively 1,500 times the Mod 50. I might add, a typical Mod 50 system with I/O sold for $1M. On the question of memory cost - this is from the bible on 360 mentioned earlier. *For example, the Model 50 main memory with a read-write cycle of 2 microseconds cost .8 cents per bit*. *Page 194 Chapter 4 ‘IBM’s 360 and Early 370 Systems”* ​ ᐧ

On 2018-Jun-18 10:25:03 +0100, Tim Bradshaw <tfb(a)tfeb.org> wrote: One way of looking at this actually backs up the claim: An iPhone has maybe 3 orders of magnitude more CPU power than a 360/50 but only a couple of times the I/O bandwidth. So it's actually got maybe 2 orders of magnitude less relative I/O throughput. -- Peter Jeremy

On 2018-Jun-20 08:55:05 +1000, David Arnold <davida(a)pobox.com> wrote: I was thinking about that as well. 1080p30 video is around 2MBps as H.264 or about 140MBps as 6bpp raw. The former is negligible, the latter is still shy of the disparity in CPU power, especially if you take into account the GPU power needed to do the decoding. I agree. Even back then, there was a difference between commercial-oriented mainframes (the 1401 and 360/50 lineage - which stressed lots of I/O) and the scientific mainframes (709x, 360/85 - which stressed arithmetic capabilities). One, not too inaccurate, description of the BCM2835 (RPi SoC) is that it's a GPU and the sole job of the CPU is to push data into the GPU. -- Peter Jeremy

On Tuesday, 19 June 2018 at 23:41:41 -0600, Warner Losh wrote: Looking at something like the IBM 370 series (mid-1970s), I/O was performed by the channels, effectively separate processors with a very limited instruction set. Others, like the UNIVAC 1100 series, could perform I/O directly or via separate processors. This was similar on the /360, but very different on the 1401. In each case, from my recollection, main memory and the peripheral were the bottleneck. For the UNIVAC 1108 (1965, the one of which I have the best recollection), memory was 36 bits every 750 ns, and you could expect it to be interleaved at least 2 ways, so you could transfer data across two channels to a FH 432 drum at in the order of 2.5 MW/s. This could lead to underruns depending on what else was going on in the system. Other peripherals were slower, so this would have been about the maximum. Greg -- Sent from my desktop computer. Finger grog(a)lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA

On 2018-Jun-20 12:33:05 -0400, Paul Winalski <paul.winalski(a)gmail.com> wrote: The S360 architecture defined separate main CPU and I/O channel processors and the actual implementation varied between models. IBM stressed the compatibility between models so it can be difficult to determine what the actual implementation did in hardware vs microcode. At least the model 30 also emulated the channel processor using the main CPU. [1] confirms this for the multiplexor[2] channels and implies it for the selector[3] channels. The "CPU interference factors" in [5](p65) suggest the model 50 also emulated the channel processors. The idea of separate I/O processors was also used in the CDC6600. Note that most S360 machines were microcoded with the native ALU size varying between 8 and 32 bits. The model 25 was also the only S360 with writable microcode and there was a microcoded APL implementation for it so it "natively" executed APL. I'm not sure if there were any other novel microcode sets for it. Going back to Greg's question of actual I/O performance: A model 50 could support 3 selector channels, with a nominal rate of 800kBps each[6]. Since each selector channel could only perform a single I/O operation at a time, I believe the actual rate was effectively limited to the fastest device on the channel - which [5] indicates was 340kBps for a 7340-3 Hypertape at 3022bpi. That implies a total of 1020kBps of I/O. The "CPU interference" indicates that each byte transferred blocked the CPU for 0.95us, so 1020kBps of I/O would also steal 97% of the CPU-storage bandwidth. [1] http://bitsavers.org/pdf/ibm/360/funcChar/GA24-3231-7_360-30_funcChar.pdf [2] "multiplexer" channels were used for low speed devices - card readers, card punches, printers, serial communications. [3] "selector" channels were used for high speed devices - tape, DASD[4] [4] Direct Access Storage Device - IBM speak for "disk" [5] http://bitsavers.org/pdf/ibm/360/funcChar/A22-6898-1_360-50_funcChar_1967.p… [6] https://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP2050.html -- Peter Jeremy

On 21 Jun 2018, at 16:00, Paul Winalski <paul.winalski(a)gmail.com> wrote: [...] Is this the origin of the lore on “the IBM slowdown device”? I seem to recall there was also some trickery at the CPU level so that you could “field upgrade” between two models by removing it but a) I cannot find the source and b) my Pugh book is far and cannot scan through it. Arrigo

The VAX 8800 was also the advent of the DEC BI bus attempt to lock third-party I/O devices out of the VAX market and prevent "unauthorized" competition with their own overpriced and underperforming I/O devices. In late 1988 or early 1989 my group at Apple ordered a VAX-8810 to replace two 11/780s on the promise from DEC that all our UniBus and MASSbus peripherals would still work ... which we knew (from others on the Internet who'd tried and reported their experiences) to be a lie. After allowing DEC field circus to embarass themselves for a while trying to make it work, we cancelled our 8810 order and bought two 8650s instead (they cost half as much!), which we knew would run 4.3 BSD UNIX (unlike the 8800 series where we'd be stuck with Ultrix) and where all our old but still useful peripherals would still work. Surprise, DEC - your customers talk to each other and compare notes. IIRC, as a consolation for DEC, we still bought a heavily discounted 6000 series BI machine with all new I/O to handle some other tasks that the 8650s weren't doing while also making clear to DEC that we understood the game they'd tried to play with us. After that, Apple engineering concentrated on Sun & SGI gear, along with our Cray running UniCOS, but Apple IS&T (corporate IT) bought quite a bit of VAX gear to run VMS for certain applications they had to support. Part of being in the Unix community was participating it as a community and sharing experiences like this for the benefit of all (and to keep hardware vendors honest) - the Unix-Wizards Internet mailing list, and comp.unix USENET newsgroup were invaluable in this regard. Erik Fair

On Thu, 21 Jun 2018, Arrigo Triulzi wrote: If I remember my computer lore correctly, wasn't the difference between the Cyber 72 and the 73 just a timing capacitor, if you knew which board? And I still reckon that the olde 360/20 (I did see the console for one) should never have been part of the 360 series; * It had a HALT instruction! * It had about half the instruction set. * Half the number of registers, and width. * Floating point? What's that? Etc. A triumph of marketing over engineering... -- Dave, who did his CompSci thesis on the 360...