Load on Raspberry Pi

[D Gillies]

I heard from a friend back in 1977, who was studying for a PhD in Computer Science / Systems area, that UNIX was the first operating system with an overhead of less than 10% of the cpu.   At the time, other systems like OS/360 or maybe some other 1960's systems (Michigan Terminal System/MTS?).  In particular, I think the first version of OS/360 had a 90% overhead (that is, 10% of the cpu was left over for running user programs), in its first release.

- Don Gillies

Palo Alto, CA, USA

[Johnny Billquist]

That is complete nonsense.
Unix probably have higher overhead compared to other OSes on the PDP-11,
since C compilers at the time was nowhere near the performance of hand
optimized assembler.

I can't speak for most other platforms, but since the PDP-11 was
basically what you'd be running Unix on in 1977, we can probably focus a
bit on that.

Johnny

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

[Johnny Billquist]

By the way, as an anecdote. In 1984 or so, I was using a PDP-11/70
running RSTS/E where we normally were somewhere around 40 users online
at the same time, most doing one thing or other (this was at a school,
so various people doing programming, some running various other
applications).

With 40 users it was running along just fine.
On bad days we got close to 60 users, and then it wasn't that much fun
anymore.

But I have never seen or heard anyone running more than 40 users under
Unix on an 11/70, with an acceptable performance.

Johnny

[Sytse van Slooten]

In the time of OS/360, MFT, MVT and maybe even a bit later when it was renamed to MVS already, IBM used to use a marketing statistic to brag that their systems were spending 90% of their time running IBM code - of course with the explanation that the OS, libraries etc contained so much functionality that users had to do almost nothing themselves. Who knows, maybe they were even correct, given that many IBM users had loads of COBOL code and that easily compiles to lots of library calls. I'm not quite sure, maybe the marketing started this line to justify software licence fees - which was a new thing in those days.

Other than that, OS/360 is a very small operating system - if you consider the same parts as what you would call the OS in other systems; almost all functionality is layered on top of it as separate packages. In today's terms, you could call it a microkernel.

I remember from the late 80s that I worked on a detailed performance report of a large MVS system. I don't recall the exact numbers, but the OS and all associated system software for job entry, networking, data management did not consume any meaningful amount of the total capacity. What did take a lot of capacity were the transaction monitors - but those were very closely interrelated to the user code.

So what I think is that your friend maybe misremembered the marketing line. I've not really worked with OS/360, but I can't imagine anything like these numbers to be correct, and they're certainly not for the somewhat later 370 versions.

Cheers,

Sytse

 

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/6252bd8b-5b77-486d-bd23-75267de54befn%40googlegroups.com.

[Anton Lavrentiev]

Even today, quite a beefy multicore Linux box with tons of memory but 40+ users using it simultaneously, would look rather shaky, especially if all those users would want to run just C compiler let alone anything more computation-intensive....  So nothing has drastically changed from the olden days ;-)  LOL 

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/c27efabf-9ba3-8d81-ea45-100449e5c838%40softjar.se.

[Johnny Billquist]

Well... You could say it's gotten worse. I think even 40 users on a
modern machine is generally a very horrible experience... :-)

Johnny

> email: b...@softjar.se <mailto:b...@softjar.se>             ||

> Reading murder books
> pdp is alive!                     ||  tryin' to stay hip" - B. Idol
>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11%2Bunsu...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-11/c27efabf-9ba3-8d81-ea45-100449e5c838%40softjar.se

> <https://groups.google.com/d/msgid/pidp-11/c27efabf-9ba3-8d81-ea45-100449e5c838%40softjar.se>.

[D Gillies]

Actually I understand that the original K&R C compiler (or pcc) was not bad in terms of efficiency.

while (*p++ = *q++);

compiled into 2 instructions, a move-memory register-indirect using auto increment, and a conditional jump-nonzero back to the move instruction, an optimal result.

- Don Gillies

Palo Alto, CA, USA

[Johnny Billquist]

