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

What is the oldest computer that could be used today for real work?

Started by	Jason Evans <jsevans@mailfence.com>
First post	2021-09-05 09:55 +0000
Last post	2021-10-08 07:27 -0700
Articles	20 on this page of 224 — 41 participants

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

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

#218774

From	Thomas Koenig <tkoenig@netcologne.de>
Date	2021-09-09 13:08 +0000
Message-ID	<shd10j$4ns$1@newsreader4.netcologne.de>
In reply to	#218761

J  Clarke <jclarke.873638@gmail.com> schrieb:
> On Tue, 7 Sep 2021 13:06:16 -0000 (UTC), John Goerzen
><jgoerzen@complete.org> wrote:
>
>>On 2021-09-07, J  Clarke <jclarke.873638@gmail.com> wrote:
>>>>https://governor.kansas.gov/wp-content/uploads/2021/04/GintherTaxCouncilKDOT.pdf
>>>>hints that it may be an IBM System 370/Model 145.
>>>
>>> I'd be very surprised if it actually was.  When did IBM end
>>> maintenance on those?
>>
>>I have no more information, other than that link claims "The Kansas UI System
>>runs on a Mainframe that was installed in 1977."
>>
>>Is it possible the hardware was upgraded to something that can emulate the
>>370/145, and that difference was lost on a non-technical author?  Sure.
>
> A brand new Z can emulate the 370/145.  So can my Raspberry Pi if I
> don't expect any performance.

Surely, a higher performance than the original?  Bitsavers claims that

"The Model 145 has a variable-length CPU cycle time. Cycle times of
202.5, 247.5, 292.5, and 315 nanoseconds are implemented. The time
required for the CPU to perform operations is made up of combinations of
these cycles. The CPU fetches instructions from processor storage a
doubleword at a time, while data accesses, both fetches and stores, are
made on a word basis. Eight instruction bytes or four data bytes can be
fetched by the CPU in 540 nanoseconds."

Variable-length CPU cycle time sounds strange, but the clock ran at
somewhere between 3.2 and 5 MZh.  Not sure what sort of Pi you
have, but even a 700 MHz ARMv6 should be able to run rings around
that old machine in emulation with a factor of more than 100 in
CPU cycle time.

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

#218782

From	John Levine <johnl@taugh.com>
Date	2021-09-10 01:35 +0000
Message-ID	<shecp6$11c6$1@gal.iecc.com>
In reply to	#218774

According to Thomas Koenig  <tkoenig@netcologne.de>:
>> A brand new Z can emulate the 370/145.  So can my Raspberry Pi if I
>> don't expect any performance.
>
>Surely, a higher performance than the original? ...

CPU speed, sure, but the point of a mainframe is that it has high performance
peripherals.  A /145 could have up to four channels and could attach several
dozen disk drives.

These days one SSD holds more data than two dozen 2314 disks, but I wouldn't
think a Pi has particularly high I/O bandwidth.

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

#218784

From	J. Clarke <jclarke.873638@gmail.com>
Date	2021-09-09 23:52 -0400
Message-ID	<56lljgpiq93ukr9q60fnmhsot2kl0hop35@4ax.com>
In reply to	#218782

On Fri, 10 Sep 2021 01:35:34 -0000 (UTC), John Levine
<johnl@taugh.com> wrote:

>According to Thomas Koenig  <tkoenig@netcologne.de>:
>>> A brand new Z can emulate the 370/145.  So can my Raspberry Pi if I
>>> don't expect any performance.
>>
>>Surely, a higher performance than the original? ...

No.  The pi is painfully slow running the emulator.

>CPU speed, sure, but the point of a mainframe is that it has high performance
>peripherals.  A /145 could have up to four channels and could attach several
>dozen disk drives.
>
>These days one SSD holds more data than two dozen 2314 disks, but I wouldn't
>think a Pi has particularly high I/O bandwidth.

It's I/O is a USB port, Gigabit, and wifi.  It can also implement I/O
with a USART but that's very limited bandwidth.

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

#218790

From	Thomas Koenig <tkoenig@netcologne.de>
Date	2021-09-10 15:57 +0000
Message-ID	<shfv9j$4mj$2@newsreader4.netcologne.de>
In reply to	#218784

J  Clarke <jclarke.873638@gmail.com> schrieb:
> On Fri, 10 Sep 2021 01:35:34 -0000 (UTC), John Levine
><johnl@taugh.com> wrote:
>
>>According to Thomas Koenig  <tkoenig@netcologne.de>:
>>>> A brand new Z can emulate the 370/145.  So can my Raspberry Pi if I
>>>> don't expect any performance.
>>>
>>>Surely, a higher performance than the original? ...
>
> No.  The pi is painfully slow running the emulator.

