Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.folklore.computers > #220214 > unrolled thread

TOPS-20 Boot Camp for VMS Users 05-Mar-2022

Back to article view | Back to alt.folklore.computers

Contents

  TOPS-20 Boot Camp for VMS Users 05-Mar-2022 "Stephen M. Jones" <smj@ma.sdf.org> - 2022-03-02 21:32 +0000
    Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-03 14:30 +0000
      Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Ahem A Rivet's Shot <steveo@eircom.net> - 2022-03-03 16:38 +0000
        Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-03 17:13 +0000
          Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Rich Alderson <news@alderson.users.panix.com> - 2022-03-03 15:33 -0500
            Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-03 21:55 +0000
              Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-03-04 12:06 -0700
                Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Paul Rubin <no.email@nospam.invalid> - 2022-03-04 13:23 -0800
                  Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Johnny Billquist <bqt@softjar.se> - 2022-03-06 17:29 +0100
                    Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-03-06 11:34 -0700
                      Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-06 19:40 +0000
                      Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Charles Richmond <codescott@aquaporin4.com> - 2022-12-23 11:49 -0600
                      Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Anne & Lynn Wheeler <lynn@garlic.com> - 2022-12-23 10:34 -1000
                        Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Ahem A Rivet's Shot <steveo@eircom.net> - 2022-12-23 21:42 +0000
                          Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Vir Campestris <vir.campestris@invalid.invalid> - 2022-12-24 11:54 +0000
                            Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 D.J. <chucktheouch@gmnol.com> - 2022-12-24 11:17 -0600
                              Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 D.J. <chucktheouch@gmnol.com> - 2022-12-24 18:01 -0600
                                Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-12-25 11:24 -0700
                              Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Anne & Lynn Wheeler <lynn@garlic.com> - 2022-12-25 09:12 -1000
                              Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Vir Campestris <vir.campestris@invalid.invalid> - 2022-12-30 17:06 +0000
                                Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2022-12-30 19:09 +0000
                                Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 D.J. <chucktheouch@gmnol.com> - 2022-12-30 16:11 -0600
                              Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Thomas Koenig <tkoenig@netcologne.de> - 2022-12-30 20:22 +0000
                                Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 D.J. <chucktheouch@gmnol.com> - 2022-12-30 16:12 -0600
                                Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2022-12-30 23:44 +0000
                        Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Anne & Lynn Wheeler <lynn@garlic.com> - 2022-12-23 12:18 -1000
                        Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2022-12-24 03:43 +0000
                          Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Anne & Lynn Wheeler <lynn@garlic.com> - 2022-12-24 07:55 -1000
                          Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-12-24 11:08 -0700
                            Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-12-24 18:36 +0000
                            Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2022-12-24 21:09 +0000
                            Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Anne & Lynn Wheeler <lynn@garlic.com> - 2022-12-24 14:03 -1000
                          Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Anne & Lynn Wheeler <lynn@garlic.com> - 2022-12-24 14:46 -1000
                    Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Paul Rubin <no.email@nospam.invalid> - 2022-03-06 11:17 -0800
                      Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Johnny Billquist <bqt@softjar.se> - 2022-03-07 17:53 +0100
                        Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Vir Campestris <vir.campestris@invalid.invalid> - 2022-03-07 22:02 +0000
                          Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Charles Richmond <codescott@aquaporin4.com> - 2022-12-23 11:55 -0600
                            Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-12-23 12:27 -0700
                    Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2022-03-07 03:11 +0000
                Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Quadibloc <jsavard@ecn.ab.ca> - 2022-12-30 13:57 -0800
                  Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Niklas Karlsson <nikke.karlsson@gmail.com> - 2022-12-30 22:11 +0000
                    Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2022-12-30 23:44 +0000
                      Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Niklas Karlsson <nikke.karlsson@gmail.com> - 2022-12-30 23:56 +0000
                        Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 cb@elaine.df.lth.se (Christian Brunschen) - 2022-12-31 09:02 +0000
                  Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Rich Alderson <news@alderson.users.panix.com> - 2022-12-30 20:44 -0500
                  Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-12-30 20:08 -0700
                    Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Quadibloc <jsavard@ecn.ab.ca> - 2022-12-31 00:25 -0800
                      Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Johnny Billquist <bqt@softjar.se> - 2022-12-31 13:39 +0100
            Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Bob Eager <news0009@eager.cx> - 2022-03-04 00:46 +0000
              Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 "Stephen M. Jones" <smj@ma.sdf.org> - 2022-03-04 18:49 +0000
                Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 drb@ihatespam.msu.edu (Dennis Boone) - 2022-03-04 14:55 -0600
                  Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-04 22:14 +0000
                    Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Bob Eager <news0009@eager.cx> - 2022-03-04 22:17 +0000
                      Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 David Lesher <wb8foz@panix.com> - 2022-03-06 04:35 +0000
                      Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Ahem A Rivet's Shot <steveo@eircom.net> - 2022-03-06 05:40 +0000
              Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Rich Alderson <news@alderson.users.panix.com> - 2022-03-04 22:46 -0500
            Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Johnny Billquist <bqt@softjar.se> - 2022-03-06 17:21 +0100
              Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-03-06 11:34 -0700
                Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Johnny Billquist <bqt@softjar.se> - 2022-03-07 17:42 +0100
              Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Rich Alderson <news@alderson.users.panix.com> - 2022-03-06 20:43 -0500
                Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-07 15:07 +0000
                  Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Johnny Billquist <bqt@softjar.se> - 2022-03-07 17:51 +0100
                    Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-07 17:07 +0000
                      Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-03-07 11:47 -0700
                        Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-07 19:19 +0000
                        Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Andreas Eder <a_eder_muc@web.de> - 2022-03-08 10:08 +0100
                          Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-03-08 07:49 -0700
                            Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2022-03-08 19:47 +0000
                              Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Bob Eager <news0009@eager.cx> - 2022-03-09 01:03 +0000
                      Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Johnny Billquist <bqt@softjar.se> - 2022-03-07 20:18 +0100
                        Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-07 19:37 +0000
                          Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Dan Espen <dan1espen@gmail.com> - 2022-03-07 14:53 -0500
                            Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-07 20:43 +0000
                        Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Ahem A Rivet's Shot <steveo@eircom.net> - 2022-03-07 19:52 +0000
                  Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Rich Alderson <news@alderson.users.panix.com> - 2022-03-07 17:18 -0500
                    Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-07 22:33 +0000
                      Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-07 22:58 +0000
                        Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Johnny Billquist <bqt@softjar.se> - 2022-03-08 00:06 +0100
                      Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-03-08 07:49 -0700
                        Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-08 15:22 +0000
                          Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-03-08 11:17 -0700
                        Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Vir Campestris <vir.campestris@invalid.invalid> - 2022-03-08 21:09 +0000
                          Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-08 21:33 +0000
                Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Johnny Billquist <bqt@softjar.se> - 2022-03-07 20:24 +0100
        Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Rich Alderson <news@alderson.users.panix.com> - 2022-03-03 15:24 -0500
          Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Ahem A Rivet's Shot <steveo@eircom.net> - 2022-03-03 21:06 +0000
            Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Rich Alderson <news@alderson.users.panix.com> - 2022-03-04 22:47 -0500
      Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-03-04 12:06 -0700
      Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 D.J. <chucktheouch@gmail.com> - 2022-03-07 10:48 -0600
        Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-07 17:03 +0000
          Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 D.J. <chucktheouch@gmail.com> - 2022-03-07 19:52 -0600
            Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Fred Smith <fred@thejanitor.corp> - 2022-03-08 04:13 +0000
              Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Johnny Billquist <bqt@softjar.se> - 2022-03-08 16:32 +0100

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#223297