On 2022-05-20 07:13, D Gillies wrote:
> Actually I understand that the original K&R C compiler (or pcc) was not
> bad in terms of efficiency.
>
> while (*p++ = *q++);
>
> compiled into 2 instructions, a move-memory register-indirect using auto
> increment, and a conditional jump-nonzero back to the move instruction,
> an optimal result.

Sure. It does a reasonable job at that level. But there is so much more
to this topic... Also, Unix on PDP-11 isn't near as slim as some of the
DEC offerings. Something like RT-11 is ridiculously light weight.
RSX-11M is also pretty minimal at this level. M+ and RSTS/E are more
fancy, but still using less resources than Unix.
The 90% claim is so far out by the moon if we talk about PDP-11s that
it's not really even worth having a discussion about. Overhead for
basically any OS is way below 10%, more likely somewhere about 1-2% for
the lighter ones, and maybe 3-5% on the really fancy ones. I can believe
if Unix might go a bit higher than that, but I'd still expect it to be
firmly below 10%.

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/8ae88923-20b7-49ff-b66b-811ed57cb152n%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/8ae88923-20b7-49ff-b66b-811ed57cb152n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Regan Russell]

I have a 24 CPU Onyx2 with 48Gb RAM. IRIX consumes 50Mb in gr_osview. Really.

R.

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/f244b355-bd2d-ada9-d945-253b97e736cc%40softjar.se.

--

All the best,

Visit Pymblesoftware.com.au

[jon....@gmail.com]

For a PDP-11 era typical timesharing load, I'm sure you can fit well more than 40 users. For sufficiently large jobs, compiling is probably one of the more purely CPU-bound loads you can put on a machine, but the "sufficiently large jobs" threshold is moving upward: A Linux kernel compile on my latest beefy multicore Linux box runs in just shy of 14 minutes on 16 cores, and a kernel compile beats out just about anything else I've ever compiled for runtime. If you've got 40 users on a box working with code, I'd expect them to be spending most of their time in an editor, and the average compile-job would likely be much smaller than a kernel build.

Now, if they're all running a lightweight graphical session (the kind of thing you can expect to work over the network), I think 40 users might be feasible, depending on the size of your box, the size of your network link, and how much network bandwidth the remote sessions eat (network might well be the limiting factor).