Slower than the original?  How many cycles per S/360 instruction does
it take?  If it was really slower than the original, it would have
to be more than 100 cycles per instruction.  I find that hard to
believe.

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

#218793

From	Anne & Lynn Wheeler <lynn@garlic.com>
Date	2021-09-10 06:49 -1000
Message-ID	<87tuis1ikq.fsf@localhost>
In reply to	#218790

Thomas Koenig <tkoenig@netcologne.de> writes:
> Slower than the original?  How many cycles per S/360 instruction does
> it take?  If it was really slower than the original, it would have
> to be more than 100 cycles per instruction.  I find that hard to
> believe.

Endicott cons me into helping do ECPS for 138/148. I was told that
low/mid 370, 115-148 avg ten native instructions per 370 emulated instructions
(i.e. 80kips 370/115 had 800kips engine, 120kips 370/125 had 1.2mips
engine, etc) and the 138/148 had 6kbytes of available microcode storage.
I was to identity the 6k bytes highest executed kernel instructions
for moving to microcode (on roughtly byte-for-byte basis). old
archived post with the analysis
http://www.garlic.com/~lynn/94.html#21

6kbytes of kernel instructions pathlength accounted for 79.55% of kernel
execution time ... dropped directly into microcode would run 10times
faster. Also implemented for later 4331/4341.

In the early 80s I got permission to give howto ECPS presentations at
local user group (silicon valley) monthly baybunch meetings and would
get lots of questions from the Amdahl people.

They would say that IBM had started doing lots of trivial microcode
implementations for the 3033 which would be required for MVS to
run. Amdahl eventually responded with "macrocode" ... effectively
370-like instruction set that ran in microcode mode ... where Amdahl
could implement the 3033 microcodes changes much easier with much less
effort.

Note the low/mid range 370s had vertical instruction microcode
processors (i.e.  programming like cics/risc processors). high-end 370
had horizontal microcode and typically expressed in the avg.  number of
machine cycles per 370 instruction. The 370/165 ran 2.1 machine cycles
per 370 instruction. That was optimized for 370/168 to 1.6 machine
cycles per 370 instruction. The 3033 started out as 168-3 logic remapped
to 20% faster chips and the microcode was further optimized to one
machine cycle per 370 instruction. It was claimed that all those 3033
microcode tweaks ran same speed as 370 (and some cases slower).

Amdahl was then using macrocode to implement hypervisor support ...
subset of virtual machines support w/o needing vm370 ... which took IBM
several years to respond with PR/SM and LPAR in native horizontal
microcode (well after 3081 and well into 3090 product life).

some years later after retiring from IBM ... I was doing some stuff with
http://www.funsoft.com/

and their experience with emulating 370, avg. ten instructions per 370
was about the same as low&mid range 370s ... although they had some
other tweaks that could dynamically translate high-use instruction paths
directly into native code on-the-fly (getting 10:1 improvement).

I believe hercules is somewhat similar
https://en.wikipedia.org/wiki/Hercules_(emulator)

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

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

#218794

From	Andreas Kohlbach <ank@spamfence.net>
Date	2021-09-10 12:51 -0400
Message-ID	<87y284idbn.fsf@usenet.ankman.de>
In reply to	#218790

On Fri, 10 Sep 2021 15:57:39 -0000 (UTC), Thomas Koenig wrote:
>
> J  Clarke <jclarke.873638@gmail.com> schrieb:
>> On Fri, 10 Sep 2021 01:35:34 -0000 (UTC), John Levine
>><johnl@taugh.com> wrote:
>>
>>>According to Thomas Koenig  <tkoenig@netcologne.de>:
>>>>> A brand new Z can emulate the 370/145.  So can my Raspberry Pi if I
>>>>> don't expect any performance.
>>>>
>>>>Surely, a higher performance than the original? ...
>>
>> No.  The pi is painfully slow running the emulator.
>
> Slower than the original?  How many cycles per S/360 instruction does
> it take?  If it was really slower than the original, it would have
> to be more than 100 cycles per instruction.  I find that hard to
> believe.

Having the issue here with an (aged) AMD PC. It's since years (software
bloat over the years I assume) no longer able to emulated a Commodore 64
with full speed (around 1 MHz for the 6510 CPU), while the host is
supposed to run at 780 MHz (according to /proc/cpuinfo here in Linux), so
780 times faster. Yeas ago it was able to emulate the C64 at its max
speed, while I could run other tasks on the host at the same time.
-- 
Andreas

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

#218805

