On 2012-06-03 23:21, Mark Benson wrote:
On 4 May 2012, at 00:07, Boyanich, Alastair wrote:
Sampsa:
Interesting. Be sure to set up the idle detection in the simh.ini for
your appropriate OS (netbsd/TheoLinux/VMS/Ultrix/etc..) or it'll run the
CPU flat-out all the time and potentially get hot. I'm really curious to
hear how 'hot' the R-Pi's get under load. Mine's still on order.
Beautiful idea.
I got my Raspsberry Pi Thursday. It runs SimH 3.9.0 flawlessly under the provided Debian Linux 'squeeze' distribution from a SD Card. The I/O on the RPi isn't fantastic from SD Card, it just about manages 5.5MB/s by most people's benchmarks which is rather slow.
libpcap and screen are installable from the provided arm6l repositories so no need for compiling those. Once I did that I just downloaded the source zip, unzipped it into a directory and used 'make' to build, just like normal. Built fine and runs perfectly.
PDP-11 simulation is plenty snappy enough running RSX-11M Plus 4.2 on a simulated 11/83 with 2048kW of RAM. I have DECNet 4.0 (Phase IV) working on there too and it works fine.
Nice.
VAX KA655X simulation is... sluggish. I'm used to running it on 1.xGHz x86_64 CPUs (Atom or AMD) with fast hard drives or SATA SSD. The CPU speed makes it slow but imagine it's as fast or faster than a real late model VAX. It's by no means perishingly annoying, it just takes a little thinking between operations. I think I may be spoilt as I've never used a real VAX.
It would be interesting to hear of a comparison. The "newer" VAXen are really not that bad. But of course, everything is relative...
Overall so far I'm very impressed with the RasPi and it will fulfil the roles I need for it. When I get hold of a few more I am going to try and build a VMS cluster that uses less than 6W :) I will also have one permanently running a PDP-11 (something that I've not managed since I had my Cobalt Qube2 running) RSX-11MP system.
Talk about doing a misread. I saw that as an RSX-11 MultiProcessor system. :-)
Oh and CPU Idle works just fine in PDP-11 and VMS-VAX simulations. To be honest even when I compiled all the simulator binaries for SimH (as a stress test) and when I was running the SYSGEN in RSX-11M it barely got much worse temperature-wise than hot to touch a the CPU. On a board that only uses 300mA with no USB and Ethernet active it hardly has a lot of energy to dissipate as heat in the first place!
I would suspect that is because the CPU will still be just waiting for I/O lots of the time. Compilations, as well as running something like SYSGEN in RSX, is really I/O intensive. Not much CPU work in there.
Johnny
On 4 Jun 2012, at 15:07, Steve Davidson wrote:
You paged??? I've been flat out lately. Sorry.
What's up? I will be around all day today.
I needed to bother you about a couple of things:
My Multinet tunnel to your network has died unrecoverable (or so I can see).
I am gearing up to start work on a VMS cluster and need some tips and tuition.
I'll be around for a while tonight.
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
On 6/4/2012 12:58 PM, Rob Jarratt wrote:
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE] On Behalf Of Paul_Koning at Dell.com
Sent: 04 June 2012 17:26
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Speaking of IDLE
On Jun 4, 2012, at 12:04 PM, Brian Hechinger wrote:
Sadly the updates didn't fix it for me. :(
VAX simulator V3.9-0
/simh/rifter/vax.ini> set cpu idle
Command not allowed
-brian
Silly question, but is "set cpu idle" actually the first thing in your ini
file? Can you post the whole ini file?
I'd have to check, but if I just run it with no ini file I still get that issue (and this is on latest and greatest Sol 11)
wonko at larry:~/software/simh$ BIN/vax
VAX simulator V3.9-0
sim> set cpu idle
Command not allowed
sim>
-brian
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE] On Behalf Of Paul_Koning at Dell.com
Sent: 04 June 2012 17:26
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Speaking of IDLE
On Jun 4, 2012, at 12:04 PM, Brian Hechinger wrote:
Sadly the updates didn't fix it for me. :(
VAX simulator V3.9-0
/simh/rifter/vax.ini> set cpu idle
Command not allowed
-brian
Silly question, but is "set cpu idle" actually the first thing in your ini
file? Can you post the whole ini file?
Regards
Rob
On 6/4/2012 12:26 PM, Paul_Koning at Dell.com wrote:
On Jun 4, 2012, at 12:04 PM, Brian Hechinger wrote:
Sadly the updates didn't fix it for me. :(
VAX simulator V3.9-0
/simh/rifter/vax.ini> set cpu idle
Command not allowed
-brian
That's odd. I just downloaded and built simh 3.9.0, and it accepts the command without any complaints, both in "vax" and "vax780":
pkoning:simhv39-0 pkoning$ BIN/vax780
VAX780 simulator V3.9-0
sim> set cpu idle
sim> show cpu idle
idle=VMS, idle enabled, stability wait = 20s
sim> set cpu idle=NETBSD
sim> show cpu idle
idle=NETBSD, idle enabled, stability wait = 20s
sim> q
Goodbye
pkoning:simhv39-0 pkoning$ BIN/vax
VAX simulator V3.9-0
sim> show cpu idle
idle disabled
sim> set cpu idle
sim> show cpu idle
idle=VMS, idle enabled, stability wait = 20s
sim> set cpu idle=OPENBSD
sim> show cpu idle
idle=OPENBSD, idle enabled, stability wait = 20s
sim> q
Goodbye
pkoning:simhv39-0 pkoning$
Yeah, works fine on linux, but Solaris not so much. :(
And now libpcap doesn't want to easily build on newest Solaris 11. Joy.
-brian
On Jun 4, 2012, at 12:04 PM, Brian Hechinger wrote:
Sadly the updates didn't fix it for me. :(
VAX simulator V3.9-0
/simh/rifter/vax.ini> set cpu idle
Command not allowed
-brian
That's odd. I just downloaded and built simh 3.9.0, and it accepts the command without any complaints, both in "vax" and "vax780":
pkoning:simhv39-0 pkoning$ BIN/vax780
VAX780 simulator V3.9-0
sim> set cpu idle
sim> show cpu idle
idle=VMS, idle enabled, stability wait = 20s
sim> set cpu idle=NETBSD
sim> show cpu idle
idle=NETBSD, idle enabled, stability wait = 20s
sim> q
Goodbye
pkoning:simhv39-0 pkoning$ BIN/vax
VAX simulator V3.9-0
sim> show cpu idle
idle disabled
sim> set cpu idle
sim> show cpu idle
idle=VMS, idle enabled, stability wait = 20s
sim> set cpu idle=OPENBSD
sim> show cpu idle
idle=OPENBSD, idle enabled, stability wait = 20s
sim> q
Goodbye
pkoning:simhv39-0 pkoning$
paul
On 6/4/2012 10:50 AM, Paul_Koning at Dell.com wrote:
On Jun 4, 2012, at 10:14 AM, Brian Hechinger wrote:
On 6/4/2012 7:55 AM, Dave McGuire wrote:
On 06/04/2012 07:52 AM, Brian Hechinger wrote:
Anyone know how it works? I'd really like to get it working on Solaris.
You mean it doesn't? I wonder why that would be.
/simh/rifter/vax.ini> set cpu idle=VMS
Command not allowed
It detects the idle loop patterns in some OSs and throttles back the
simulator, so the host system isn't sitting there burning CPU to execute
the guest OS's idle loop.
Right, but I'm curious what it needs to know about the host OS to accomplish that.
I should look at the source but I'm not sure I'll know what I'm looking at. :)
See vax_cpu.c.
My copy (SIMH 3.8.1) rejects that command with a different message: "Invalid argument". But to make things even stranger, it DOES accept the command -- "show cpu idle" shows that it paid attention.
Possibly the issue is that the VAX-specific command next passes control to the general command (in sim_timer.c) and that routine accepts an argument but requires it to be an integer!
You might try simply "set cpu idle" (without argument). The default seems to be VMS, with NETBSD, OPENBSD, ULTRIX, and 32V accepted as alternate values. The difference is in what the particular OS does when it is idle. That tends to change from one OS to another (even when the hardware seems to suggest a standard way to do it, as in the PDP11 with its WAIT instruction).
paul
Sadly the updates didn't fix it for me. :(
VAX simulator V3.9-0
/simh/rifter/vax.ini> set cpu idle
Command not allowed
-brian
On 6/4/2012 10:59 AM, Paul_Koning at Dell.com wrote:
On Jun 4, 2012, at 10:53 AM, Brian Hechinger wrote:
On 6/4/2012 10:50 AM, Paul_Koning at Dell.com wrote:
On Jun 4, 2012, at 10:14 AM, Brian Hechinger wrote:
On 6/4/2012 7:55 AM, Dave McGuire wrote:
On 06/04/2012 07:52 AM, Brian Hechinger wrote:
Anyone know how it works? I'd really like to get it working on Solaris.
You mean it doesn't? I wonder why that would be.
/simh/rifter/vax.ini> set cpu idle=VMS
Command not allowed
It detects the idle loop patterns in some OSs and throttles back the
simulator, so the host system isn't sitting there burning CPU to execute
the guest OS's idle loop.
Right, but I'm curious what it needs to know about the host OS to accomplish that.
I should look at the source but I'm not sure I'll know what I'm looking at. :)
See vax_cpu.c.
My copy (SIMH 3.8.1) rejects that command with a different message: "Invalid argument". But to make things even stranger, it DOES accept the command -- "show cpu idle" shows that it paid attention.
Possibly the issue is that the VAX-specific command next passes control to the general command (in sim_timer.c) and that routine accepts an argument but requires it to be an integer!
You might try simply "set cpu idle" (without argument). The default seems to be VMS, with NETBSD, OPENBSD, ULTRIX, and 32V accepted as alternate values. The difference is in what the particular OS does when it is idle. That tends to change from one OS to another (even when the hardware seems to suggest a standard way to do it, as in the PDP11 with its WAIT instruction).
Same thing:
/simh/rifter/vax.ini> set cpu idle
Command not allowed
-brian
Looks like you'll have to read the Fine Code to see what changed.
paul
Looks like there were some changes to IDLE for the VAX in 3.9
building that now.
-brian
On 6/4/2012 11:00 AM, Dave McGuire wrote:
On 06/04/2012 10:14 AM, Brian Hechinger wrote:
Anyone know how it works? I'd really like to get it working on Solaris.
You mean it doesn't? I wonder why that would be.
/simh/rifter/vax.ini> set cpu idle=VMS
Command not allowed
Oh my. I assume that's done by a #define somewhere. Have you looked?
Yes. The code is a little.............. tricky to follow.
I don't think I'm going to be able to sort this out. I just don't have the time it'll take to go through all his code. :(
-brian