If they're all running 3d games, well, that's generally not going to work for even a single user over the network, and you likely only have one graphics adapter. You probably don't have enough PCI slots for many GPUs even if you do have more than one, and many such games have significant CPU requirements in addition, *and* are interactive, so the scheduler can't resort to the trick of prioritizing interactive and I/O bound jobs over CPU-bound jobs (though games often aren't as parallelizable as compiling is, so with enough cores you might not be CPU-limited). Most people don't even try running more than one user for this sort of thing.

[jon....@gmail.com]

On Wednesday, May 18, 2022 at 7:26:05 PM UTC-5 Sy...@sytse.net wrote:

In the time of OS/360, MFT, MVT and maybe even a bit later when it was renamed to MVS already, IBM used to use a marketing statistic to brag that their systems were spending 90% of their time running IBM code - of course with the explanation that the OS, libraries etc contained so much functionality that users had to do almost nothing themselves. Who knows, maybe they were even correct, given that many IBM users had loads of COBOL code and that easily compiles to lots of library calls. I'm not quite sure, maybe the marketing started this line to justify software licence fees - which was a new thing in those days.

In addition to "90% of user CPU time is spent in our super-cool labour-saving libraries", I can imagine that IBM marketing may have wanted, early on, before timesharing, to draw attention to how much time their OS was spending running things as opposed to idling (and IBM likely would have made this a point of pride for longer than other vendors), because a batch system's motto is "idle cycles are the devil's workshop", while a timesharing or PC system's motto is "they also serve who only stand and wait". 

[Carl Marbach]

Prior to RSTS/E V7.1, there was a limit to how many users could be
logged in at the same time. It was around 40-45 users. In V7.1, RSTS/E
enabled ( in the start up)  the "I and D" space allowing there to be at
least double the number of small buffers and thus double the number of
simultaneous users.

TRUE STORY:

I am in a meeting in my office, as publisher of the RSTS/E Professional
and DEC Professional magazines, when we are interrupted by our
receptionist who says, "Carl, you have a phone call." I reply, "Marge we
are in a meeting." She continues, "They said it is the President>" "Of
what?", I reply.  "The United States", she says.  Well, it wasn't the
President (Reagan), but it was his office. David Stockman, Director of
the Office of Management and Budget, had many staffers working on the
upcoming budget all on a PDP-11/70 running RSTS/E V7.1.

At about 4:00 pm each afternoon they exceeded the maximum number of
users (about 44), and no one else could log in. "Is there any thing we
can do to increase this number," they asked. I asked if anyone else had
looked at this and they told me DEC had been there and said, "nothing
could be4 done." I agreed to come to Washington and look. I landed in
Washington the very early next morning at Washington National airport in
my beloved Mooney Super 21. Upon arrival at the White House I was taken
to a computer room with 4 PDP-11/70's and a few other computers that I
don't remember. I asked if I could take the 11/70 that Stockman used
down and look around. After shutting down, rebooting with the I & D
space now enabled, I told the manager that I expected the machine would
support up to 80 Simultaneous users. It took about 10 minutes for the
whole operation. He looked at me like I was from Mars and said, "But DEC
said nothing could be done!"

I'm sure he didn't believe me and asked if I would stay for the day to
see how it went. I agreed and at 3 PM or so, they approached the
previous limit of 40 something users. As we watched,
40...43..45..49..53..55..60..65.....He was believer.

President Reagan's budget for 1982 was formulated on a PDP-11/70 running
RSTS/E V7.1 !!!

[sydn...@gmail.com]

Carl--that is a truly amazing story!    I fondly remember your RSTS Professional magazine in the early 1980's. At my company, we had an 11/70 running RSTS/E and we would anxiously await each new issue, and when it arrived we read every single page over and over. The 1980's were great times and you and Dave brought ideas and people together in the DEC communities. Thank you!

[Johnny Billquist]

I think my first experience was with RSTS/E V7.1, so I don't think I can
comment much about anything earlier than that.

However, the hard upper limit on the number of users in RSTS/E from V7.1
and upward is 63, and that is still the hard upper limit even today.

I'm sure Paul Konig can give more information on this topic than I can. :-)

I do know that at some later point than 7.1, the number of possible
terminals were raised to 127 (or of it was 128), but max number of
jobs/users were still 63.

I'm also fairly sure we were running up to 63 users already on V7.1.

Johnny

[Kim Colwell]

Hi, group ..  Just got delivery of my PiDP-11 (very cool) and can’t wait to start construction.

 

I also have got my hands on a Pi 3 B+ (1 GB) and a Pi 4 B (2GB) .. which do you suggest would be a better install on the PiDP-11?  I presume the Pi 4, but I also want to play with the Pi on it’s own separately, so I think the Pi 4 would be a better fit for that purpose.  Would the Pi 3 B+ do well on the PiDP-11 (even tho it only has 1 GB)?

 

Thanks for any feedback.

 

KImC

 

Sent from Mail for Windows

--

You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/59669abc-8e94-a2c8-34a7-8be98251f8eb%40softjar.se.

 

[Anton Lavrentiev]

Welcome to the club :-)

I have Pi3B+ and I can't complain with performance once I replaced the SD card with a high speed branded one.  I heard (on this list) Pi 4 may run into temp issues so may need some additional protection from overheating, which 3B+ doesn't.

My $.02

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/AF15E034-65F0-4143-AB90-BF2975B88BF8%40hxcore.ol.

[Ken Hansen]

Either RPi should be fine, and early overheating issues with the RPi 4 were resolved long ago in firmware - an RPi 4 with current firmware should be fine. If you're worried about it, consider putting a heatsink on the SoC/CPU chip.

The PiDP-11 software doesn't need 1 gig of RAM, I've run it happily on an RPi 3 A+ (the square RPi with no Ethernet port and only one USB port) which only has 512 Meg of RAM.

If you don't need full-size USB 2.0 ports, the RPi Zero 2 W would also be good, it's like a tiny RPi 3 B+ with 4 cores, it should run just fine and you can connect via WiFi (ssh).