From	Thomas Koenig <tkoenig@netcologne.de>
Date	2021-09-11 07:34 +0000
Message-ID	<shhm72$9p5$2@newsreader4.netcologne.de>
In reply to	#218794

Andreas Kohlbach <ank@spamfence.net> schrieb:
> On Fri, 10 Sep 2021 15:57:39 -0000 (UTC), Thomas Koenig wrote:
>>
>> J  Clarke <jclarke.873638@gmail.com> schrieb:
>>> On Fri, 10 Sep 2021 01:35:34 -0000 (UTC), John Levine
>>><johnl@taugh.com> wrote:
>>>
>>>>According to Thomas Koenig  <tkoenig@netcologne.de>:
>>>>>> A brand new Z can emulate the 370/145.  So can my Raspberry Pi if I
>>>>>> don't expect any performance.
>>>>>
>>>>>Surely, a higher performance than the original? ...
>>>
>>> No.  The pi is painfully slow running the emulator.
>>
>> Slower than the original?  How many cycles per S/360 instruction does
>> it take?  If it was really slower than the original, it would have
>> to be more than 100 cycles per instruction.  I find that hard to
>> believe.
>
> Having the issue here with an (aged) AMD PC. It's since years (software
> bloat over the years I assume) no longer able to emulated a Commodore 64
> with full speed (around 1 MHz for the 6510 CPU), while the host is
> supposed to run at 780 MHz (according to /proc/cpuinfo here in Linux), so
> 780 times faster.

That is a bit different. An emulator for a whole C-64 including
graphics and sound has to do much more work than an emulator for a
370/145 which did computation and I/O.

> Yeas ago it was able to emulate the C64 at its max
> speed, while I could run other tasks on the host at the same time.

"Other tasks" including running a browser?

I agree that modern software, also for Linux, has become incredibly
bloated.  IIRC, the first Linux I ran at home was Slackware
0.99-something on a 486 with 4 MB running a simple window manager
and xterm.  It wasn't as nice as the HP workstations I used
at the university, but it ran well enough.

Now... not a chance of getting things going with that setup.

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

#218811

From	Andreas Kohlbach <ank@spamfence.net>
Date	2021-09-11 15:14 -0400
Message-ID	<874kaqj55b.fsf@usenet.ankman.de>
In reply to	#218805

On Sat, 11 Sep 2021 07:34:58 -0000 (UTC), Thomas Koenig wrote:
>
> Andreas Kohlbach <ank@spamfence.net> schrieb:
>>
>> Having the issue here with an (aged) AMD PC. It's since years (software
>> bloat over the years I assume) no longer able to emulated a Commodore 64
>> with full speed (around 1 MHz for the 6510 CPU), while the host is
>> supposed to run at 780 MHz (according to /proc/cpuinfo here in Linux), so
>> 780 times faster.
>
> That is a bit different. An emulator for a whole C-64 including
> graphics and sound has to do much more work than an emulator for a
> 370/145 which did computation and I/O.

Thought a complete machine is emulated in the other case too.

Sure depends on the amount of hardware the target machine has. And if a
for a specific machine dedicated emulator is used, which often simulates
parts of the hardware instead of truly emulating it, which speeds it up.

I prefer the "all-purpose" emulator MAME, which attempts to emulate all
parts of the hardware, although it is slower.

Because there are many emulators for the Raspberry PI I assume they can
emulate faster than my aging machine. Also that some retro mini-cabs run
on an ARM processor with similar specs as a PI.

>> Yeas ago it was able to emulate the C64 at its max
>> speed, while I could run other tasks on the host at the same time.
>
> "Other tasks" including running a browser?

The destop-manager (Linux here) for example. The laptop here is also
"abused" as web- and other servers running at the same time.
-- 
Andreas

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

#218785

From	Anne & Lynn Wheeler <lynn@garlic.com>
Date	2021-09-09 17:56 -1000
Message-ID	<87sfyd2ie2.fsf@localhost>
In reply to	#218782

John Levine <johnl@taugh.com> writes:
> CPU speed, sure, but the point of a mainframe is that it has high performance
> peripherals. A /145 could have up to four channels and could attach several
> dozen disk drives.
>
> These days one SSD holds more data than two dozen 2314 disks, but I wouldn't
> think a Pi has particularly high I/O bandwidth.

raspberry Pi 4 specs and benchmarks (2 yrs ago)
https://magpi.raspberrypi.org/articles/raspberry-pi-4-specs-benchmarks

