Re: [TUHS] core

Re: [TUHS] core

[Noel Chiappa]

    > From: "John P. Linderman"

    > 4 bucks a bit!

When IBM went to license the core patent(s?) from MIT, they offered MIT a
choice of a large lump sump (the number US$20M sticks in my mind), or US$.01 a
bit.

The negotiators from MIT took the lump sum.

When I first heard this story, I thought it was corrupt folklore, but I later
found it in one of the IBM histories.

This story repets itself over and over again, though: one of the Watson's
saying there was a probably market for <single-digit> of computers; Ken Olsen
saying people wouldn't want computers in their homes; etc, etc.

      Noel

Re: [TUHS] core

[Dave Horsfall]

On Fri, 15 Jun 2018, Noel Chiappa wrote:

> This story repets itself over and over again, though: one of the 
> Watson's saying there was a probably market for <single-digit> of 
> computers; Ken Olsen saying people wouldn't want computers in their 
> homes; etc, etc.

I seem to recall reading somewhere that these were urban myths...  Does 
anyone have actual references in their contexts?

E.g. Watson was talking about the multi-megabuck 704/709/7094 etc, and I 
think that Olsens's quote was about the DEC-System 10...

-- Dave, who has been known to be wrong before

Re: [TUHS] core

[Lyndon Nerenberg]

>> This story repets itself over and over again, though: one of the Watson's 
>> saying there was a probably market for <single-digit> of computers; Ken 
>> Olsen saying people wouldn't want computers in their homes; etc, etc.
>
> I seem to recall reading somewhere that these were urban myths...  Does 
> anyone have actual references in their contexts?
>
> E.g. Watson was talking about the multi-megabuck 704/709/7094 etc, and I 
> think that Olsens's quote was about the DEC-System 10...

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

Re: [TUHS] core

[Dave Horsfall]

On Fri, 15 Jun 2018, Lyndon Nerenberg wrote:

>> E.g. Watson was talking about the multi-megabuck 704/709/7094 etc, and 
>> I think that Olsen's quote was about the DEC-System 10...
>
> 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.

Precisely, but idiots keep repeating those "quotes" (if they were repeated 
accurately at all) in some sort of an effort to make the so-called 
"experts" look silly; a form of reverse jealousy/snobbery or something? 
It really pisses me off, and I'm sure that there's a medical term for 
it...

I came across a web site that had these populist quotes, alongside the 
original *taken in context*, but I'm damned if I can find it now.

I mean, how many people could afford a 7094, FFS?  The power bill, the air 
conditioning, the team of technicians, the warehouse of spare parts...

Hell, 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 :-)

-- Dave

Re: [TUHS] core

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]

On Sat, Jun 16, 2018 at 2:36 AM, Dave Horsfall <dave@horsfall.org> wrote:

> ​...​
>
> Hell, 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 :-)


​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”*



​
ᐧ

