Andreas Eder <a_eder_muc@web.de> wrote:
> On Mo 07 Mär 2022 at 11:47, Peter Flass <peter_flass@yahoo.com> wrote:
>
>> Scott Lurndal <scott@slp53.sl.home> wrote:
>> I’m always amazed when I try to use some piece of software I used to use
>> years ago how primitive it seems now. Back then non-ISPF TSO or DOS EDLIN
>> seemed like usable, if not much fun, pieces of software. Playing with old
>> systems like TSS or Multics it seems like my biggest problem is lack of a
>> decent editor.
>
> Well, on Multics you have Emacs!
> That should be enough for everyone :-)

I’ve managed to get fifty years in without having to learn emacs. I don’t
want to have to start now.

--
Pete

Peter Flass <peter_flass@yahoo.com> writes:
>Scott Lurndal <scott@slp53.sl.home> wrote:
>> Rich Alderson <news@alderson.users.panix.com> writes:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> Rich Alderson <news@alderson.users.panix.com> writes:
>>>>> Johnny Billquist <bqt@softjar.se> writes:
>>>
>>>>> I do not know VMS (or RSTS/E or RSX) internals. Is DCL a separate program,
>>>>> like the TOPS-20 EXEC? Or an interaction with the monitor/kernel?
>>>
>>>> VMS is an odd beast in that respect. The VAX had a four privilege
>>>> rings (aside: interestingly enough, the relatively recent ARMv8
>>>> architecture also has four privilege rings (with a fifth coming soon)).
>>>
>>>> The kernel ran in the most privileged ring, Kernel Mode. RMS (mainly
>>>> derived from RSX-11, IIRC, and authored by Andy Goldstein (IIRC again))
>>>> ran in the next most privileged ring (Executive Mode). The Command
>>>> Interpreter (DCL) ran in the next ring (Supervisor Mode), and user
>>>> applications ran in the least privileged ring (User Mode).
>>>
>>> Interestingly, the *2nd generation* PDP-10, the KI-10 processor, implemented a
>>> 4-level privilege model: Kernel, Executive, Public, and User. Tops-10 ran
>>> mostly in Executive mode, with only some of the most sensitive routines done in
>>> Kernel mode. Public mode was a user-level mode (i.e., no privileged
>>> instructions such as I/O operations) which allowed for system services similar
>>> to dynamic libraries in modern Unix-style operating systems, but serving a
>>> different purpose. User mode was the bog standard mode for any program not
>>> requiring elevated privileges.
>>>
>>> (Public mode was used by the system services such as spoolers so that user
>>> programs did not need to use system calls to interact with unit record
>>> equipment.)
>>>
>>>> As with most[*] ring-based privilege architectures, ring switches were
>>>> expensive and I believe once they went to Alpha, that architecture was
>>>> pretty much dead.
>>>
>>> The KI model was not ring-based in the way that I understand rings (based on
>>> early Multics writings, mostly); it was simply a matter of a couple of bits in
>>> the process status.
>>
>> It's changing between rings that is the primary issue as that often
>> includes a change in the memory context (e.g. x86 segment, active page
>> table) resulting in a performance hit. E.g. UUO's/system calls.
>>
>
>Some systems (Sigma) had different register sets for different processor
>modes. Memory is cheap these days, why not different caches?

Indeed, it's difficult to compare systems designed 40 to 50 years ago
with modern processors.

But even today, nobody uses more than two of the four rings on Intel
processors. (well, technically, one can consider VM-X/SVM a ring,
and SMM mode can also be considered a ring, and in both cases,
crossing the ring boundary isn't cheap - see VMEXIT).

On 2022-03-08 05:13, Fred Smith wrote:
> On 2022-03-08, D.J <chucktheouch@gmail.com> wrote:
>> On Mon, 07 Mar 2022 17:03:45 GMT, scott@slp53.sl.home (Scott Lurndal)
>> wrote:
>>> D.J. <chucktheouch@gmail.com> writes:
>>>> I didn't have access to the 11/780. The campus I was on had the
>>>> 11/730. What differences for it ?
>>>
>> >From the perspective of the average user, there was no difference
>>> between the 11/730, 11/750 or 11/780 other than absolute performance.
>>
>> I know the 730 I used was slower than the 780 on main campus. I think
>> it used fewer vt102 terminals as well.

Like Chuck said. Performance.

>> One of the professors tried to run ADA on the 730. Incredibly slow.
>> --
>> Jim
>
> The only advantage with the 730 I used was it had the REAL*16 (128 bit IEEE floating point) built in, the 750 & 780 machines required upgrades. So the 730 was actually faster for operations using real*16 operations.

VAX don't do IEEE floating point. But yes, H_FLOAT in hardware was an
addon on those machines. Otherwise it had to be done in software, which
was indeed slower.

> It was also faster because nobody wanted to use it.

Only if the larger machines were in use, of course. :-)
But yeah. Being along on a machine usually helped.