On 2022-12-30, Vir Campestris <vir.campestris@invalid.invalid> wrote:

> On 24/12/2022 17:17, D.J. wrote:
>
>> The Cray YMP-2 had a non-conductive fluid that flowed across the
>> circuit boards, then out to a head exchanger.
>
> Liquid cooling is not uncommon.
>
> Boiling liquid cooling has all sorts of problems, which is what Steve 
> suggested.

I can't help but visualize a car pulled over to the side of the road
with its radiator boiling over.  Maybe Tesla will bring it back.

-- 
/~\  Charlie Gibbs                  |  Microsoft is a dictatorship.
\ /  <cgibbs@kltpzyxm.invalid>      |  Apple is a cult.
 X   I'm really at ac.dekanfrus     |  Linux is anarchy.
/ \  if you read it the right way.  |  Pick your poison.

[toc] | [prev] | [next] | [standalone]

#223301

On Fri, 30 Dec 2022 17:06:35 +0000, Vir Campestris
<vir.campestris@invalid.invalid> wrote:
>On 24/12/2022 17:17, D.J. wrote:
>> The Cray YMP-2 had a non-conductive fluid that flowed across the
>> circuit boards, then out to a head exchanger.
>
>Liquid cooling is not uncommon.
>
>Boiling liquid cooling has all sorts of problems, which is what Steve 
>suggested.
>
>Andy