SoC: Broadcom BCM2711B0 quad-core A72 (ARMv8-A) 64-bit @ 1.5GHz
GPU: Broadcom VideoCore VI
Networking: 2.4GHz and 5GHz 802.11b/g/n/ac wireless LAN
RAM: 1GB, 2GB, or 4GB LPDDR4 SDRAM
Bluetooth: Bluetooth 5.0, Bluetooth Low Energy (BLE)
GPIO: 40-pin GPIO header, populated
Storage: microSD
Ports: 2x micro-HDMI 2.0, 3.5mm analogue audio-video jack, 2x USB 2.0,
2x USB 3.0, Gigabit Ethernet, Camera Serial Interface (CSI), Display Serial Interface (DSI)
Dimensions: 88mm x 58mm x 19.5mm, 46g

linpack mips 925MIPS, 748MIPS, 2037MIPS
memory bandwidth (1MB blocks r&w) 4129/sec, 4427/sec
USB storage thruput (megabytes/sec r&w) 353mbytes/sec, 323mbytes/sec

more details
https://en.wikipedia.org/wiki/Raspberry_Pi
best picks Pi microSD cards (32gbytes)
https://www.tomshardware.com/best-picks/raspberry-pi-microsd-cards

===

by comparison, 145 would be .3MIPS and 512kbyte memory,

2314 capacity 29mbytes ... need 34 2314s/gbyte or 340 2314s for
10gbytes
https://www.ibm.com/ibm/history/exhibits/storage/storage_2314.html
2314 disk rate 312kbytes/sec ... ignoring channel program overhead, disk
access, etc, assuming that all four 145 channels would continuously be doing
disk i/o transfer at sustained 312kbytes/sec ... that is theoritical
1.2mbytes/sec

trivia: after transferring to San Jose Research (bldg28), I got roped
into playing disk engineer part time (across the street in
bldg14&15). The 3830 controller for 3330 & 3350 disk drives was replaced
with 3880 controller for 3380 disk drives. While 3880 had special
hardware data path for handling 3380 3mbyte/sec transfer ... it had a
microprocessor that was significantly slower than 3830 for everything
else ... which drastically drove up channel busy overhead ... especially
for the channel program chatter latency between processor and
controller.

The 3090 folks had configured number of channels, assuming the 3880
would be similar to 3830 but handling 3mbyte data transfer ... when they
found out how bad the 3880 channel busy really was ... they realized
they would have to drastically increase the number of channels. The
channel number increase required an extra (very expensive) TCM (there
were jokes that the 3090 office was going to charge the 3880 office for
the increase in 3090 manufacturing cost). Eventually marketing respun
big increase in number of channels (to handle the half-duplex chatter
channel busy overhead) as how great all the 3090 channels were.

Other triva: in 1980, IBM STL (lab) was bursting at the seams and they
were moving 300 people from the IMS DBMS development group to and
offsite bldg with dataprocessing back to STL datacenter. The group had
tried "remote" 3270 terminal support and found the human factors totally
unacceptable. I get con'ed into doing channel-extender support so they
can put local channel connected 3270 controllers at the offsite bldg
(with no perceived difference in human factors offsite and in STL).

The hardware vendor tries to get IBM to release my support, but there
were some people in POK playing with some serial stuff that get it
vetoed (they were worried that if it was in the market, it would harder
to justify releasing their stuff). Then in 1988, I'm asked to help LLNL
standardize some serial stuff they are laying with ... which quickly
becomes fibre channel standard (including some stuff I had done in
1980), initially 1gbit (100mbyte) full-duplex (2gbit, aka 200mbyte,
aggregate)

In 1990, the POK people get their stuff released with ES/9000 as ESCON
(when it is already obsolete, around 17mbyte aggregate). Later some of
the POK people start playing with fibre channel standard and define a
heavy weight protocol that drastically cuts the native throughput which
is finally releaseed as FICON.

The latest published benchmarks I can find is "peak I/O" for z196 that
used 104 FICON (running over 104 fibre channel) to get 2M IOPS. About
the same time there was a fibre channel announced for E5-2600 blade
claiming over million IOPS, two such fibre channel getting higher
(native) throughput than 104 FICON running over 104 fibre channel).

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

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

#218787

From	J. Clarke <jclarke.873638@gmail.com>
Date	2021-09-10 01:17 -0400
Message-ID	<ofqljgpadsumlc55cmo01f0p5eb8ic9of0@4ax.com>
In reply to	#218785

On Thu, 09 Sep 2021 17:56:21 -1000, Anne & Lynn Wheeler
<lynn@garlic.com> wrote:

>John Levine <johnl@taugh.com> writes:
>> CPU speed, sure, but the point of a mainframe is that it has high performance
>> peripherals.  A /145 could have up to four channels and could attach several
>> dozen disk drives.
>>
>> These days one SSD holds more data than two dozen 2314 disks, but I wouldn't
>> think a Pi has particularly high I/O bandwidth.
>
>raspberry Pi 4 specs and benchmarks (2 yrs ago)
>https://magpi.raspberrypi.org/articles/raspberry-pi-4-specs-benchmarks
>
>SoC: Broadcom BCM2711B0 quad-core A72 (ARMv8-A) 64-bit @ 1.5GHz
>GPU: Broadcom VideoCore VI
>Networking: 2.4GHz and 5GHz 802.11b/g/n/ac wireless LAN
>RAM: 1GB, 2GB, or 4GB LPDDR4 SDRAM
>Bluetooth: Bluetooth 5.0, Bluetooth Low Energy (BLE)
>GPIO: 40-pin GPIO header, populated
>Storage: microSD
>Ports: 2x micro-HDMI 2.0, 3.5mm analogue audio-video jack, 2x USB 2.0,
>2x USB 3.0, Gigabit Ethernet, Camera Serial Interface (CSI), Display Serial Interface (DSI)
>Dimensions: 88mm x 58mm x 19.5mm, 46g
>
>linpack mips 925MIPS, 748MIPS, 2037MIPS
>memory bandwidth (1MB blocks r&w) 4129/sec, 4427/sec
>USB storage thruput (megabytes/sec r&w) 353mbytes/sec, 323mbytes/sec
>
>more details
>https://en.wikipedia.org/wiki/Raspberry_Pi
>best picks Pi microSD cards (32gbytes)
>https://www.tomshardware.com/best-picks/raspberry-pi-microsd-cards
>
>===
>
>by comparison, 145 would be .3MIPS and 512kbyte memory,
>
>2314 capacity 29mbytes ... need 34 2314s/gbyte or 340 2314s for
>10gbytes
>https://www.ibm.com/ibm/history/exhibits/storage/storage_2314.html
>2314 disk rate 312kbytes/sec ... ignoring channel program overhead, disk
>access, etc, assuming that all four 145 channels would continuously be doing
>disk i/o transfer at sustained 312kbytes/sec ... that is theoritical
>1.2mbytes/sec
>
>trivia: after transferring to San Jose Research (bldg28), I got roped
>into playing disk engineer part time (across the street in
>bldg14&15). The 3830 controller for 3330 & 3350 disk drives was replaced
>with 3880 controller for 3380 disk drives.  While 3880 had special
>hardware data path for handling 3380 3mbyte/sec transfer ... it had a
>microprocessor that was significantly slower than 3830 for everything
>else ... which drastically drove up channel busy overhead ... especially
>for the channel program chatter latency between processor and
>controller.
>
>The 3090 folks had configured number of channels, assuming the 3880
>would be similar to 3830 but handling 3mbyte data transfer ... when they
>found out how bad the 3880 channel busy really was ... they realized
>they would have to drastically increase the number of channels. The
>channel number increase required an extra (very expensive) TCM (there
>were jokes that the 3090 office was going to charge the 3880 office for
>the increase in 3090 manufacturing cost). Eventually marketing respun
>big increase in number of channels (to handle the half-duplex chatter
>channel busy overhead) as how great all the 3090 channels were.
>
>Other triva: in 1980, IBM STL (lab) was bursting at the seams and they
>were moving 300 people from the IMS DBMS development group to and
>offsite bldg with dataprocessing back to STL datacenter. The group had
>tried "remote" 3270 terminal support and found the human factors totally
>unacceptable. I get con'ed into doing channel-extender support so they
>can put local channel connected 3270 controllers at the offsite bldg
>(with no perceived difference in human factors offsite and in STL).
>
>The hardware vendor tries to get IBM to release my support, but there
>were some people in POK playing with some serial stuff that get it
>vetoed (they were worried that if it was in the market, it would harder
>to justify releasing their stuff). Then in 1988, I'm asked to help LLNL
>standardize some serial stuff they are laying with ... which quickly
>becomes fibre channel standard (including some stuff I had done in
>1980), initially 1gbit (100mbyte) full-duplex (2gbit, aka 200mbyte,
>aggregate)
>
>In 1990, the POK people get their stuff released with ES/9000 as ESCON
>(when it is already obsolete, around 17mbyte aggregate). Later some of
>the POK people start playing with fibre channel standard and define a
>heavy weight protocol that drastically cuts the native throughput which
>is finally releaseed as FICON.
>
>The latest published benchmarks I can find is "peak I/O" for z196 that
>used 104 FICON (running over 104 fibre channel) to get 2M IOPS. About
>the same time there was a fibre channel announced for E5-2600 blade
>claiming over million IOPS, two such fibre channel getting higher
>(native) throughput than 104 FICON running over 104 fibre channel).