Ken

On May 23, 2022, at 21:52, Anton Lavrentiev <anton.la...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/CAAo%3Dyr2Dt11g4yRY7LvE%3DZknzQi%3DkAq8Jv1d%3Dunt-JStxMUJfg%40mail.gmail.com.

[Jon Brase]

>it should run just fine and you can connect via WiFi (ssh).

If you want to get full value out of networking on 2.11 BSD or RSX-11M+, however, wifi can't bridge the guest machine's Ethernet properly: you need wired Ethernet.

[Anton Lavrentiev]

> however, wifi can't bridge the guest machine's Ethernet properly: you need wired Ethernet.

I've seen this so many times before, but can someone please explain in plain language, why is it so with wifi vs. wired?  What's the (big) difference?  Thx!

[Warner Losh]

On Tue, May 24, 2022 at 1:27 PM Anton Lavrentiev <anton.la...@gmail.com> wrote:

> however, wifi can't bridge the guest machine's Ethernet properly: you need wired Ethernet.

I've seen this so many times before, but can someone please explain in plain language, why is it so with wifi vs. wired?  What's the (big) difference?  Thx!

The frame format for wireless is not quite the frame format for wired. This 'not quite' rarely matters since most people

talk at the IP or higher level, or they know how to cope with the extra MAC address that can be there. Not so

with systems like simh which pass the frames through to the guest OS unchanged. so over wifi bridging doesn't

work.