Yeah, I can see that would be a problem if a leak happened.
--  
Jim

[toc] | [prev] | [next] | [standalone]

#223298

D.J <chucktheouch@gmnol.com> schrieb:
> On Sat, 24 Dec 2022 11:54:10 +0000, Vir Campestris
><vir.campestris@invalid.invalid> wrote:
>>On 23/12/2022 21:42, Ahem A Rivet's Shot wrote:
>>> 	I think the cleverest twist in system cooling has to be the trick of
>>> immersing the whole thing in an inert fluid that boils at 50C with a
>>> fan assisted condenser at the top.
>>
>>The problem with that is hot spots under the bubbles. You'll need a 
>>decent heat spreader too.
>>
>>Andy
>
> The Cray YMP-2 had a non-conductive fluid that flowed across the
> circuit boards, then out to a head exchanger.

Not sure I'd want to have my head exchanged, I'd stay well clear
of that machine :-)

[toc] | [prev] | [next] | [standalone]

#223303

On Fri, 30 Dec 2022 20:22:44 -0000 (UTC), Thomas Koenig
<tkoenig@netcologne.de> wrote:
>D.J <chucktheouch@gmnol.com> schrieb:
>> On Sat, 24 Dec 2022 11:54:10 +0000, Vir Campestris
>><vir.campestris@invalid.invalid> wrote:
>>>On 23/12/2022 21:42, Ahem A Rivet's Shot wrote:
>>>> 	I think the cleverest twist in system cooling has to be the trick of
>>>> immersing the whole thing in an inert fluid that boils at 50C with a
>>>> fan assisted condenser at the top.
>>>
>>>The problem with that is hot spots under the bubbles. You'll need a 
>>>decent heat spreader too.
>>>
>>>Andy
>>
>> The Cray YMP-2 had a non-conductive fluid that flowed across the
>> circuit boards, then out to a head exchanger.
>
>Not sure I'd want to have my head exchanged, I'd stay well clear
>of that machine :-)

Yeah, typo. I did correct it, but maybe the correction didn't make it.
Too few new charactrers.
--  
Jim

[toc] | [prev] | [next] | [standalone]

#223304

On 2022-12-30, Thomas Koenig <tkoenig@netcologne.de> wrote:

> D.J <chucktheouch@gmnol.com> schrieb:
>
>> On Sat, 24 Dec 2022 11:54:10 +0000, Vir Campestris
>> <vir.campestris@invalid.invalid> wrote:
>>
>>> On 23/12/2022 21:42, Ahem A Rivet's Shot wrote:
>>>
>>>> 	I think the cleverest twist in system cooling has to be the trick of
>>>> immersing the whole thing in an inert fluid that boils at 50C with a
>>>> fan assisted condenser at the top.
>>>
>>> The problem with that is hot spots under the bubbles. You'll need a 
>>> decent heat spreader too.
>>
>> The Cray YMP-2 had a non-conductive fluid that flowed across the
>> circuit boards, then out to a head exchanger.
>
> Not sure I'd want to have my head exchanged, I'd stay well clear
> of that machine :-)

This reminds me of a couple of scenes from _Red Dwarf_
(perhaps with a bit of _Sleeper_ thrown in for good measure).

-- 
/~\  Charlie Gibbs                  |  Microsoft is a dictatorship.
\ /  <cgibbs@kltpzyxm.invalid>      |  Apple is a cult.
 X   I'm really at ac.dekanfrus     |  Linux is anarchy.
/ \  if you read it the right way.  |  Pick your poison.

[toc] | [prev] | [next] | [standalone]

#223236