Johnny

Scott Lurndal <scott@slp53.sl.home> wrote:
> Peter Flass <peter_flass@yahoo.com> writes:
>> Scott Lurndal <scott@slp53.sl.home> wrote:
>>> Rich Alderson <news@alderson.users.panix.com> writes:
>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>
>>>>> Rich Alderson <news@alderson.users.panix.com> writes:
>>>>>> Johnny Billquist <bqt@softjar.se> writes:
>>>>
>>>>>> I do not know VMS (or RSTS/E or RSX) internals. Is DCL a separate program,
>>>>>> like the TOPS-20 EXEC? Or an interaction with the monitor/kernel?
>>>>
>>>>> VMS is an odd beast in that respect. The VAX had a four privilege
>>>>> rings (aside: interestingly enough, the relatively recent ARMv8
>>>>> architecture also has four privilege rings (with a fifth coming soon)).
>>>>
>>>>> The kernel ran in the most privileged ring, Kernel Mode. RMS (mainly
>>>>> derived from RSX-11, IIRC, and authored by Andy Goldstein (IIRC again))
>>>>> ran in the next most privileged ring (Executive Mode). The Command
>>>>> Interpreter (DCL) ran in the next ring (Supervisor Mode), and user
>>>>> applications ran in the least privileged ring (User Mode).
>>>>
>>>> Interestingly, the *2nd generation* PDP-10, the KI-10 processor, implemented a
>>>> 4-level privilege model: Kernel, Executive, Public, and User. Tops-10 ran
>>>> mostly in Executive mode, with only some of the most sensitive routines done in
>>>> Kernel mode. Public mode was a user-level mode (i.e., no privileged
>>>> instructions such as I/O operations) which allowed for system services similar
>>>> to dynamic libraries in modern Unix-style operating systems, but serving a
>>>> different purpose. User mode was the bog standard mode for any program not
>>>> requiring elevated privileges.
>>>>
>>>> (Public mode was used by the system services such as spoolers so that user
>>>> programs did not need to use system calls to interact with unit record
>>>> equipment.)
>>>>
>>>>> As with most[*] ring-based privilege architectures, ring switches were
>>>>> expensive and I believe once they went to Alpha, that architecture was
>>>>> pretty much dead.
>>>>
>>>> The KI model was not ring-based in the way that I understand rings (based on
>>>> early Multics writings, mostly); it was simply a matter of a couple of bits in
>>>> the process status.
>>>
>>> It's changing between rings that is the primary issue as that often
>>> includes a change in the memory context (e.g. x86 segment, active page
>>> table) resulting in a performance hit. E.g. UUO's/system calls.
>>>
>>
>> Some systems (Sigma) had different register sets for different processor
>> modes. Memory is cheap these days, why not different caches?
>
> Indeed, it's difficult to compare systems designed 40 to 50 years ago
> with modern processors.
>
> But even today, nobody uses more than two of the four rings on Intel
> processors. (well, technically, one can consider VM-X/SVM a ring,
> and SMM mode can also be considered a ring, and in both cases,
> crossing the ring boundary isn't cheap - see VMEXIT).
>

OS/2 uses three (and no, it’s not completely dead yet)

--
Pete

On 2022-03-08, Peter Flass <peter_flass@yahoo.com> wrote:

> Andreas Eder <a_eder_muc@web.de> wrote:
>
>> On Mo 07 Mär 2022 at 11:47, Peter Flass <peter_flass@yahoo.com> wrote:
>>
>>> I’m always amazed when I try to use some piece of software I used to use
>>> years ago how primitive it seems now. Back then non-ISPF TSO or DOS EDLIN
>>> seemed like usable, if not much fun, pieces of software. Playing with old
>>> systems like TSS or Multics it seems like my biggest problem is lack of a
>>> decent editor.
>>
>> Well, on Multics you have Emacs!
>> That should be enough for everyone :-)
>
> I’ve managed to get fifty years in without having to learn emacs.
> I don’t want to have to start now.

I took a look at emacs a couple of years ago.
I found its mindset to be too foreign for me,
e.g. in things like tab handling.

My fingers speak vi. That's usually enough.

--
/~\ 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.