I supposed I could compile Linpack under Z/OS on the pi and see what
it actually does.  I'm not that ambitious though.  Native on the pi
doesn't count.

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

#218789

From	Thomas Koenig <tkoenig@netcologne.de>
Date	2021-09-10 15:54 +0000
Message-ID	<shfv32$4mj$1@newsreader4.netcologne.de>
In reply to	#218782

John Levine <johnl@taugh.com> schrieb:
> According to Thomas Koenig  <tkoenig@netcologne.de>:
>>> A brand new Z can emulate the 370/145.  So can my Raspberry Pi if I
>>> don't expect any performance.
>>
>>Surely, a higher performance than the original? ...
>
> CPU speed, sure, but the point of a mainframe is that it has high performance
> peripherals.  A /145 could have up to four channels and could attach several
> dozen disk drives.

The "Functional characteristics" document from 1972 from Bitsavers 
gives a  maximum rate per channel of 1.85 MB per second with a
word buffer installed, plus somewhat lower figures for four channels
for a total of 5.29 MB/s (which would be optimum).

> These days one SSD holds more data than two dozen 2314 disks, but I wouldn't
> think a Pi has particularly high I/O bandwidth.

A single USB2 port can do around 53 MB/s theoretical maximum, a factor
of approximately 10 vs. the 370/145.  I didn't look up the speed
of the Pi's SSD.

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

#218795

From	scott@slp53.sl.home (Scott Lurndal)
Date	2021-09-10 20:45 +0000
Message-ID	<UtP_I.20522$rsCb.2681@fx01.iad>
In reply to	#218789

Thomas Koenig <tkoenig@netcologne.de> writes:
>John Levine <johnl@taugh.com> schrieb:
>> According to Thomas Koenig  <tkoenig@netcologne.de>:
>>>> A brand new Z can emulate the 370/145.  So can my Raspberry Pi if I
>>>> don't expect any performance.
>>>
>>>Surely, a higher performance than the original? ...
>>
>> CPU speed, sure, but the point of a mainframe is that it has high performance
>> peripherals.  A /145 could have up to four channels and could attach several
>> dozen disk drives.
>
>The "Functional characteristics" document from 1972 from Bitsavers 
>gives a  maximum rate per channel of 1.85 MB per second with a
>word buffer installed, plus somewhat lower figures for four channels
>for a total of 5.29 MB/s (which would be optimum).

But it is unlikely that a single drive was dense enough to drive
anywhere near that rate.   Regardless of the channel speed, the
drive is limited by how fast it can get the data off the platter.

Burroughs disk channels had similar transfer rates and supported
multiple independently seeking drives on a single channel (up
to 16) to use the available bandwidth.   The I/O controller on
the B4900 was rated at 8MB/sec across 32 channels.

USB3.0 on a raspberry pi crushes that by orders of magnitude.

>
>> These days one SSD holds more data than two dozen 2314 disks, but I wouldn't
>> think a Pi has particularly high I/O bandwidth.
>
>A single USB2 port can do around 53 MB/s theoretical maximum, a factor
>of approximately 10 vs. the 370/145.  I didn't look up the speed
>of the Pi's SSD.

The fastest NVME SSDs can read three GByte/second and write one Gbyte/second.

The fastest USB SSDs are limited to 600MByte/sec, but few can reach that speed.

As NVME simply requires a PCI express port, which is available on many raspberry
pi boards, the max I/O speed for a pi is the speed of a single PCI Express Gen 3
(1GByte/s) or Gen 4 (2Gbytes/s) lane depending on the pi.  Might even see
Gen 5 in the next couple of years (4Gbytes/sec) in future Pi processors.

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

#218797

From	John Levine <johnl@taugh.com>
Date	2021-09-10 22:03 +0000
Message-ID	<shgko4$17d0$1@gal.iecc.com>
In reply to	#218795

According to Scott Lurndal <slp53@pacbell.net>:
>>The "Functional characteristics" document from 1972 from Bitsavers 
>>gives a  maximum rate per channel of 1.85 MB per second with a
>>word buffer installed, plus somewhat lower figures for four channels
>>for a total of 5.29 MB/s (which would be optimum).
>
>But it is unlikely that a single drive was dense enough to drive
>anywhere near that rate.   Regardless of the channel speed, the
>drive is limited by how fast it can get the data off the platter.

That's why there were four channels.  Each channel can have a
disk transfer going.  An IBM web page said a 2314 could transfer
312L bytes per second so the fastest burst speed would be four
times that, say 1.2M bytes/sec.