Anne & Lynn Wheeler <lynn@garlic.com> writes:
> IBM mainframe this century
>
> z900, 16 processors, 2.5BIPS (156MIPS/proc), Dec2000
> z990, 32 processors, 9BIPS, (281MIPS/proc), 2003
> z9, 54 processors, 18BIPS (333MIPS/proc), July2005
> z10, 64 processors, 30BIPS (469MIPS/proc), Feb2008
> z196, 80 processors, 50BIPS (625MIPS/proc), Jul2010
> EC12, 101 processors, 75BIPS (743MIPS/proc), Aug2012
> z13, 140 processors, 100BIPS (710MIPS/proc), Jan2015
> z14, 170 processors, 150BIPS (862MIPS/proc), Aug2017
> z15, 190 processors, 190BIPS* (1000MIPS/proc), Sep2019
>
> * pubs say z15 1.25 times z14 (1.25*150BIPS or 190BIPS)
> * z16, 200?? processors, ???BIPS (???MIPS/proc), 

other trivia: 1980, STL (since renamed silicon valley lab) was bursting
at the seams and were moving 300 people from the IMS group to offsite
bldg (with dataprocessing back to STL datacenter). They had tried
"remote 3270" terminals, but found the human factors totally
unacceptable (especially compared to channel attached 3270 controlers in
STL bldg).  I get con'ed into doing channel extender support
... allowing channel attached controllers to be placed at offsite bldg
... with no perceptable human factors difference between offsite and
inside STL.

Then the hardware vendor tries to get IBM to release my support, but
there are some engineers in POK playing with some serial stuff who get
that vetoed (because they were afraid if it was in the market, it would
make it harder to get their stuff released).

In 1988, the IBM branch wants me to help LLNL standardize some stuff
they are playing with, ... which quickly becomes FCS (including some
stuff that I had done in 1980), initially full-duplex 1gbit, 2gbit
aggregate, 200mbytes/sec

The POK people finally get their stuff released in 1990 with ES/9000 as
ESCON, when it is already obsolete (17mbytes/sec). Some POK engineers
start playing with FCS and define a heavy weight protocol that
drastically reduces the native throughput, which eventually ships as
FICON. The most recent public benchmark I can find is z196 "peak I/O"
which gets 2M IOPS aggregate using 104 FICON. About the same time there
was a FCS announced for E5-2600 claiming over million IOPS (two such FCS
getting higher throughput than 104 FICON) ... and E5-2600 blade at
500BIPS is ten times processing of max configured z196 50BIPS.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

[toc] | [prev] | [next] | [standalone]

#223239

On 2022-12-23, Anne & Lynn Wheeler <lynn@garlic.com> wrote:

> Peter Flass <peter_flass@yahoo.com> writes:
>
>> IBM never used MIPS either, but rated processors relative to each other.
>> I always thought they did this to avoid comparisons to other vendors’
>> machines, but it was probably as much because it was meaningless, as you
>> say.
>
> IBM tries stamp out industry standard benchmark numbers for their
> mainframes.

After all, MIPS really stands for
"Meaningless Indication of Processor Speed".

-- 
/~\  Charlie Gibbs                  |  Microsoft is a dictatorship.
\ /  <cgibbs@kltpzyxm.invalid>      |  Apple is a cult.
 X   I'm really at ac.dekanfrus     |  Linux is anarchy.
/ \  if you read it the right way.  |  Pick your poison.

[toc] | [prev] | [next] | [standalone]

#223246

Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
> After all, MIPS really stands for
> "Meaningless Indication of Processor Speed".

... "stamping out" benchmarks for mainframes ...  not just MIPS
(conflating that they are actual count of instructions frequently
highlighting significant RISC/CISC differences ... rather than industry
benchmark is number of program iterations per second compared to
reference platform) ... but also TPC (transactions/sec, $$/transaction,
power/transaction) and other of the ilk ... however participate in
benchmarks for their non-mainframe platforms.

reminiscence of the enormous marketing FUD from the 70s Future System
days where internal politics from the Future System project was killing
off 370 efforts ... and the lack of new IBM 370 products was credited
with giving the 370 clone makers their market foothold (leaving IBM
marketing little else but "Fear, Uncertainty, and Doubt")

some FS details:
http://www.jfsowa.com/computer/memo125.htm
http://people.cs.clemson.edu/~mark/fs.html

before that ... killing off ACS/360 because executives were afraid that
it would advance state-of-the-art too fast and IBM would loose control
of the market:
https://people.cs.clemson.edu/~mark/acs_end.html

above list some of the ACS/360 features that don't show up until more
than 20yrs later with ES/9000.