On 08/03/2022 14:49, Peter Flass wrote:
> Some systems (Sigma) had different register sets for different processor
> modes. Memory is cheap these days, why not different caches?

Because you'll get more bang for your buck by having one big cache
instead of two small ones.

Cache still isn't cheap.

Andy

Vir Campestris <vir.campestris@invalid.invalid> writes:
>On 08/03/2022 14:49, Peter Flass wrote:
>> Some systems (Sigma) had different register sets for different processor
>> modes. Memory is cheap these days, why not different caches?
>
>Because you'll get more bang for your buck by having one big cache
>instead of two small ones.
>
>Cache still isn't cheap.

Indeed. However, many high-end server processors[*] implement some form of
programmable cache partitioning where portions of the cache (at any or
all levels of hierarchy) can be reserved for certain applications (or rings), and
then there are PCI Express steering tags, which allow inbound DMA to
be directed to one or more of the cache levels without going through
memory first.

[*] e.g. ARMv8 processors like the Neoverse N2 with MPAM.

On Tue, 08 Mar 2022 19:47:05 +0000, Charlie Gibbs wrote:

> I took a look at emacs a couple of years ago.
> I found its mindset to be too foreign for me,
> e.g. in things like tab handling.
>
> My fingers speak vi. That's usually enough.

I have exactly the opposite. I started UNIX in 1975, although vi took a
while to appear. I continued to use 'ed' because my terminal was a bit
basic.

Then I got a PC with a simplified emacs that was marketed as part of a
'word processor'. My fingers know that (but I also use 'ed' in extremis,
usually in single user mode on a basic console).

--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org

On 3/6/2022 12:34 PM, Peter Flass wrote:
> Johnny Billquist <bqt@softjar.se> wrote:
>> On 2022-03-04 22:23, Paul Rubin wrote:
>>> Peter Flass <peter_flass@yahoo.com> writes:
>>>> 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.
>>>
>>> For the first N years, VAXes were much slower than the faster 10's.
>>
>> Not really. The KL10 was about 1.5 MIPS, while the original VAX-11/780
>> was 1 MIPS.
>>
>> Speed parity was basically achieved with the VAX-11/785. After that, the
>> VAXen just were becoming faster.
>>
>> The PDP-10 was never a speed daemon. It was helped a lot by being
>> offloaded for terminal I/O by the front end processor. But with the
>> spreading of ethernet, all of that work started moving back to the
>> PDP-10 itself, at which point you really felt the pain. 40 users on a
>> -2060 was usually not all that much fun, I can tell you. Heck, even 20
>> was painful.
>>
>>> Faster VAXes appeared later, and eventually overtook the 10 mostly due
>>> to improved chip technology. The main VAX for a long time was the
>>> original 11/780 (introduced 1977) which was the canonical 1 MIP machine.
>>> A KL-10 (introduced 1975) was maybe 3x that, about equivalent(?) to the
>>> VAX 8600 that that came out in 1984.
>>
>> KL-10 was about 1.5x. The 8600, introduced in 1984 was 4x the 11/780,
>> and was noticeably faster than the KL-10.
>>
>>> I don't know about today, but legend has it that a few 11/780's were
>>> kept operational for decades after that model's obsolescence, to serve
>>> as benchmark hosts for MIPs rating of newer cpus.
>>
>> 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.
>>
>> And that's a big reason DEC themselves never used MIPS. They instead
>> talked about VUPs. Where a VAX-11/780 was by definition 1 VUP. And it
>> was more properly based on the actual processing speed, and not
>> depending on various software.
>>
>> Johnny
>>
>
> 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.
>
MIPS in Outer Space

The processor used in the original Sony PlayStation is currently guiding
a space probe the size of a grand piano towards Pluto? Yep, the same
MIPS R3000 CPU that once ran Final Fantasy VII and Metal Gear Solid was
repurposed by NASA in 2006 to fire thrusters, monitor sensors, and
transmit data from the New Horizons space probe.

https://www.theverge.com/2015/1/15/7551365/playstation-cpu-powers-new-horizons-pluto-probe

--

Charles Richmond

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

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

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

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. I had worked with Jim Gray at IBM Research on System/R
(original SQl/Relational implementation) and he then palmed off some
stuff on me when he left for Tandem ... where he pioneers DBMS TPC
benchmarks
http://www.tpc.org/information/who/gray5.asp