[-- Attachment #2: Type: text/html, Size: 5818 bytes --]

Re: [TUHS] core

[Tim Bradshaw]

Apropos of the 'my iPhone has more power than our System-360/50, but it has nowhere near the sheer I/O throughput of a mainframe' comment: there's obviously no doubt that devices like phones (and laptops, desktops &c) are I/O-starved compared to serious machines, but comparing the performance of an iPhone and a 360/50 seems to be a matter of choosing how fine the dust you want the 360/50 to be ground into should be.

The 360/50 could, I think, transfer 4 bytes every 2 microseconds to/from main memory, which is 20Mb/s.  I've just measured my iPhone (6): it can do about 36Mb/s ... over WiFi, backed by a 4G cellular connection (this is towards the phone, the other direction is much worse).  Over WiFi with something serious behind it it gets 70-80Mb/s in both directions.  I have no idea what the raw WiFi bandwidth limit is, still less what the raw memory bandwidth is or its bandwidth to 'disk' (ie flash or whatever the storage in the phone is), but the phone has much more bandwidth over a partly wireless network to an endpoint tens or hundreds of miles away than the 360/50 had to main memory.

Re: [TUHS] core

[Peter Jeremy]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

On 2018-Jun-18 10:25:03 +0100, Tim Bradshaw <tfb@tfeb.org> wrote:
>Apropos of the 'my iPhone has more power than our System-360/50, but it has nowhere near the sheer I/O throughput of a mainframe' comment: there's obviously no doubt that devices like phones (and laptops, desktops &c) are I/O-starved compared to serious machines, but comparing the performance of an iPhone and a 360/50 seems to be a matter of choosing how fine the dust you want the 360/50 to be ground into should be.
>
>The 360/50 could, I think, transfer 4 bytes every 2 microseconds to/from main memory, which is 20Mb/s.  I've just measured my iPhone (6): it can do about 36Mb/s ... over WiFi, backed by a 4G cellular connection

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [TUHS] core

[David Arnold]

Does the screen count as I/O?

I’d suggest that it’s just that the balance is (intentionally) quite different.  If you squint right, a GPU could look like a channelized I/O controller. 




d

> On 20 Jun 2018, at 06:45, Peter Jeremy <peter@rulingia.com> wrote:
> 
>> On 2018-Jun-18 10:25:03 +0100, Tim Bradshaw <tfb@tfeb.org> wrote:
>> Apropos of the 'my iPhone has more power than our System-360/50, but it has nowhere near the sheer I/O throughput of a mainframe' comment: there's obviously no doubt that devices like phones (and laptops, desktops &c) are I/O-starved compared to serious machines, but comparing the performance of an iPhone and a 360/50 seems to be a matter of choosing how fine the dust you want the 360/50 to be ground into should be.
>> 
>> The 360/50 could, I think, transfer 4 bytes every 2 microseconds to/from main memory, which is 20Mb/s.  I've just measured my iPhone (6): it can do about 36Mb/s ... over WiFi, backed by a 4G cellular connection
> 
> 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

Re: [TUHS] core

[Peter Jeremy]

[-- Attachment #1: Type: text/plain, Size: 939 bytes --]

On 2018-Jun-20 08:55:05 +1000, David Arnold <davida@pobox.com> wrote:
>Does the screen count as I/O?

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’d suggest that it’s just that the balance is (intentionally) quite different.  If you squint right, a GPU could look like a channelized I/O controller. 

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [TUHS] core

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

On Tue, Jun 19, 2018 at 11:04 PM, Peter Jeremy <peter@rulingia.com> wrote:

> On 2018-Jun-20 08:55:05 +1000, David Arnold <davida@pobox.com> wrote:
> >Does the screen count as I/O?
>
> 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’d suggest that it’s just that the balance is (intentionally) quite
> different.  If you squint right, a GPU could look like a channelized I/O
> controller.
>
> 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).
>

So what could an old mainframe do as far as I/O was concerned? Google
didn't provide me a straight forward answer...

Warner

[-- Attachment #2: Type: text/html, Size: 1476 bytes --]

[TUHS] Old mainframe I/O speed (was: core)

[Greg 'groggy' Lehey]

[-- Attachment #1: Type: text/plain, Size: 2155 bytes --]

On Tuesday, 19 June 2018 at 23:41:41 -0600, Warner Losh wrote:
> On Tue, Jun 19, 2018 at 11:04 PM, Peter Jeremy <peter@rulingia.com> wrote:
>
>> On 2018-Jun-20 08:55:05 +1000, David Arnold <davida@pobox.com> wrote:
>>> Does the screen count as I/O?
>>
>> 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???d suggest that it???s just that the balance is (intentionally) quite
>> different.  If you squint right, a GPU could look like a channelized I/O
>> controller.
>>
>> 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).
>
> So what could an old mainframe do as far as I/O was concerned? Google
> didn't provide me a straight forward answer...

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@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [TUHS] Old mainframe I/O speed (was: core)

[Paul Winalski]

On 6/20/18, Greg 'groggy' Lehey <grog@lemis.com> 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.

All of the System/360 series except the model 25 used separate channel
processors to perform I/O.  Once the I/O was initiated, the channel
performed data transfer to and from main storage (IBM didn't use the
term "memory") completely independently from the CPU.  The S/360 model
25 was the last of the 360 series and was really a 16-bit minicomputer
microprogrammed to execute the S/360 instruction set.  It had what
they called "integrated channels", meaning that I/O was handled by CPU
microcode.

IBM used the model 25 I/O design in the S/370 models 135 and 145.  The
models 115 and 125 were actually four 16-bit processors on a bus along
with main memory.  One of them, the service processor, handled system
power-on, power-off, microcode load, diagnostics, and the system
console (a modified 3277 transaction terminal).  One was the CPU and
executed the S/370 instruction set in microcode.  The remaining two
processors acted as a byte and block multiplexer channel.  This meant
that I/O proceeded independently from the CPU, as with the old 360s.
It also meant that if the system was reading cards, punching cards,
and printing all at the same time (often the case when spooling), a
model 125 outperformed a 145 in compute speed, because the 145 had to
execute a microcode loop for every byte of I/O.

The 158 and 168 appear to have had independent channels, but housed in
the same boxes as the CPU as opposed to stand-alone units as with
S/360.

-Paul W.

Re: [TUHS] Old mainframe I/O speed (was: core)

[Peter Jeremy]

[-- Attachment #1: Type: text/plain, Size: 2447 bytes --]

On 2018-Jun-20 12:33:05 -0400, Paul Winalski <paul.winalski@gmail.com> wrote:
>All of the System/360 series except the model 25 used separate channel
>processors to perform I/O.

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.

>term "memory") completely independently from the CPU.  The S/360 model
>25 was the last of the 360 series and was really a 16-bit minicomputer
>microprogrammed to execute the S/360 instruction set.

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.pdf
[6] https://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP2050.html
-- 
Peter Jeremy

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [TUHS] Old mainframe I/O speed (was: core)

[Paul Winalski]

On 6/20/18, Peter Jeremy <peter@rulingia.com> wrote:
>
> 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.

Yes, the model 25's microcode was in core.  I remember we had to
reaload it from punch cards at one point when IBM issued an update.  I
didn't know about the custom APL microcode.  I do recall that the disk
controller logic, as well as the "selector channel", was in CPU
microcode.  After the model 25 was withdrawn, IBM released the sources
for the microcode to customers.  There were several hacks in there to
slow down the disk I/O so that it didn't outperform the model 30.

> [3] "selector" channels were used for high speed devices - tape, DASD[4]
> [4] Direct Access Storage Device - IBM speak for "disk"

They used the term DASD because it covered non-disk devices such as
drums and the 2321 data cell drive (aka "noodle picker").

-Paul W.

Re: [TUHS] Old mainframe I/O speed (was: core)

[Arrigo Triulzi]

On 21 Jun 2018, at 16:00, Paul Winalski <paul.winalski@gmail.com> wrote:
[...]
> for the microcode to customers.  There were several hacks in there to
> slow down the disk I/O so that it didn't outperform the model 30.

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 

Re: [TUHS] Old mainframe I/O speed (was: core)

[Paul Winalski]

On 6/21/18, Arrigo Triulzi <arrigo@alchemistowl.org> wrote:
> On 21 Jun 2018, at 16:00, Paul Winalski <paul.winalski@gmail.com> wrote:
> [...]
>> for the microcode to customers.  There were several hacks in there to
>> slow down the disk I/O so that it didn't outperform the model 30.
>
> 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.

I don't know about that for IBM systems, but DEC pulled that trick
with the VAX 8500 series.  Venus, the successor to the 11/780, was
originally to be called the 11/790 and was done in ECL by the PDP-10
folks.  The project suffered many delays and badly missed its initial
market window.  It eventually was released as the VAX 8600.  It had a
rather short market life because by that time the next generation CPU,
codenamed Nautilus and implemented in TTL, was nearly ready for market
and offered comparable performance.  There was also a slower and lower
cost system in that series codenamed Skipjack.  When it finally came
time to market these machines, it was found that the product line
needed a reduced cost version of Skipjack.  Rather than design a new
CPU, they just put NOPs in the Skipjack microcode to slow it down.
The official code name for this machine was Flounder, but within DEC
engineering we called it "Wimpjack".  Customers could buy a field
upgrade for Flounder microcode that restored it to Skipjack
performance levels.

-Paul W.

Re: [TUHS] Old mainframe I/O speed (was: core)

[Erik E. Fair]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=US-ASCII; format=flowed, Size: 3461 bytes --]

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


>Date: Thu, 21 Jun 2018 16:39:23 -0400
>From: Paul Winalski <paul.winalski@gmail.com>
>
>On 6/21/18, Arrigo Triulzi <arrigo@alchemistowl.org> wrote:
>> On 21 Jun 2018, at 16:00, Paul Winalski <paul.winalski@gmail.com> wrote:
>> [...]
>>> for the microcode to customers.  There were several hacks in there to
>>> slow down the disk I/O so that it didn't outperform the model 30.
>>
>> 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 yo>u
>> could “field upgrade” between two models by removing it b>ut a) I cannot find
>> the source and b) my Pugh book is far and cannot scan through it.
>
>I don't know about that for IBM systems, but DEC pulled that trick
>with the VAX 8500 series.  Venus, the successor to the 11/780, was
>originally to be called the 11/790 and was done in ECL by the PDP-10
>folks.  The project suffered many delays and badly missed its initial
>market window.  It eventually was released as the VAX 8600.  It had a
>rather short market life because by that time the next generation CPU,
>codenamed Nautilus and implemented in TTL, was nearly ready for market
>and offered comparable performance.  There was also a slower and lower
>cost system in that series codenamed Skipjack.  When it finally came
>time to market these machines, it was found that the product line
>needed a reduced cost version of Skipjack.  Rather than design a new
>CPU, they just put NOPs in the Skipjack microcode to slow it down.
>The official code name for this machine was Flounder, but within DEC
>engineering we called it "Wimpjack".  Customers could buy a field
>upgrade for Flounder microcode that restored it to Skipjack
>performance levels.
>
>-Paul W.