(source: https://www.rfwireless-world.com/Articles/WLAN-MAC-layer-protocol.html)

vs

(source: http://www.dcs.gla.ac.uk/~lewis/networkpages/m04s03EthernetFrame.htm#:~:text=The%20MAC%20addresses%20used%20in,driven%20by%20the%20transmission%20order)%20.) 

Disclaimer: there's a couple of different 802.11 mac formats, and I may have pasted the wrong one here...

Warner

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/CAAo%3Dyr1V8a5m%2BmzqgqKP%2B2G0DZM9sVXyyrb2LcC-%3Dwg0g6JqPg%40mail.gmail.com.

[Johnny Billquist]

Trying to recollect the exact details here...

The problem stems from that WiFi don't truly have real broadcasting.
Basically, when you have something doing a broadcast that should travel
over WiFi, the L2 layer will in fact deliver it point to point to each
remote node. And WiFi do this by keeping track of the actual MAC address
of each station connected. And now we're talking about the MAC of the
actual WiFi interface, and not whatever fake MAC address you might be
playing around with. WiFi have to do it this way, since you basically
have to have transmit with some kind of handshaking down at the radio
level, or else things just don't work reliably enough to be useful.

And here is where the problem comes. When you run simh (for example),
your machine actually would appear to have two MAC addresses, and
packets ought to be sent to both when it's a broadcast, but it's not,
since the MAC address of your simh instance isn't visible at the WiFi
broadcast level. So your network connection only half works. Point to
point packets will get through, but protocols like ARP do not work
right. So your networking will only half work in this case. It might
work a while, and then stop. It might work again at some point, and then
stop.

WiFi is *not* ethernet. On ethernet broadcasts as well as switching is
purely done by the visible MAC address, and thus your machine can have
several, and all other equipment will understand and deal with that just
fine. WiFi don't work like ethernet. Even though it does a pretty good
imitation of it, as long as you don't do anything funny (like try to
have a second MAC address).

One workaround that can be done is to use the same MAC address for both
your pi and your simh. This isn't trivial to set up, but it can be done.
I've done it. Then you can have things working.
Or else do a switch or a router that talks on the WiFi, and then
forwards the packets to your simh instance. That obviously also works.

And modulo I might have gotten some details wrong. But end result is
that broadcasts do not work, and networking usually runs for the first
few minutes, but then stop. It basically stops the moment some machine
wants to talk to your simh instance, and it needs to use ARP to find the
simh instance. Those ARP requests will never reach the simh instance.

Johnny

[Johnny Billquist]

Well, IP don't know how to deal with that extra MAC address either. It's
all very hidden from software, but it matters to the WiFi routers when
they talk to other nodes.

If you run tcpdump on a WiFi interface, it really looks no different
than ethernet. The extra addresses and layers are down at the radio
level, where the "not ethernet" happens.

Johnny

On 2022-05-24 21:39, Warner Losh wrote:
>
>
> On Tue, May 24, 2022 at 1:27 PM Anton Lavrentiev
> <anton.la...@gmail.com <mailto:anton.la...@gmail.com>> wrote:
>
> > however, wifi can't bridge the guest machine's Ethernet properly:
> you need wired Ethernet.
>
> I've seen this so many times before, but can someone please explain
> in plain language, why is it so with wifi vs. wired?  What's the
> (big) difference?  Thx!
>
>
> The frame format for wireless is not quite the frame format for wired.
> This 'not quite' rarely matters since most people
> talk at the IP or higher level, or they know how to cope with the extra
> MAC address that can be there. Not so
> with systems like simh which pass the frames through to the guest OS
> unchanged. so over wifi bridging doesn't
> work.
>

> image.png
> (source:
> https://www.rfwireless-world.com/Articles/WLAN-MAC-layer-protocol.html
> <https://www.rfwireless-world.com/Articles/WLAN-MAC-layer-protocol.html>)
>
> vs

>
> image.png
> (source:
> http://www.dcs.gla.ac.uk/~lewis/networkpages/m04s03EthernetFrame.htm#:~:text=The%20MAC%20addresses%20used%20in,driven%20by%20the%20transmission%20order)%20

> <http://www.dcs.gla.ac.uk/~lewis/networkpages/m04s03EthernetFrame.htm#:~:text=The%20MAC%20addresses%20used%20in,driven%20by%20the%20transmission%20order)%20>.)

>
>
> Disclaimer: there's a couple of different 802.11 mac formats, and I may
> have pasted the wrong one here...
>
> Warner
>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-11/CAAo%3Dyr1V8a5m%2BmzqgqKP%2B2G0DZM9sVXyyrb2LcC-%3Dwg0g6JqPg%40mail.gmail.com

> <https://groups.google.com/d/msgid/pidp-11/CAAo%3Dyr1V8a5m%2BmzqgqKP%2B2G0DZM9sVXyyrb2LcC-%3Dwg0g6JqPg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/CANCZdfrZ%3D%3D89frkEzJUsTmEHJc0p3t1ix-VYzgN26OvXJ1MvCw%40mail.gmail.com
> <https://groups.google.com/d/msgid/pidp-11/CANCZdfrZ%3D%3D89frkEzJUsTmEHJc0p3t1ix-VYzgN26OvXJ1MvCw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[desa...@gmail.com]

I posted a workaround for SIMH with WiFi here with the help of Proxy ARP: https://groups.google.com/g/pidp-11/c/aIFONtn2z4A/m/CMM7puvdCAAJ

It's been a long while, so maybe the tools have changed by now, but the principle should be the same.

(I know `tunctl` is considered deprecated, and you should use the `ip` command instead).

This is a bit complicated for the reasons described in this thread, and to keep things simple and robust I would rather use the ethernet interface with normal bridging instead.

[Marco]

I had one of these lying around, and used that in Ethernet to WiFi bridge mode. They cost about 25 $/€ and are reliable, and very small . Your Pi (and thus simh) is Ethernet connected but you are actually on the WiFi. I can confirm this works, also with normal bridging. Only downside is that if you power it from one one the Pi's USB ports (which is the most convenient way, if you have ports to spare) then it will take some time after the Pi powers up before Ethernet comes online. You could of course power it separately and keep it powered up all the time, it also acts as a WiFi repeater. Another small issue is that it lights up like a Christmas tree...

Op dinsdag 24 mei 2022 om 22:41:14 UTC+2 schreef desa...@gmail.com:

[Mike Ross]

Depends on the modern machine... you can have thousands of Linux systems running in VMs on a Z Series mainframe... ;-) 

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/ab1cad0f-01ec-0a48-72ca-6e30d05c5f32%40softjar.se.

--

http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'