Periodically some mainframe numbers manage to leak. Industry standard
MIPS benchmark wasn't instructions/sec but number of program iterations
compared to the standard's processor ... assumed to be one MIP machine
(and easier to find for IBM's non-mainframe systems).

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

Max configured z196 was $30M ($600,000/BIPS) and in that timeframe,
cloud megadatacenters (with half million or more systems) standard was
E5-2600 blades benchmarked at 500BIPS. This was shortly before IBM sold
off its blade server business ... but IBM had E5-2600 base list price of
$1815 ($3.60/BIPS). However, cloud megadatacenters had been saying for
at least a decade that they assembled their own systems for 1/3rd the
cost of brand name blade servers ($1.20/BIPS) ... likely contributing to
IBM selling off its blade server business ... this was also about the
time that server chip maker press said that they were shipping half
their product directly to cloud megadatacenters.

z196 pubs also claimed that over half the per processor performance
improvement from z10 to z196 was the introduction of cache miss (memory
latency) compensation features (that had been in other platforms in some
cases for decades) ... out-of-order execution, branch prediction,
speculative execution, etc.

Big cloud operators (with dozen or more megadatacenters around the
world, each with half million or more systems) had so drastically
reduced their system costs that power & cooling were becoming
increasingly large part of their costs ... and they were putting
pressure on Intel/AMD to significantly increase computational power
efficiency (and looking at moving to ARM, originally designed for low
power, battery use, computational power efficiency offsetting increasing
the number of systems). They had so decreased cost of systems that they
could justify complete upgrade of all systems when there was improvement
computational power efficiency. Also start seeing TPC including
computational efficiency in benchmarks, being able to calculate
electrical power cost per transaction ... and IBM still participates for
their non-mainframe systems.
https://www.tpc.org/tpcc/results/tpcc_results5.asp?orderby=hardware

trivia: 50+ yrs ago, IBM 195 mainframe had out-of-order execution but
conditional branches drained the pipeline ... so most 360&370 codes ran
at half the 195 throughput. Shortly after joining IBM, the 195 group
tried to suck me into helping with hyperthreading the 195 ... simulating
two processor with two threads, each running at half machine throughput.
In this description of the shutdown of ACS/360 (executives were afraid
it would advance the state of art too fast and IBM would loose control
of the market) ... there is reference to multithreading patents
https://people.cs.clemson.edu/~mark/acs_end.html

new work for 195 (including multithread) was canceled when it was
decided to add "virtual memory" to all 370s ... and it wasn't believed
that adding virtual memory to 195 was practical. Also claims that at the
time, MVT/MVS two-processor SMP systems were claimed to only have
1.2-1.5 system throughput of single processor (because of their
multiprocessor system software overhead) ... which would have more than
offset any benefit of having a multithreaded (simulated two processor)
195.

other trivia: in the morph from cp67->vm370, they simplified and/or
dropped (including dropping cp67 multiprocessor support). after joining
IBM, one of my hobbies was enhanced production operating systems for
internal datacenters ... including world-wide, sales&market support
"HONE" systems. The US HONE systems had been consolidated in Palo Alto
in the mid-70s (when facebook 1st moves into silicon valley, it was into
a new bldg built next door to the former US HONE datacenter). Their
VM370 was enhanced to have eight loosely-coupled (cluster, shared DASD)
single-system image, aka cluster with load balancing and fall-over
across the complex. I had added lots of CP67 features/function back into
VM370 and then (initially for HONE) added tightly-coupled (shared
memory) multiprocessor into VM370 release 3 ... giving them 16 processor
complex (at the time I considered largest IBM mainframe single-system
image complex; some ACP/TPF complexes may have had eight loosely-coupled
system complex but ACP/TPF didn't have tightly-coupled support so was
limited to one processor/system), With very short multiprocessor
pathlengths and some games with "cache affinity" ... could get two
processor machine with twice the throughput of single processor machine
(improved cache hit rate offsetting the multiprocessor software
overhead).

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

On Fri, 23 Dec 2022 10:34:13 -1000
Anne & Lynn Wheeler <lynn@garlic.com> wrote:

> Big cloud operators (with dozen or more megadatacenters around the
> world, each with half million or more systems) had so drastically
> reduced their system costs that power & cooling

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.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

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

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.

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

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

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

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

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.

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.

On Sat, 24 Dec 2022 11:17:54 -0600, D.J. <chucktheouch@gmnol.com>
wrote:
>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.

Heat exchanger.
--
Jim

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

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

D.J. <chucktheouch@gmnol.com> wrote:
> On Sat, 24 Dec 2022 11:17:54 -0600, D.J. <chucktheouch@gmnol.com>
> wrote:
>> 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.
>
> Heat exchanger.
> --
> Jim
>

Head Exchanger is what you need after using windoze.

--
Pete