Re: [TUHS] Old mainframe I/O speed (was: core)

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 1880 bytes --]

On Fri, Jun 22, 2018 at 1:32 AM, Erik E. Fair <fair-tuhs@netbsd.org> wrote:

> 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.
>
Interesting story on the BI.   My friend, Dave Cane who had been #2 on the
780 and lead the 750 project was the primary force behind the BI and
developed by the team in the laboratory products division (LDP).​  The
whole idea behind BI was, BI was supposed to be (i.e. designed as) an
'open' bus and DEC was originally going to license the driver chips to a
number of 3rd parties (I believe Western Digital, Mostek, TI).   The whole
idea was to create a 3rd party market for I/O devices for LDP.   By making
sure everyone use the same interface chips, their was a reasonable belief
that the boards would not break bus protocol and have some of the issues
that they had had with Omibus and Unibus.

But ... once the BI was completed and actually put into the 8800 and the
main line system, DEC central marketing made it private and locked up.
 Dave quit (his resignation letter was sent out on the engining mailing
list -- KO and GB were not happy -- and one of the thing he sites is the
fact that he thought taking the BI private was going to be bad).

FYI: Masscomp was formed shortly there after (my mostly ex-LDP, 750 and VMS
folks) and Dave used MultiBus and later VMEbus for the I/O (but he did a
private SMI like split transaction memory bus).