another FUD trivia: 3880 was designed to handle the 3mbyte/sec 3380
transfer speed ... along with data streaming channel architecture
(previously enormous channel protocol chatter with end-to-end handshake
for ever byte transferred, 3mbyte channels allowed multi-byte transfer
per end-to-end handshake). The trout/3090 effort had number of channels
assuming 3880 was similar to the previous 3830 but with 3380 3mbyte/sec
transfer. However, 3880 had special hardware path for data transfer but
everything else was done by an extremely slow "vertical" microcode
processor (not the much faster 3830 "horizontal" microcode processor).
When trout/3090 finally found out that the 3880 channel busy would be
significantly larger than anticipated, they realized that had to
significantly increase the number of channels ... in order to achieve
IOPS required to achieve targeted system throughput. It turns out that
the increase in channels required an additional (expensive) TCM. They
joked that they were going to bill the 3880 organization for the
increase in 3090 manufactoring cost (additional TCM).

Note that marketing eventually respins the significant increase in
channels for 3090 (compared to previsious mainframe genereations)
... needed to compensate for the enormous increase 3880 channel
busy ... as making the 3090 and wonderful I/O machine.

This is somewhat analogous to the peak I/O z196 benchmark of 2M IOPS
reqired 104 FICON (FICON protocol running over FCS) compared to IOPS
for single native FCS of over a million.

recent post on linkedin
https://www.linkedin.com/pulse/mainframe-channel-io-lynn-wheeler/

-- 
virtualization experience starting Jan1968, online at home since Mar1970

[toc] | [prev] | [next] | [standalone]

#223247

Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2022-12-23, Anne & Lynn Wheeler <lynn@garlic.com> wrote:
> 
>> Peter Flass <peter_flass@yahoo.com> writes:
>> 
>>> IBM never used MIPS either, but rated processors relative to each other.
>>> I always thought they did this to avoid comparisons to other vendors’
>>> machines, but it was probably as much because it was meaningless, as you
>>> say.
>> 
>> IBM tries stamp out industry standard benchmark numbers for their
>> mainframes.
> 
> After all, MIPS really stands for
> "Meaningless Indication of Processor Speed".
> 

On the other tentacle, comparing one IBM processor to another makes the
most sense for current customers looking to upgrade. “Oh, this new one is
twice as fast as what we have now.” MIPS would be a lot less meaningful to
this group.

-- 
Pete

[toc] | [prev] | [next] | [standalone]

#223249

Peter Flass <peter_flass@yahoo.com> writes:
>Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>> On 2022-12-23, Anne & Lynn Wheeler <lynn@garlic.com> wrote:
>> 
>>> Peter Flass <peter_flass@yahoo.com> writes:
>>> 
>>>> IBM never used MIPS either, but rated processors relative to each other.
>>>> I always thought they did this to avoid comparisons to other vendors’
>>>> machines, but it was probably as much because it was meaningless, as you
>>>> say.
>>> 
>>> IBM tries stamp out industry standard benchmark numbers for their
>>> mainframes.
>> 
>> After all, MIPS really stands for
>> "Meaningless Indication of Processor Speed".
>> 
>
>On the other tentacle, comparing one IBM processor to another makes the
>most sense for current customers looking to upgrade. “Oh, this new one is
>twice as fast as what we have now.” MIPS would be a lot less meaningful to
>this group.

Burroughs used "RPM" (Relative Performance Measure) to compare both within
the Burroughs mainframes and between Burroughs and IBM mainframes.

RPM was derived from the results of running a basket of typical customer
applications:

  * On-line Banking Simulator
  * COBOL 74 Cross Reference
  * Document Editor (COBOL74)
  * Factory Material Requirements Planning
  * Grocery Warehouse Inventory (Forte 2)
  * DMPALL Disk to Disk Transfer
  * Treasury Tax and Loan System

These applications were also run on various IBM machines for
apples-to-apples comparisions.

These measure whole-system performance (CPU, I/O Subsystem, etc)
rather than pure CPU speed.

[toc] | [prev] | [next] | [standalone]

#223251

On 2022-12-24, Peter Flass <peter_flass@yahoo.com> wrote:

> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>
>> On 2022-12-23, Anne & Lynn Wheeler <lynn@garlic.com> wrote:
>> 
>>> Peter Flass <peter_flass@yahoo.com> writes:
>>> 
>>>> IBM never used MIPS either, but rated processors relative to each other.
>>>> I always thought they did this to avoid comparisons to other vendors’
>>>> machines, but it was probably as much because it was meaningless, as you
>>>> say.
>>> 
>>> IBM tries stamp out industry standard benchmark numbers for their
>>> mainframes.
>> 
>> After all, MIPS really stands for
>> "Meaningless Indication of Processor Speed".
>
> On the other tentacle, comparing one IBM processor to another makes the
> most sense for current customers looking to upgrade.

At least for CPU-bound jobs.

> “Oh, this new one is twice as fast as what we have now.” MIPS would be
> a lot less meaningful to this group.

"Oh wow, my bubble sort runs in half the time now!"

-- 
/~\  Charlie Gibbs                  |  Microsoft is a dictatorship.
\ /  <cgibbs@kltpzyxm.invalid>      |  Apple is a cult.
 X   I'm really at ac.dekanfrus     |  Linux is anarchy.
/ \  if you read it the right way.  |  Pick your poison.

[toc] | [prev] | [next] | [standalone]

#223255

Peter Flass <peter_flass@yahoo.com> writes:
> On the other tentacle, comparing one IBM processor to another makes the
> most sense for current customers looking to upgrade. “Oh, this new one is
> twice as fast as what we have now.” MIPS would be a lot less meaningful to
> this group.

the previous story about no. of channels and i/o throughput for 3090
... was to have sufficient concurrent work load to keep cpu busy (in
aggregate) ... i/o throughput power matching cpu throughput power.

the story this was the justification of making all 370s, virtual memory
machines ... customer asked me a decade ago to track down the decision;
found somebody that reported to the executive. Bascially (OS/360) MVT
storage management was so bad that region sizes had to be usually four
times larger than actually used ... as a result it restricted number of
concurrently executing regions for typical 1mbyte 370/165 to four
... insufficient to keep processor adequately justified and busy.

Going to 16mbyte virtual memory, allowed increasing number of
concurrently executing regions by four times ... with little or no
paging. Original VS2 was SVS ... very similar to running MVT in a CP67
16mbyte virtual machine. The biggest code change was for channel program
copies with virtual addresses translated to real ... OS/360 running in
CP67 virtual machines had I/O channel programs with virtual addresses
and CP67 "CCWTRANS" made copies of the virtual machine channel programs
where the virtual addresses replaced with real addresses.

OS/360 had libraries executed by application programs, generating I/O
channel programs and then invoking (kernel SVC0) EXCP to invoke the
channel program. In VS2/SVS (and later MVS), EXCP had same problem (as
CP67) making I/O channel program copy, replacing virtual addresses with
real addresses. The initial VS2 implementation borrowed CP67 CCWTRANS
and crafted it into EXCP.

old archived post from decade ago with pieces of the email exchange
about MVT (bad) storage management was motivation for making all 370s,
virtual memory machines.
http://www.garlic.com/~lynn/2011d.html#73

other trivia is seen in EC12->z13 numbers (from upthread post), max
configurations, had EC12/75BIPS going to z13/100BIPS ... but EC12 had
101 743MIPS processors while z13 had 140 710MIPS processors (1/3rd
increase in aggregate MIPS by having 40% increase in number of
processors with slightly lower MIPS).

one of my other comparisons was communication group fiercely fighting
off client/server and distributed computing, also trying to block
release of mainframe TCP/IP support ... when they lost, somewhat because
of univ. demand ... the communication group changed their tactic and
said that since they had corporate strategic responsibility for
everything that crossed datacenter walls, it had to be shipped through
them. What shipped, used nearly a while 3090 processor getting
44kbytes/sec aggregate throughput. I then did the changes for RFC1044
and in some tuning tests at Cray Research between IBM 4341 (about
1+mips) and cray, got sustained channel I/O throughput (about 500 times
improvement in bytes moved per instruction executed).

A few years later, the communication group hired silicon valley
contractor to implement TCP/IP directly in VTAM. What he demo'ed had TCP
running much faster than (SNA) LU6.2. He was then told that everybody
"knows" thaa a "proper" TCP/IP implementation is much slower than LU6.2
... and they would only be paying for a "proper" implementation.