I'd think later on people would be more likely to use 3330 or 3340
disks, which were 800K bytes/sec so say total data rate of 3.2MB/sec.

>USB3.0 on a raspberry pi crushes that by orders of magnitude.

Yeah, I would think so.  No seek time on your SSD either.

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

#218804

From	maus <maus@dmaus.org>
Date	2021-09-11 06:42 +0000
Message-ID	<slrnsjojto.49f.maus@dmaus.org>
In reply to	#218795

On 2021-09-10, Scott Lurndal <scott@slp53.sl.home> wrote:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>>John Levine <johnl@taugh.com> schrieb:
>>> According to Thomas Koenig  <tkoenig@netcologne.de>:
>>>>> A brand new Z can emulate the 370/145.  So can my Raspberry Pi if I
>>>>> don't expect any performance.
>>>>
>>>>Surely, a higher performance than the original? ...
>>>
>>> CPU speed, sure, but the point of a mainframe is that it has high performance
>>> peripherals.  A /145 could have up to four channels and could attach several
>>> dozen disk drives.
>>
>>The "Functional characteristics" document from 1972 from Bitsavers 
>>gives a  maximum rate per channel of 1.85 MB per second with a
>>word buffer installed, plus somewhat lower figures for four channels
>>for a total of 5.29 MB/s (which would be optimum).
>
> But it is unlikely that a single drive was dense enough to drive
> anywhere near that rate.   Regardless of the channel speed, the
> drive is limited by how fast it can get the data off the platter.
>
>
> The fastest NVME SSDs can read three GByte/second and write one Gbyte/second.
>
> The fastest USB SSDs are limited to 600MByte/sec, but few can reach that speed.
>
> As NVME simply requires a PCI express port, which is available on many raspberry
> pi boards, the max I/O speed for a pi is the speed of a single PCI Express Gen 3
> (1GByte/s) or Gen 4 (2Gbytes/s) lane depending on the pi.  Might even see
> Gen 5 in the next couple of years (4Gbytes/sec) in future Pi processors.


I have several Pi's, and only in the last have I found what I think is
a grievious error, installed heat sinks, turned it on. After a few
minutes I noticed a searing pain where my hand was leaning on  one of
the heat sinks.

greymausg@mail.com

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

#218808

From	J. Clarke <jclarke.873638@gmail.com>
Date	2021-09-11 08:55 -0400
Message-ID	<ie8pjgd13s00ddm304ii7ctmotbe2d40fo@4ax.com>
In reply to	#218804

On 11 Sep 2021 06:42:00 GMT, maus <maus@dmaus.org> wrote:

>On 2021-09-10, Scott Lurndal <scott@slp53.sl.home> wrote:
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>John Levine <johnl@taugh.com> schrieb:
>>>> According to Thomas Koenig  <tkoenig@netcologne.de>:
>>>>>> A brand new Z can emulate the 370/145.  So can my Raspberry Pi if I
>>>>>> don't expect any performance.
>>>>>
>>>>>Surely, a higher performance than the original? ...
>>>>
>>>> CPU speed, sure, but the point of a mainframe is that it has high performance
>>>> peripherals.  A /145 could have up to four channels and could attach several
>>>> dozen disk drives.
>>>
>>>The "Functional characteristics" document from 1972 from Bitsavers 
>>>gives a  maximum rate per channel of 1.85 MB per second with a
>>>word buffer installed, plus somewhat lower figures for four channels
>>>for a total of 5.29 MB/s (which would be optimum).
>>
>> But it is unlikely that a single drive was dense enough to drive
>> anywhere near that rate.   Regardless of the channel speed, the
>> drive is limited by how fast it can get the data off the platter.
>>
>>
>> The fastest NVME SSDs can read three GByte/second and write one Gbyte/second.
>>
>> The fastest USB SSDs are limited to 600MByte/sec, but few can reach that speed.
>>
>> As NVME simply requires a PCI express port, which is available on many raspberry
>> pi boards, the max I/O speed for a pi is the speed of a single PCI Express Gen 3
>> (1GByte/s) or Gen 4 (2Gbytes/s) lane depending on the pi.  Might even see
>> Gen 5 in the next couple of years (4Gbytes/sec) in future Pi processors.
>
>
>I have several Pi's, and only in the last have I found what I think is
>a grievious error, installed heat sinks, turned it on. After a few
>minutes I noticed a searing pain where my hand was leaning on  one of
>the heat sinks.
>
>greymausg@mail.com

I think this is mostly moot.  A maxed out 360 would have under a gig
of DASD.  On a pi 4 with 4 or 8 gig of RAM there's enough to buffer
the entire system, so our emulated 360, DASD and all, would be running
mostly RAM resident.