One of the other BI people, who's name now escapes me, although I can see
his face in my mind, maybe I'll think of it later), would go on to do the
PCI for Alpha a couple of years later.   As I said, DEC did manage to get
that one public, after the BI was made private as Erik points out.



ᐧ

[-- Attachment #2: Type: text/html, Size: 3155 bytes --]

Re: [TUHS] Old mainframe I/O speed (was: core)

[Dave Horsfall]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

On Thu, 21 Jun 2018, Arrigo Triulzi wrote:

>> for the microcode to customers.  There were several hacks in there to 
>> slow down the disk I/O so that it didn't outperform the model 30.
>
> Is this the origin of the lore on “the IBM slowdown device”?

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...

Re: [TUHS] Old mainframe I/O speed (was: core)

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

A complete summary of slowdown devices and eunuch hardware would make a
fascinating document. Every vendor I know of at some point had the "wire
wrap" clock-x-2 upgrade, there is of course the infamous 486/487 story, and
Jon Hall used to love telling the story of the VAX backplane with the glue
in the board slots, which clever customers managed to damage and have
repaired with a non-glued-up backplane.

And on a bigger scale is the tragedy of, e.g., DECs use of its ownership of
Alpha firmware to hamstring its customer-competitors who tried to build
systems with Alpha.
"What are you doing to our Alpha customers? They're selling systems with
Alpha!"
"They're system competitors, we must crush them"

It would be neat to collect them all somewhere ...

[-- Attachment #2: Type: text/html, Size: 896 bytes --]

Re: [TUHS] Old mainframe I/O speed (was: core)

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 590 bytes --]

Don't you love Wikipedia.   As it has been said by others follow the money
(or in this case the law suites)....
ᐧ

On Sun, Jun 24, 2018 at 3:50 AM, Mutiny <mutiny.mutiny@rediffmail.com>
wrote:

> >From: Johnny Billquist <bqt@update.uu.se>
> >To me it sounds as if you are saying that DEC did/designed PCI.
> >Are you sure about that? As far as I know, PCI was designed and created
> >by Intel, and the first users were just plain PC machines.
>
> Work on PCI began at Intel's Architecture Development Lab c. 1990.
> https://en.wikipedia.org/wiki/Conventional_PCI#History
>

[-- Attachment #2: Type: text/html, Size: 1519 bytes --]

Re: [TUHS] Old mainframe I/O speed (was: core)

[Norman Wilson]

Paul Winalski:

  That was the VAXstation-11/RC.

===

Yep, that's the name.

My first batch of discarded MicroVAX IIs were the original
backbone routers for a large university campus, installed
ca. 1990.  That backbone ran over serial-line connections,
at 56Kbps, which was quite impressive for the day given the
physical distances involved.

Either they had a bunch of Qbus backplanes lying around, or
someone computed that the cost of an 11/RC plus a backplane
was appreciably less than a system with an unobstructed
backplane.  In any case, they swapped most of the backplanes
themselves.  The one I got that still had the glue in was an
anomaly; maybe it was a spare chassis.

The MicroVAX routers ran Ultrix, and some of them had uptimes
of five years when they were finally shut down to be discarded.
All the hardware I rescued tested out fine, and some of it is
still running happily in my basement.  I've had a few disk
failures over the years, and I think lost one power supply
back around Y2K and maybe had a DZV11 fail, but that's it.
We don't make hardware like that any more.

Norman Wilson
Toronto ON

Re: [TUHS] Old mainframe I/O speed (was: core)

[Norman Wilson]

Paul Winalski:

  Rather than design a new
  CPU, they just put NOPs in the Skipjack microcode to slow it down.
  The official code name for this machine was Flounder, but within DEC
  engineering we called it "Wimpjack".  Customers could buy a field
  upgrade for Flounder microcode that restored it to Skipjack
  performance levels.

====

As I remember it, once it came out that the upgrade
merely removed gratuitous nops, customers raised sufficient
fuss that the denopped microcode was made available for
free (perhaps only to those with service contracts) and
Flounder (VAX 8500) was no longer sold.

Norman Wilson
Toronto ON

Re: [TUHS] Old mainframe I/O speed (was: core)

[Arthur Krewat]

On 6/24/2018 10:41 AM, Lawrence Stewart wrote:
> Glue or microcode NOPs or DRM licence unlock codes work, but they tend to damage your reputation.

I was called in at the last minute to help a consulting firm who was 
having a hard time convincing their customer that they knew what they 
were doing. They spec'd out a SunFire 4800 cluster back in the mid 
2000's that would run 10 or so medium-to-large OLTP and DW Oracle 
instances. I came across the notion of "Capacity On Demand" (COD) CPU 
licensing. You would buy a complete system, full of CPUS and memory, but 
only license a subset of the CPUs (and associated memory).

The customer thought "great!" we can save a few $'s and if we want, we 
can turn on the extra capacity when/if we need it.

After reading all the documentation, I was on a conference call with 
some Sun engineers, the sales rep, and my customer's team (including 
some of the consultants who were a little too "wet behind the ears".

I point-blank asked the engineers: "I see in the documentation that if 
you use COD, memory interleaving is turned off, which only makes sense. 
Since we're only licensing 3 of every 4 CPU, Doesn't that mean we're 
only going to get half if not one quarter of the platform's advertised 
memory bandwidth?" (Single vs. two-way vs. four-way interleaving. Odd 
number of CPUs, no interleaving). Reluctantly, one of the engineers 
agreed that was indeed the case. The other "engineers" had no freakin' 
clue, but muttered something about "we have to remember that for next 
time".

I roughly calculated the difference in my head and said: "For an extra 
2% of the entire project cost (IBM Shark, Oracle licenses and Sun 
hardware combined), we're going to hobble these systems that much?". 
After the consulting firm I was sub-contracting for balked on telling 
the customer about this extra cost, I mentioned this in the presentation 
for the customer's CIO. She perked up her ears and immediately said 
'We'll spend the extra for that much performance. What were you guys 
thinking?'" (referring to the original consulting firm's own "Sun 
expert" who I'd had a lot of arguments with, actually quit the day they 
signed the contract with Sun).