In that time-frame there was analysis that had (mainframe) pathlength
for VTAM/LU6.2 at 160K instructions and 15 buffer copies ... while UNIX
TCP/IP pathlength was 5K instructions and 5 buffer copies. Other
history about IBM (mainframe) downfall
https://www.linkedin.com/pulse/ibm-downfall-lynn-wheeler/
and
https://www.linkedin.com/pulse/john-boyd-ibm-wild-ducks-lynn-wheeler/

-- 
virtualization experience starting Jan1968, online at home since Mar1970

[toc] | [prev] | [next] | [standalone]

#223256

Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
> After all, MIPS really stands for
> "Meaningless Indication of Processor Speed".

... as an aside, IBM mainframe has hyping its faster processor Ghz and
no hardware multi-threading ... somehow trying to imply it corresponded
to faster instruction execution ... when the mainframe didn't come close
to approaching processor power of other platforms i.e. totally lacked
out-of-order (and multi-threaded) cache miss compensation until z196 and
then only started to evolve the technology.

this century articles started to appear that (cache miss) memory
latency, when measured in count of processor cycles is comparable to 60s
IBM 360 mainframe disk access latency, when measured in count of 360
mainframe processor cycles.

The (relatively) huge wait for 360 mainframe for disk I/O was some of
the motivation for software multiprogramming and multithreading.

This started to appear at the hardware level with caches (and cache
misses), with waiting for memory is the modern equivalent to 60s waiting
for disk I/O ... giving rise to things like hardware multithreading,
out-of-order execution, branch prediction and speculative execution

IBM mainframes were very late to this game, while at the same time, they
were exhacerbating the memory latency problem with increasing processor
Ghz speeds ... emphasizing faster Ghz speeds while discounting industry
standard MIPS benchmarks (which had better correlation with actually
processor throughput, not physically counting instructions ... but
counting program iterations compared to the reference platform).

-- 
virtualization experience starting Jan1968, online at home since Mar1970

[toc] | [prev] | [next] | [standalone]

#220252

Johnny Billquist <bqt@softjar.se> writes:
> The KL10 was about 1.5 MIPS, while the original VAX-11/780 was 1 MIPS.

Ah ok, for some reason I had thought the KL10 was faster than that.
EIther way: "36 bits -- a full DEC"  ;-)

[toc] | [prev] | [next] | [standalone]

#220264

On 2022-03-06 20:17, Paul Rubin wrote:
> Johnny Billquist <bqt@softjar.se> writes:
>> The KL10 was about 1.5 MIPS, while the original VAX-11/780 was 1 MIPS.
> 
> Ah ok, for some reason I had thought the KL10 was faster than that.
> EIther way: "36 bits -- a full DEC"  ;-)

You are not alone. Lots of people seem to think the KL10 was way faster 
than it was.

Anyway, I still appreciate the 36-bit quote. But deep down inside, I'm a 
PDP-11 person. :-D

   Johnny

[toc] | [prev] | [next] | [standalone]

#220275

On 07/03/2022 16:53, Johnny Billquist wrote:
> On 2022-03-06 20:17, Paul Rubin wrote:
>> Johnny Billquist <bqt@softjar.se> writes:
>>> The KL10 was about 1.5 MIPS, while the original VAX-11/780 was 1 MIPS.
>>
>> Ah ok, for some reason I had thought the KL10 was faster than that.
>> EIther way: "36 bits -- a full DEC"  ;-)
> 
> You are not alone. Lots of people seem to think the KL10 was way faster 
> than it was.
> 
> Anyway, I still appreciate the 36-bit quote. But deep down inside, I'm a 
> PDP-11 person. :-D
> 

TOPS-10 was where I first met assembler.

I thought the KL10 was _slower_ than that.

And how come I can still remember the instruction word format 
(9-4-1-4-18) 40 years later?

Andy

[toc] | [prev] | [next] | [standalone]

#223229

On 3/7/2022 4:02 PM, Vir Campestris wrote:
> On 07/03/2022 16:53, Johnny Billquist wrote:
>> On 2022-03-06 20:17, Paul Rubin wrote:
>>> Johnny Billquist <bqt@softjar.se> writes:
>>>> The KL10 was about 1.5 MIPS, while the original VAX-11/780 was 1 MIPS.
>>>
>>> Ah ok, for some reason I had thought the KL10 was faster than that.
>>> EIther way: "36 bits -- a full DEC"  ;-)
>>
>> You are not alone. Lots of people seem to think the KL10 was way 
>> faster than it was.
>>
>> Anyway, I still appreciate the 36-bit quote. But deep down inside, I'm 
>> a PDP-11 person. :-D
>>
> 
> TOPS-10 was where I first met assembler.
> 
> I thought the KL10 was _slower_ than that.
> 
> And how come I can still remember the instruction word format 
> (9-4-1-4-18) 40 years later?
> 
> Andy
> 