I think we forget how _immense_ the capacity of even a good _watch_ is
by '60s standards.

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

#218810

From	Andy Burns <usenet@andyburns.uk>
Date	2021-09-11 20:02 +0100
Message-ID	<iq4cq6Fnu37U1@mid.individual.net>
In reply to	#218795

Scott Lurndal wrote:

> As NVME simply requires a PCI express port, which is available on many raspberry
> pi boards

The latest pi compute module has PCIe and various breakout boards make 
it available as a normal X1 slot, but other than that, I thought to get 
access to PCIe on any other pi required de-soldering the USB chip?

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

#218812

From	scott@slp53.sl.home (Scott Lurndal)
Date	2021-09-11 19:42 +0000
Message-ID	<QE7%I.29969$tA2.23581@fx02.iad>
In reply to	#218810

Andy Burns <usenet@andyburns.uk> writes:
>Scott Lurndal wrote:
>
>> As NVME simply requires a PCI express port, which is available on many raspberry
>> pi boards
>
>The latest pi compute module has PCIe and various breakout boards make 
>it available as a normal X1 slot, but other than that, I thought to get 
>access to PCIe on any other pi required de-soldering the USB chip?

Hence "many" instead of "all".

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

#218814

From	Andy Burns <usenet@andyburns.uk>
Date	2021-09-12 11:45 +0100
Message-ID	<iq641fF3c7mU2@mid.individual.net>
In reply to	#218812

Scott Lurndal wrote:

> Andy Burns writes:
>
>> The latest pi compute module has PCIe and various breakout boards make
>> it available as a normal X1 slot, but other than that, I thought to get
>> access to PCIe on any other pi required de-soldering the USB chip?
> 
> Hence "many" instead of "all".

It'd be "a few" in my book.

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

#218818

From	J. Clarke <jclarke.873638@gmail.com>
Date	2021-09-12 12:24 -0400
Message-ID	<kcasjg1ba6mfr0kpt9cqpnetq1c7sfp4eq@4ax.com>
In reply to	#218814

On Sun, 12 Sep 2021 11:45:01 +0100, Andy Burns <usenet@andyburns.uk>
wrote:

>Scott Lurndal wrote:
>
>> Andy Burns writes:
>>
>>> The latest pi compute module has PCIe and various breakout boards make
>>> it available as a normal X1 slot, but other than that, I thought to get
>>> access to PCIe on any other pi required de-soldering the USB chip?
>> 
>> Hence "many" instead of "all".
>
>It'd be "a few" in my book.
>
I think "hardly any" comes closer.

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

#218764

From	Peter Flass <peter_flass@yahoo.com>
Date	2021-09-08 11:50 -0700
Message-ID	<1720012311.652819702.722284.peter_flass-yahoo.com@news.eternal-september.org>
In reply to	#218760

John Goerzen <jgoerzen@complete.org> wrote:
> On 2021-09-07, J  Clarke <jclarke.873638@gmail.com> wrote:
>>> https://governor.kansas.gov/wp-content/uploads/2021/04/GintherTaxCouncilKDOT.pdf
>>> hints that it may be an IBM System 370/Model 145.
>> 
>> I'd be very surprised if it actually was.  When did IBM end
>> maintenance on those?
> 
> I have no more information, other than that link claims "The Kansas UI System
> runs on a Mainframe that was installed in 1977."
> 
> Is it possible the hardware was upgraded to something that can emulate the
> 370/145, and that difference was lost on a non-technical author?  Sure.
> 
> I have known other places to run mainframes an absurdly long time.  I've seen it
> in universities and, of course, there's the famous CompuServe PDP-10 story -
> though presumably they had more technical know-how to keep their PDP-10s alive.
> You are right; it does seem farfetched.
> 
> ... so I did some more digging, and found
> https://ldh.la.gov/assets/medicaid/mmis/docs/IVVRProcurementLibrary/Section3RelevantCorporateExperienceCorporateFinancialCondition.doc
> which claims that the "legacy UI system applications run on the Kansas
> Department of Administration's OBM OS/390 mainframe."
> 
> I know little of IBM's mainframe lineup, but
> https://en.wikipedia.org/wiki/IBM_System/390 claims that the System/390 has some
> level of compatibility with the S/370.
> 
> - John
> 

You can still run programs compiled on a 360 on the latest “z” box.

-- 
Pete

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

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

csiph-web

What is the oldest computer that could be used today for real work?

Contents

#218774

#218782

#218784

#218790

#218793

#218794

#218805

#218811

#218785

#218787

#218789

#218795

#218797

#218804

#218808

#218810

#218812

#218814

#218818

#218764