I wonder, to this day, how many Sun customers were sold this COD concept 
only to suffer through 1/2 or 1/4 the memory bandwidth. This was for the 
entire SunFire 3800/4800/4810/6800/E12K/E15K line.

I went on to support that system for 5 more years as the customer 
wouldn't let the consulting firm even THINK of letting me leave ;)

art k.

Re: [TUHS] Old mainframe I/O speed (was: core)

[Lawrence Stewart]

> On 2018, Jun 24, at 9:03 AM, Paul Winalski <paul.winalski@gmail.com> wrote:
> 
> On 6/23/18, Norman Wilson <norman@oclsc.org> wrote:
>> Ron Minnich:
>> 
>>  Jon Hall used to love telling the story of the VAX backplane with the
>> glue
>>  in the board slots, which clever customers managed to damage and have
>>  repaired with a non-glued-up backplane.
> 
> That was the VAXstation-11/RC.  Marketing wanted a VAXstation with
> fewer backplane slots that it could sell at a cheaper price.  Rather
> than manufacture a different board, they just filled the extra
> backplane slots with glue to render them unusable.  "RC" officially
> stood for "restricted configuration", but we in Engineering called it
> "resin caulked".
> 
> -Paul W.

Some customers of the 11/RC figured out how to buy the full backplane as “spare parts” which worked for a while.