"The Dinner Cafe's food stays hot!!!  You can feel the food burning in 
your stomach hours later..."   ;-)

And how many advertising jingles can you sing... from television 
commercials that were shown 40 years ago???  I can sing quite a few... 
Perhaps I can make money with this... people might pay me *not* to 
sing!!! ;-)

"A gentleman is a man who can play the bagpipes... and doesn't."


-- 

Charles Richmond


-- 
This email has been checked for viruses by Avast antivirus software.
www.avast.com

[toc] | [prev] | [next] | [standalone]

#223231

Charles Richmond <codescott@aquaporin4.com> wrote:
> On 3/7/2022 4:02 PM, Vir Campestris wrote:
>> On 07/03/2022 16:53, Johnny Billquist wrote:
>>> On 2022-03-06 20:17, Paul Rubin wrote:
>>>> Johnny Billquist <bqt@softjar.se> writes:
>>>>> The KL10 was about 1.5 MIPS, while the original VAX-11/780 was 1 MIPS.
>>>> 
>>>> Ah ok, for some reason I had thought the KL10 was faster than that.
>>>> EIther way: "36 bits -- a full DEC"  ;-)
>>> 
>>> You are not alone. Lots of people seem to think the KL10 was way 
>>> faster than it was.
>>> 
>>> Anyway, I still appreciate the 36-bit quote. But deep down inside, I'm 
>>> a PDP-11 person. :-D
>>> 
>> 
>> TOPS-10 was where I first met assembler.
>> 
>> I thought the KL10 was _slower_ than that.
>> 
>> And how come I can still remember the instruction word format 
>> (9-4-1-4-18) 40 years later?
>> 
>> Andy
>> 
> 
> "The Dinner Cafe's food stays hot!!!  You can feel the food burning in 
> your stomach hours later..."   ;-)
> 
> And how many advertising jingles can you sing... from television 
> commercials that were shown 40 years ago???  I can sing quite a few... 
> Perhaps I can make money with this... people might pay me *not* to 
> sing!!! ;-)
> 

Do you have a GoFundMe page?

> "A gentleman is a man who can play the bagpipes... and doesn't."
> 
> 



-- 
Pete

[toc] | [prev] | [next] | [standalone]

#220257

On 2022-03-06, Johnny Billquist <bqt@softjar.se> wrote:

> I think I heard such stories, but I never put any value to them. Another 
> story/problem is that the original MIPS definition was also based on a 
> specific version of OS and compiler. And as these evolved, the 
> VAX-11/780 actually became significantly faster than 1 MIPS. Which 
> exposed a problem with the whole MIPS definition. And also meant keeping 
> any VAXen around for reference was pretty pointless.

Hence that definition of MIPS:

Meaningless Indicator of Processor Speed

-- 
/~\  Charlie Gibbs                  |  Microsoft is a dictatorship.
\ /  <cgibbs@kltpzyxm.invalid>      |  Apple is a cult.
 X   I'm really at ac.dekanfrus     |  Linux is anarchy.
/ \  if you read it the right way.  |  Pick your poison.

[toc] | [prev] | [next] | [standalone]

#223300

On Friday, March 4, 2022 at 12:06:39 PM UTC-7, Peter Flass wrote:

> It would have to be hard to tell, since the VAX hardware was a lot faster 
> than the PDP-10. I enjoyed working with both systems. 

I briefly used OpenVMS, and I noted one feature that it had because
VAX hardware was modern and fast... and thus it had very large disk
files.

You could put square brackets after a file name, and get previous
versions of the file. I'm pretty sure they wouldn't have offered _that_
facility with TOPS-10 or TOPS-20.

Otherwise - the operating system was a way to ask for the
program you wanted to run by name. As long as it wasn't as
incomprehensible as IBM's JCL for OS/360, for the most part,
they're all good... but _one_ notable feature of the PDP-10
environment is the text editor TECO, which was the inspiration
for EMACS.

John Savard

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | alt.folklore.computers

csiph-web