Every industry with up-front R&D or capital costs has the problem that the marginal cost of goods is much lower than the average cost.  It happens to airlines, chip companies, system companies and especially commercial software companies.  Trying to introduce product differentiation is one solution. Glue or microcode NOPs or DRM licence unlock codes work, but they tend to damage your reputation.

-L

Re: [TUHS] Old mainframe I/O speed (was: core)

[Paul Winalski]

On 6/23/18, Norman Wilson <norman@oclsc.org> wrote:
> Ron Minnich:
>
>   Jon Hall used to love telling the story of the VAX backplane with the
> glue
>   in the board slots, which clever customers managed to damage and have
>   repaired with a non-glued-up backplane.

That was the VAXstation-11/RC.  Marketing wanted a VAXstation with
fewer backplane slots that it could sell at a cheaper price.  Rather
than manufacture a different board, they just filled the extra
backplane slots with glue to render them unusable.  "RC" officially
stood for "restricted configuration", but we in Engineering called it
"resin caulked".

-Paul W.

Re: [TUHS] Old mainframe I/O speed (was: core)

[Mutiny]

[-- Attachment #1: Type: text/plain, Size: 387 bytes --]

>From: Johnny Billquist <bqt@update.uu.se>>To me it sounds as if you are saying that DEC did/designed PCI.>Are you sure about that? As far as I know, PCI was designed and created>by Intel, and the first users were just plain PC machines.Work on PCI began at Intel's Architecture Development Lab c. 1990. https://en.wikipedia.org/wiki/Conventional_PCI#History

[-- Attachment #2: Type: text/html, Size: 489 bytes --]

Re: [TUHS] Old mainframe I/O speed (was: core)

[Norman Wilson]

Ron Minnich:

  Jon Hall used to love telling the story of the VAX backplane with the glue
  in the board slots, which clever customers managed to damage and have
  repaired with a non-glued-up backplane.

=====

It wasn't exactly a VAX backplane; it was a QBus backplane,
though I don't know whether this marketing-induced castration
was performed on anywhere but on the backplaces of certain
MicroVAX models.

I think one of my saved-from-the-dumpster BA23s had one
of those backplanes.  I just declared it to be a source
of spare parts, other than backplanes.

Norman Wilson
Toronto ON

Re: [TUHS] Old mainframe I/O speed (was: core)

[Clem cole]

PCI was a late 1980s DEC design bus design that where released via license ala the Ethernet experience of  the xerox/dec/Intel blue book.  DEC had mostly learned it lesson that interface standards were better shared.  I’ve forgotten now the name of the person who lead the team.  I did not know him very well.  I can picture his face as I said.  

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Jun 23, 2018, at 6:32 AM, Johnny Billquist <bqt@update.uu.se> wrote:
> 
>> On 2018-06-22 20:01, Clem Cole<clemc@ccc.com> wrote:
>> One of the other BI people, who's name now escapes me, although I can see
>> his face in my mind, maybe I'll think of it later), would go on to do the
>> PCI for Alpha a couple of years later.   As I said, DEC did manage to get
>> that one public, after the BI was made private as Erik points out.
> 
> Clem, I think I saw you say something similar in an earlier post.
> To me it sounds as if you are saying that DEC did/designed PCI.
> Are you sure about that? As far as I know, PCI was designed and created by Intel, and the first users were just plain PC machines.
> Alpha did eventually also get PCI, but it was not where it started, and DEC had no control at all about PCI being public.
> 
> Might you have been thinking of Turbobus, Futurebus, or some other thing that DEC did? Or do you have some more information about DEC being the creator of PCI?
> 
>  Johnny
> 
> -- 
> Johnny Billquist                  || "I'm on a bus
>                                  ||  on a psychedelic trip
> email: bqt@softjar.se             ||  Reading murder books
> pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Re: [TUHS] Old mainframe I/O speed (was: core)

[Johnny Billquist]

On 2018-06-22 20:01, Clem Cole<clemc@ccc.com> wrote:
> One of the other BI people, who's name now escapes me, although I can see
> his face in my mind, maybe I'll think of it later), would go on to do the
> PCI for Alpha a couple of years later.   As I said, DEC did manage to get
> that one public, after the BI was made private as Erik points out.

Clem, I think I saw you say something similar in an earlier post.
To me it sounds as if you are saying that DEC did/designed PCI.
Are you sure about that? As far as I know, PCI was designed and created 
by Intel, and the first users were just plain PC machines.
Alpha did eventually also get PCI, but it was not where it started, and 
DEC had no control at all about PCI being public.

Might you have been thinking of Turbobus, Futurebus, or some other thing 
that DEC did? Or do you have some more information about DEC being the 
creator of PCI?

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Re: [TUHS] Old mainframe I/O speed (was: core)

[Erik E. Fair]

>Date: Fri, 22 Jun 2018 09:11:29 -0400 (EDT)
>From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
>
>    > From: "Erik E. Fair"
>
>    > 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 and tried reported their
>    > experiences) to be a lie.
>
>Just out of curiousity, why'd you all order something you knew wouldn't work?
>So you could get a better deal out of DEC for whatever you ordered instead,
>later, as they tried to make it up to you all for trying to sell you something
>broken?

Precisely. It worked too, at some cost in our time. The DEC salespeople were willing to put their lie in writing, you see ...

One of those 8650s was "apple.com" (host) for quite a number of years, as the 11/780 before it: DNS primary NS for the domain, SMTP server, NTP server (VAXen had decent, low-drift hardware clocks), UUCP/USENET host (as "apple" in that world), NNTP server - it was our public face to the world. I was given the explicit mandate to make it so when I was hired in 1988.

Unix was the OS for a wide range of facilities within Apple. Probably still is (I've been gone from there since 1997, but I still hear from folks within from time to time). As hardware got cheaper and more capable, other systems were added to the mix to provide anonymous FTP (ftp.apple.com started as a Mac IIci running A/UX under my desk), HTTP service, and so on.

The main thing that changed over time was what hardware (and version of Unix) we were running for whatever task or service (the RISC bloom was wonderful to see, even if the vendors tried bending Unix in to a proprietary lock-in thing - it's rather sad that we're mostly stuck with the awful x86 ISA after all that), and the overall character of the system use. When I arrived, Unix was used as a now-classical interactive timesharing system (with Macs as terminals - does anyone else remember the wonderful "UnixWindows" multi-windowing terminal emulator for MacOS, with its associated Unix back-end?), and by the time I left, Macs were TCP/IP hosts (peers) themselves, speaking as clients (IMAP, NNTP, HTTP) over our networks to Unix machines as servers.

	Erik Fair

Re: [TUHS] Old mainframe I/O speed (was: core)

[Noel Chiappa]

    > From: "Erik E. Fair"

    > 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 and tried reported their
    > experiences) to be a lie.

Just out of curiousity, why'd you all order something you knew wouldn't work?
So you could get a better deal out of DEC for whatever you ordered instead,
later, as they tried to make it up to you all for trying to sell you something
broken?

	Noel