Software update & Manual

[oscarv]

Hi,

The last few weeks have seen a lot of improvements to the PiDP-11 software as well as to the contents of the "software museum".

I just uploaded a beta version; the download & install procedure is in the freshly minted manual: https://www3.ispnet.net/pidp11/PiDP-11%20Manual%20v0.2.odt

It would be great if I could get some feedback from adventurous souls before dubbing this the New Release. Bug reports are very welcome, please let me know what Pi you use and what compile date simh displays when it starts up (PDP-11 simulator V4.0-0 Current  REALCONS build Jan 12 2019)

To upgrade,

• I recommend to just rename /opt/pidp11 into /opt/xidp11 and then start with a fresh pidp11 subdirectory. That way you can always revert to the old version.
• No need to rerun the install script, just do the following:
  apt-get update
  apt-get install libsdl2-dev
  apt-get install libpcap-dev
  for some additional things the new version needs.

I expect that new updates will come out much more regularly from now on. If you find any bugs, please just send me an email.

What has changed:

• decent setup for handling (re)booting into the various operating systems.
  The kludgy bootscripts/ directory is replaced by a systems/ directory, and a text file (systems/selections) now maps SR switch values to named subdirectories.
  
• networking enabled, very easy to do now for RSX and 211BSD. But only through Ethernet for the moment.
  Thanks to Mark Matlock, Bob Meyer and Johnny Billquist for doing the hard work!
  
• graphics. Play lunar lander under RT-11 to name one thing, but more is on its way.
  Thanks to Ian Schofield for doing the hard work (all the work, really) here!
• bug fix for the incidental LED flashes (Ian again)
• bug fix for the front panel display of register values (Jörg Hoppe)
• some small fixes and cleaning up
• I've received a few reports of the front panel driver crashing occasionally. Alas, not here so far - so I hope this is fixed but I feel rather unsure about that still.
  

Thanks to many people, including-but-not-limited-to Ian Schofield, Mark Matlock, Terry Kennedy, Johnny Billquist, Bob Meyer, Angelo Papenhoff, Jörg Hoppe, Mike Hill, Steve Casner and and - never mind, you know who you are! Much appreciated.

Lastly, the manual will steadily grow into a guided tour through PDP-11 as well as Raspberry Pi land. I think that makes sense, as many things are hard to discover if you're not aware of them. I think 99% of PiDP-11 builders miss out on interesting features - including myself. Self-studying an archaic OS (such as Raspbian) is fine, but a walk-through through the highlights tells you where to look.

Please send me any how-tos that should be included, the manual is editable on the Pi's OpenOffice as well as MS Word if you feel like it.

Kind regards,

Oscar.

[Sunnyboy010101]

Hi Oscar,

Just a quick note:

wget https://www3.ispnet.net/pidp11/nankervis.tar.gz

Returns "not found". Going to the server/directory does not show it in the file list.

Cheers,

-R

On 1/15/2019 1:02 PM, oscarv wrote:

Hi,

The last few weeks have seen a lot of improvements to the PiDP-11 software as well as to the contents of the "software museum".

I just uploaded a beta version; the download & install procedure is in the freshly minted manual: https://www3.ispnet.net/pidp11/PiDP-11%20Manual%20v0.2.odt

It would be great if I could get some feedback from adventurous souls before dubbing this the New Release. Bug reports are very welcome, please let me know what Pi you use and what compile date simh displays when it starts up (PDP-11 simulator V4.0-0 Current  REALCONS build Jan 12 2019)

To upgrade,

• I recommend to just rename /opt/pidp11 into /opt/xidp11 and then start with a fresh pidp11 subdirectory. That way you can always revert to the old version.
• No need to rerun the install script, just do the following:
  apt-get update
  apt-get install libsdl2-dev
  apt-get install libpcap-dev
  for some additional things the new version needs.

I expect that new updates will come out much more regularly from now on. If you find any bugs, please just send me an email.

What has changed:

• decent setup for handling (re)booting into the various operating systems.
  The kludgy bootscripts/ directory is replaced by a systems/ directory, and a text file (systems/selections) now maps SR switch values to named subdirectories.
  
• networking enabled, very easy to do now for RSX and 211BSD. But only through Ethernet for the moment.
  Thanks to Mark Matlock, Bob Meyer and Johnny Billquist for doing the hard work!
  
• graphics. Play lunar lander under RT-11 to name one thing, but more is on its way.
  Thanks to Ian Schofield for doing the hard work (all the work, really) here!
• bug fix for the incidental LED flashes (Ian again)
• bug fix for the front panel display of register values (Jörg Hoppe)
• some small fixes and cleaning up
• I've received a few reports of the front panel driver crashing occasionally. Alas, not here so far - so I hope this is fixed but I feel rather unsure about that still.
  

Thanks to many people, including-but-not-limited-to Ian Schofield, Mark Matlock, Terry Kennedy, Johnny Billquist, Bob Meyer, Angelo Papenhoff, Jörg Hoppe, Mike Hill and and - never mind, you know who you are! Much appreciated.

Lastly, the manual will steadily grow into a guided tour through PDP-11 as well as Raspberry Pi land. I think that makes sense, as many things are hard to discover if you're not aware of them. I think 99% of PiDP-11 builders miss out on interesting features - including myself. Self-studying an archaic OS (such as Raspbian) is fine, but a walk-through through the highlights tells you where to look.

Please send me any how-tos that should be included, the manual is editable on the Pi's OpenOffice as well as MS Word if you feel like it.

Kind regards,

Oscar.

--
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/54fca43c-a638-4b24-b0b5-82202e7c1381%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Virus-free. www.avast.com

[oscarv]

Thanks - solved!

[Peter Long]

Not sure if anyone has run across this – the Jan 4 release runs fine however the Jan 12 run so slow as to be unusable…

 

Last message on the console is “Connecting to localhost ….”

 

The idle pattern on the console is so slow that you can see the increments in the pattern.

 

Again – this is just with the Jan 12 release, the Jan 4 release runs just fine (still) on the same hardware

 

Peter

Thanks to many people, including-but-not-limited-to Ian Schofield, Mark Matlock, Terry Kennedy, Johnny Billquist, Bob Meyer, Angelo Papenhoff, Jörg Hoppe, Mike Hill and and - never mind, you know who you are! Much appreciated.

 

Lastly, the manual will steadily grow into a guided tour through PDP-11 as well as Raspberry Pi land. I think that makes sense, as many things are hard to discover if you're not aware of them. I think 99% of PiDP-11 builders miss out on interesting features - including myself. Self-studying an archaic OS (such as Raspbian) is fine, but a walk-through through the highlights tells you where to look.

Please send me any how-tos that should be included, the manual is editable on the Pi's OpenOffice as well as MS Word if you feel like it.

 

Kind regards,

 

Oscar.

 

--

[pl...@insys.com.au]

Never mind - solved

2 things -

1) the new selections file (Jan 12) has 0000 as idled vs 0000 as rsx11mplus for the Jan 4 release - so I ended up in an unexpected place as my switches were set to 0

2) the boot.ini file(s) tries to attach xu to eth0, my eth0 is unplugged as I'm using wlan0 for the moment so startup hangs waiting for the ethernet 

Cheers

Peter

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

[oscarv]

Peter,

On Wednesday, January 16, 2019 at 7:27:56 AM UTC+1, Peter wrote:

1) the new selections file (Jan 12) has 0000 as idled vs 0000 as rsx11mplus for the Jan 4 release - so I ended up in an unexpected place as my switches were set to 0

Correct - the idea was it is better to boot into something that does not need a shutdown as the default boot option. Set the SR switches to 1 during powerup (as you saw)

2) the boot.ini file(s) tries to attach xu to eth0, my eth0 is unplugged as I'm using wlan0 for the moment so startup hangs waiting for the ethernet 

RSX does not hang if Ethernet networking is not connected, it'll time out quite quickly. There is also a delay during boot-up if you have not added the DECUS disk image as DU1. I decided not to add that disk image to the standard systems tarball, given its size. But you can add it (see manual) and bootup will be a tad quicker.

The thinking was that for an occasional visit to RSX, a time-out during boot is OK. Regular users will add the DECUS image disk anyway.

Kind regards,

Oscar.

[John Forecast]

Oscar,

   I've been going through the latest manual and running some of the images and have the following observations:

Manual

1. In the quick tour of 2.11BSD section, the two-line intro to the vi editor

    The abort command is :q! and :wq is save and exit, ESC is never used.

2. I notice you had added a reference to my fsio utility. It probably would be useful to add somewhere a pointer to simh/simtools repository on

    github.com where there are a number of utilities for manipulating disk and tape images.

Software

1. I've rebuilt client11 with VDE support and sucessfully run 2.11BSD networking on a Pi Zero W over wlan0. In fact everything goes over

    wlan0 since that's the only interface it has. I can provide a writeup of my configuration.

2. The dos11 package is running is running a badly broken version of DOS with some files missing. If you follow the documentation you get

    the cryptic error message "S203 00000" to indicate a bad switch to PIP. I've made an updated zip file of DOS 9.20C with the Fortran

    compiler included. This version automatically forces keyboard input to upper case only. It's available via dropbox at:

        https://www.dropbox.com/s/s1vbm6w8jsys8hh/dos11.zip?dl=0

3. Someone was asking about IAS here. I've made a kit of IAS V3.4A with timesharing enabled. It's also available via dropbox at:

        https://www.dropbox.com/s/7j4b56ddv4zwoao/ias.zip?dl=0

John.

[oscarv]

John,

Thank you! I'll update the manual with those improvements on Friday.

On Wednesday, January 16, 2019 at 9:31:51 PM UTC+1, John Forecast wrote:

1. I've rebuilt client11 with VDE support and sucessfully run 2.11BSD networking on a Pi Zero W over wlan0. In fact everything goes over

    wlan0 since that's the only interface it has. I can provide a writeup of my configuration.

Oh! Yes, please. That has been a bit of a holy grail the last two weeks!

2. The dos11 package is running is running a badly broken version of DOS

3. Someone was asking about IAS here. I've made a kit of IAS V3.4A with timesharing enabled.

Unless you object, I will add those to the distribution on Friday as well.

Thank you very much! Some significant steps forward again for the pidp11 package.

Kind regards,

Oscar.

[oscarv]

Hi,

Also, I just updated the systems tarball as I discovered I had included the wrong RT-11 setup. Much improved now.

The manual reflects that improvement with a lighthearted 2-page section on VT11/GT40 graphics and games.

If you already downloaded the entire systems tarball, here is a drop-in replacement for the systems/rt11/ directory:

https://www3.ispnet.net/pidp11/rt11.tar.gz

Kind regards,

Oscar

[Johnny Billquist]

A quick couple of comments...

On 2019-01-16 21:31, John Forecast wrote:
> Oscar,
>    I've been going through the latest manual and running some of the
> images and have the following observations:
>
> Manual
>
> 1. In the quick tour of 2.11BSD section, the two-line intro to the vi editor
>
>     The abort command is :q! and :wq is save and exit, ESC is never used.

Not totally true. If you are in insert mode, you need to press ESC first
to get out. And if you are not, it is harmless. So in general, it's a
fair recommendation.

> 2. I notice you had added a reference to my fsio utility. It probably
> would be useful to add somewhere a pointer to simh/simtools repository on
>     github.com where there are a number of utilities for manipulating
> disk and tape images.

Just as an FYI: If anyone have access to Ultrix, there is arff in there,
which is also a tool to manipulate RT11 file systems from Unix.
There is also John Wilsons PUTR, doing the same thing from Windows/MS-DOS.

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

[John Forecast]

On Wednesday, January 16, 2019 at 6:26:58 PM UTC-5, oscarv wrote:

John,

Thank you! I'll update the manual with those improvements on Friday.

On Wednesday, January 16, 2019 at 9:31:51 PM UTC+1, John Forecast wrote:

1. I've rebuilt client11 with VDE support and sucessfully run 2.11BSD networking on a Pi Zero W over wlan0. In fact everything goes over

    wlan0 since that's the only interface it has. I can provide a writeup of my configuration.

Oh! Yes, please. That has been a bit of a holy grail the last two weeks!

 The writeups are based on running on a Pi Zero W which only has a single wireless LAN interface, multiple interfaces should be possible but

 will require interface changes. Since we'll be tunnelling traffic over UDP, a second system will be needed for the remote end of the tunnel. I use

 an old RPi1 to bridge the traffic from multiple tunnels onto my ethernet. "Raspbian Stretch vde_cryptcab setup.txt" describes the overall setup

 and references "Raspbian Stretch bridge setup.txt". In these document client means the PiDP-11 system and server is whatever is going to

 be the other end of the tunnel. Once it's all setup, boot.ini will need to be changed to make use of VDE so "att xu eth0" will need to become

 "att xu vde:/tmp/vde.ctl".

2. The dos11 package is running is running a badly broken version of DOS

3. Someone was asking about IAS here. I've made a kit of IAS V3.4A with timesharing enabled.

Unless you object, I will add those to the distribution on Friday as well.

Go right ahead,

  John.

 

[Antoni Villalonga]

Hi Oscar,

Thanks for the release!

I had to report a "miss feature". In the prev version the simh
terminal (after a ctrl-e) had some features like autocomplete (ctrl-r)
and history (arrows up/down keys). In the last version it seems to be
disabled.

Regards,

On Tue, Jan 15, 2019 at 10:02 PM oscarv <vermeul...@gmail.com> wrote:
>
> Hi,
>
> The last few weeks have seen a lot of improvements to the PiDP-11 software as well as to the contents of the "software museum".
>
> I just uploaded a beta version; the download & install procedure is in the freshly minted manual: https://www3.ispnet.net/pidp11/PiDP-11%20Manual%20v0.2.odt
> It would be great if I could get some feedback from adventurous souls before dubbing this the New Release. Bug reports are very welcome, please let me know what Pi you use and what compile date simh displays when it starts up (PDP-11 simulator V4.0-0 Current REALCONS build Jan 12 2019)
>
> To upgrade,
>
> I recommend to just rename /opt/pidp11 into /opt/xidp11 and then start with a fresh pidp11 subdirectory. That way you can always revert to the old version.
> No need to rerun the install script, just do the following:
> apt-get update
> apt-get install libsdl2-dev
> apt-get install libpcap-dev
> for some additional things the new version needs.
>
> I expect that new updates will come out much more regularly from now on. If you find any bugs, please just send me an email.
>
> What has changed:
>
> decent setup for handling (re)booting into the various operating systems.
> The kludgy bootscripts/ directory is replaced by a systems/ directory, and a text file (systems/selections) now maps SR switch values to named subdirectories.
> networking enabled, very easy to do now for RSX and 211BSD. But only through Ethernet for the moment.
> Thanks to Mark Matlock, Bob Meyer and Johnny Billquist for doing the hard work!
> graphics. Play lunar lander under RT-11 to name one thing, but more is on its way.
> Thanks to Ian Schofield for doing the hard work (all the work, really) here!
> bug fix for the incidental LED flashes (Ian again)
> bug fix for the front panel display of register values (Jörg Hoppe)
> some small fixes and cleaning up
> I've received a few reports of the front panel driver crashing occasionally. Alas, not here so far - so I hope this is fixed but I feel rather unsure about that still.
>

> Thanks to many people, including-but-not-limited-to Ian Schofield, Mark Matlock, Terry Kennedy, Johnny Billquist, Bob Meyer, Angelo Papenhoff, Jörg Hoppe, Mike Hill and and - never mind, you know who you are! Much appreciated.

>
> Lastly, the manual will steadily grow into a guided tour through PDP-11 as well as Raspberry Pi land. I think that makes sense, as many things are hard to discover if you're not aware of them. I think 99% of PiDP-11 builders miss out on interesting features - including myself. Self-studying an archaic OS (such as Raspbian) is fine, but a walk-through through the highlights tells you where to look.
> Please send me any how-tos that should be included, the manual is editable on the Pi's OpenOffice as well as MS Word if you feel like it.
>
> Kind regards,
>
> Oscar.
>

> --
> 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/54fca43c-a638-4b24-b0b5-82202e7c1381%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
"You hear about the chinese godfather? He made them an offer they
couldn't understand." - The Sopranos 1x04

Antoni Villalonga i Noceras
#Bloc# ~> http://friki.cat/
#Twitter# ~> @friki

[Ian Schofield]

Dear All,

 Antoni; well spotted! There is an anomlay in Simh in relation to the use of SDL. As the SDL thread needs to be at top level to receive keyboard/mouse events etc. the keyboard history buffer is a problem. This is due to the use of libncurses via a dynamic library load and a dlsym call in read_line_p() in scp.c. if enabled, simh will cause a sigsegv when ^e is invoked. Why this should be a problem is unclear but I suspect it is due to keyboard event rehooking. I am working on this at then moment but any suggestions welcome. The current plan is to link libncurses in as normal. If you look at this code, you will see that various versions of libncurses are searched for and if the library was never installed, the history buffer is disabled.

Regards, Ian.

[Carlos Teani]

Hi Oscar

The team did a great job! I'm having too much fun with this computer!

The access to the General Registers through the Switch Registers is working, now I can switch in my programs (at least until the nice men come with the straight jacket to take me over!).

TCP/IP is working well and I'm now playing with the FTP and have a question about the list of USERs and PASSWORDs available on the RSX11 disk image.

The connection is open, however I can't log in because I do not know the passwords.

Thanks

Carlos

[Mark Matlock]

 Carlos,

     The default accounts and passwords that come with RSX11M or M+ are:

Username: SYSTEM    Password: SYSTEM

Username: USER.       Password: USER

    To add a new user account RUN ACNT and answer the questions. Remember that in the group,user UIC (e.g. [6,1]) any group 10 or less has system privileges.

You can also list the existing accounts from inside ACNT. If you get an error trying to run acnt, it might not be installed in which case you will need to INS $ACNT

   If you access RSX with FTP and try anonymous, it was configured to give you access to the files in DU1:[FTP]

Best,

Mark

[Bob Flanders]

 

HI Oscar,

I found a small problem in the manual. It seems that the link 

http://skn.noip.me/pdp11/resources/rsx/DEC-11-OMBGA-A_D_RSX-11M_Beginners_Guide_Jun77.pdf is protected.

 

I did find another copy at:

http://www.bitsavers.org/pdf/dec/pdp11/rsx11/RSX11M_V3.1_Dec77/1A_System_Reference_Information/DEC-11-OMBGA-A_D_RSX-11M_Beginners_Guide_Jun77.pdf

Best regards,

Bob 

[oscarv]

Antoni, all,

I just posted an update of the software & manual.

Manual is at https://www3.ispnet.net/pidp11/PiDP-11%20Manual%20v0.2.odt

Fixed:

- command line autocomplete (thanks once more to Ian)

- some small fry

Still to be fixed:

- Some people report occasional crashes of the front panel driver. Annoyingly, running 3 different Pi's for >200 hours, I still don't have the problem.
  So a bigger brain will be looking in to this, but it'll take a bit of time before Jörg, owner of said brain, can dig in to it.

- Booting into RT-11 will break when you do it from ssh. For now, restart pidp11.sh and it will work.

  I need to get the DISPLAY=:0 variable into the environment during boot time. Will be fixed, embarrassing.

Kind regards,

Oscar.

[Tom Lake]

On page 11 of the manual, I think you should add

sudo tar -xvf nankervis.tar.gz

to the install procedure, just for completeness.

Tom L

On Tuesday, January 15, 2019 at 4:02:27 PM UTC-5, oscarv wrote:

[Ian Schofield]

Dear Oscar,

Excellent. The display bit is an interesting point as if you RDP to the PiDP11, you may want a local display (having made sure the window isn't full screen!). With VNC there is no problem. I would merely add a note about this in the manual as I think most people will know how the window system works.

However, the fail mode is really obscure. But, a likely cause is  Raspian going into standby. I will have a look at the settings for this and drop you a line. Having said this, the classic cause is power line transients. 

Regards, Ian.

--
You received this message because you are subscribed to a topic in the Google Groups "[PiDP-11]" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-11/EfOin6Njln0/unsubscribe.
To unsubscribe from this group and all its topics, 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/cc097838-e096-4c72-8384-9bb4a68337a4%40googlegroups.com.

[David Richards]

Greetings Oscar,

The manual is very interesting and helpful, than kyou for your efforts.

I have found a small error in it however, on page 19 there is a link to the Lions commentary, the text tag is correct but the underlying link is a file on your local PC.

t’s now online at lemis.com/grog/Documentation/Lions . 

I have found some errors in the boot.ini file used with the nankervis systems files, the disk image file links still point to the old 16 directories, no directory prefix is now needed the lines may be written in this fashion  "attach rk0 ./rk0.dsk"

I do not have a PiDP11 yet though I am enjoying your systems updates, I have re-written the panelsim invocation to use the new system layout, This could be useful for others who want to used a system without a PiDP11. I amalgamated as much as I could into this single file (see attached) it takes the switch number as single argument to select the desired operating system, It should be run from the panelsim directory with the systems directory inside it. (I'll try it in /opt to match the Pidp11 shortly)

Kind regards, David.

[oscarv]

Ian,

On Tuesday, January 22, 2019 at 6:48:13 PM UTC+1, Ian Schofield wrote:

Excellent. The display bit is an interesting point as if you RDP to the PiDP11, you may want a local display (having made sure the window isn't full screen!). With VNC there is no problem. I would merely add a note about this in the manual as I think most people will know how the window system works.

I'm just testing a fix to allow VT11 graphics without restarting. But the problem just points to the truth - the install and pidp11.sh scripts are stretched up derivatives from the original PiDP-8 ones, overstretched. They need to be scrapped and replaced by a better setup. It all works fine, but it is awfully messy inside them.

However, the fail mode is really obscure. But, a likely cause is  Raspian going into standby. I will have a look at the settings for this and drop you a line. Having said this, the classic cause is power line transients. 

I too, always suspect power problems. The Pi is extremely vulnerable to them and the results are sometimes surprisingly hard to distinguish from software bugs. But - even then a recovery should be written into the server. Looks like an overload of LED updates crashes the buffer, and though a power glitch might do something nasty elsewhere, the front panel server does not have to die from it this way.

Interesting factoid from here (see section The importance of a good power supply): a new Pi 3B+ actually runs slower than the previous Pi 3 if the power supply is insufficient. I bet many people use cheap power bricks that would qualify as such.

Actually, the contents of that link are good enough to copy & paste. People have no idea...

<snip>

The importance of a good power supply

Every generation of Raspberry Pi has upped the ante in terms of power supply requirements. For the first few Pis, you could toss any little USB power adapter at it, and aside from a tiny glitch here or there, you'd never really experience difficulties. You can even see in my Raspberry Pi Power Consumption benchmarks how each generation uses more power at idle, presumably due to more and more active circuits running all the time.

In my first set of performance tests, I was using my standard 5 port USB power supply, which puts out a nominal 2.4A at 5V... but in reality usually serves up 1.8A or so. With the Pi model 2 B and Pi model 3 B, this power supply never really caused an issue, and I never experienced CPU throttling even under load. However, the Pi model 3 B+ had 2x better performance when using a dedicated 2.4A power supply.

It was an amazing difference; at first, I thought maybe there was some thermal throttling going on—I monitored the temperature with the command while true; do /opt/vc/bin/vcgencmd measure_temp && sleep 1; done, and it showed that the model 3 B spiked to 68.8°C under load, while the Pi model 3 B+ hit 54.2°C. So it doesn't look like there's any thermal throttling, and in fact the metal CPU enclosure on the model 3 B+ does a remarkably better job at thermal management than the plastic one on the 3 B.

Next I thought maybe there was some CPU frequency throttling going on. Measuring with the command watch -n 1 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq, the frequency went from idle at 600000 Hz (600 Mhz) to 1400000 Hz (1.4 Ghz). So it didn't look like there was any CPU frequency throttling either.

Finally, to get a raw performance statistic, I decided to run a barebones sysbench CPU test (specifically, sysbench --test=cpu --num-threads=4 --cpu-max-prime=2000 run) to see how things measured up:

• Pi model 3 B+: 6.9920s
• Pi model 3 B: 3.6902s

That seemed awfully suspicious; a CPU clocked at 1.4 GHz should surely be faster—not 2x slower—than almost the same CPU at 1.2 GHz!

Once I switched out the power supply, all the numbers made more sense:

• sysbench test went from 6.9920s to 3.1718s (75% faster)
• Drupal anonymous page views went from 99.18 req/s to 149.00 req/s (40% faster)
• Drupal authenticated (uncached) page views went from 9.27 to 15.25 req/s (49% faster)
• CPU temperature went up to 69.8°C under heavy load (maxed out around 54°C before).

So, as with all things Pi: If you're experiencing strange issues regarding performance or stability, make sure you have a good (and ideally dedicated) micro USB power supply.

<\snip>

Kind regards,

Oscar.

 

[Neil Higgins]

I still don’t understand why a change of binaries stopped my PiDP-11 from crashing. Does Mr Schofield include Pixie Dust with his stuff??

[Mark Matlock]

Oscar,

   On the topic of PiDP-11/70 LED freeze upps, I have been very lucky not to experience hardly any of these issues on either the beta version PiDP-11 or the later one that's been running since early fall. Both have RPi3B+ units and both run from a 2.4A wall wart sold for the RPi3B+. One thing I did on each one, because of my concern about voltage drop due to the tiny microUSB connector and that I was also using an Adafruit microUSB extender was to add a digital voltmeter on the clear acrylic back panels that I had laser cut from your design with my mods (adding the tiny voltmeter, removing the large RS-232 serial ports, etc). The voltmeters I use come from Sparkfun (PRT-14313) and cost only $1.50 which is a great deal. They read to 0.01V and I connected them to pins soldered in the prototype area. That way I should see any low voltage resulting from resistance in the USB connectors, and the GPIO connections.

  Now to my main point, normally at boot up the voltage reads about 5.20 volts and drops to ~4.99-5.01 volts on both units when the PiDP-11 is up and running in my case RSX. One day this last weekend, I saw the older PiDP-11 had frozen and only had one single LED on in the address line on maybe the mode line. When I looked at the back to see if the Pi showed any disk activity with the green led to the microSD card through the clear back panel, I was surprised to see the voltmeter reading 4.90 Volts, lower than I have ever seen it. The wireless keyboard and mouse did not produce any response on the HDMI screen which lit but static. I had no choice but to power off the Pi and I wondered if I had a bad connection somewhere, but when I powered it up I saw the 5.20V during boot uo and later as the panel lit up it dropped to the normal 4.99 Volts I see on that unit.

   So especially after reading your post on power consumption by the RPi3B+, I think this may have a hardware component to the issue as well. Others experiencing this issue may want to invest $1.50 in one of there tiny voltmeter panels. I'd also love to figure out how to easily bring the green microSD card activity light out as a pseduo disk drive activity light. I suppose that might also be possible in a Simh modification but that software engineering is above my pay grade.

Best,

Mark 

[Ian Schofield]

Dear All,

 I think the comments on this thread support the power supply problem. And, I am delighted as tracking down a critical timing problem in this software would be a nightmare! Let's see if using a good quality power supply solves the problem.... Finally, I think my chums in IT would agree. They have spent a lot of money on stabilised and maintained supplies for the servers.

Regards, Ian.

[Gerry Duprey]

Howdy,

Just to weigh in on this...

I can confirm that it's not EXCLUSIVELY a power supply problem (though I know
that could be some peoples problems). I have a very stable bench PS, meters and
scopes and have watched the rPi rails while testing.

I also use a standardized rPi PS wall-wart that puts out 3+ amps at 5.1v with
heavy gauge supply lines (when not running on my bench). They are scattered
around the house and of the 8 that run everything else in the house, none have
PS problems.

My pidp11 PS was equally stable. Absolutely no problems with the power rails
before or after the regulator. Further, running a bunch of monitor apps and
they show nothing stops working. Except the server11/front panel thing.

Since I pushed the refresh cycle to 20ms (vs 1ms), I crash far less often. The
fact that changing that changes the crashes periodicity again suggests it's not
just a PS issue (again, for me). However, I still get crashes, but on the order
of 2-4 weeks between (way better than every few days before updating the refresh
speed).

I'm absolutely NOT saying it can't be the PS - there are a literal ton of dodgy
PS's for the rPi and the super crappy micro-USB power invites use of
sub-standard power supplies/cables.

But I can say with a very, very high degree of confidence that in my testing,
with my PS on my rPi 3+, the crashes are infrequent, random and absolutely not
related to the PS.

So, just a data point ;-)

Gerry

P.S. I'm still running the original distribution of the PiPDP11, so haven't
tried the most recent

> --
> 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/cf67ae26-d4bd-4dbe-8043-2db61b0f784f%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/cf67ae26-d4bd-4dbe-8043-2db61b0f784f%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Oscar Vermeulen]

Gerry,

Indeed, not all can be attributed to bad power supplies (although I'd be curious what the impact is if you ratchet up the bench PS to 5.25V; the Pi Foundations own PS does not do that for nothing...). At any rate, we'll figure out a way to make the server more resilient.

Ian Schofield mentioned compiling the program with the -O0 compile option 'solved' his machine from crashing. You might give that a try!

I wish I could reproduce the phenomenon. I have not seen anything in 250 hours of run time across 3 machines with different Pi's inside.

Kind regards

Oscar.

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/ceff1b3c-20c0-d893-8639-db445495ce97%40gmail.com.

[Warren Young]

On Wednesday, January 23, 2019 at 12:00:35 PM UTC-7, oscarv wrote:

At any rate, we'll figure out a way to make the server more resilient.

Given a server written in C that crashes apparently randomly over long periods of time, the classic debugging technique is to enable core dumps and then use those dumped cores to debug the problem when it eventually does occur.  This technique goes back to the days when "core memory" was current technology, but it's still useful today.

In my own work, I've used that technique many times to quickly nail a bug I had no way to reproduce prior to getting a core file that showed how the system got into that state.

Most modern Linuxes disable core dumps by default. The instructions linked previously aren't overcomplicated, they're a reflection of the multiple protections against cores being enabled in the name of security and operational resilience. You have to defeat *all* of those protections to get cores to drop on disk.

Another successful technique I've often used is running the program under a memory debugger. Has no one tried running this system under Valgrind, or building it with the GCC memory sanitizer enabled? 

(Don't ask me: I haven't tried building my -11 yet. I've just been lurking here.)

[Warren Young]

One more point: while the Valgrind and -fsanitize options are best done by people who understand the C code in question, enabling cores is something anyone can do. Someone unable to make use of the core file themselves can ship the core file to someone who can, along with sufficient instructions to build an identical binary.

Ideally, you use the core dump technique on the same box that produced the executable, but with care, a "foreign" core file can be used successfully on a different machine.

[Sunnyboy010101]

I too suspect there's more to it than just poor power supply, as my system using the latest "stock" downloaded software has been running since the latest update (i.e. many days). I have one of the higher-amp power supplies supposedly designed for the Pi 3.

The problem is that if there is a software "glitch" that's causing the display shut-down, then it's both random (as far was we know at the moment) and very infrequent. This is the worst of all possible debugging scenarios, as reproducing the error can take days or weeks of running before it appears.

One thing that did trigger my memory in recent comments is the mention that compiling with "-O0" seems to help. This is a fairly huge concern to me only because "compiler optimization inroduced bugs" was was of the worst situations I've had to code through over the years. It was very common in both FORTRAN and C compilers that certain optimization levels would cause mysterious errors or even crashes and the only ultimate work-around was to use a different optimization level. Usually the worst case was when the only solution was "no optimization" at all - of course when you really wanted full optimization for speed.

Ultimately the solution may well be the optimization level for the software compile. It would be great to find an optimization that would trigger the error much more frequently, but even that might not really tell us much if it's determined to be some register optimization (assumed clear so don't clear) or loop rolled or unrolled that's the culprit. Then it really is caused by the optimization and not the written code.

At least my observation from ages-ago debugging.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/CAJAwMc2m%3DKhuRhwbCF3tqfdeJcY3iOzThrR%3D1e5VhnX51%2BtFkA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

Virus-free. www.avast.com

[Stephen Casner]

A difference in crash susceptibility when compiling with different
optimization levels does not necessarily mean that the optimizer is
producing any incorrect output to introduce the bug. It could just be
a consequence of timing differences with the different optimization
levels affecting a race condition. The bug of groups of LEDs all
flashing on was caused by a race condition, for example.

-- Steve

[Sunnyboy010101]

On 1/23/2019 3:00 PM, Stephen Casner wrote:
> A difference in crash susceptibility when compiling with different
> optimization levels does not necessarily mean that the optimizer is
> producing any incorrect output to introduce the bug. It could just be
> a consequence of timing differences with the different optimization
> levels affecting a race condition. The bug of groups of LEDs all
> flashing on was caused by a race condition, for example.
>
> -- Steve

Definitely a good point. Something that happens in software/hardware
interactions as opposed to  the scientific type stuff I was programming.
I only got into such issues years later when I got more involved in
hardware programming. I think there's a tendency to default to our
earlier experiences. :-)

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

[Warren Young]

On Wednesday, January 23, 2019 at 4:00:15 PM UTC-7, Stephen Casner wrote:

A difference in crash susceptibility when compiling with different
optimization levels does not necessarily mean that the optimizer is
producing any incorrect output to introduce the bug.  It could just be
a consequence of timing differences with the different optimization
levels affecting a race condition.  The bug of groups of LEDs all
flashing on was caused by a race condition, for example.

Race conditions are just one small slice of a much wider problem area called Undefined Behavior, a vast area of pain in C, its size largely due to the way the language is defined, which in turn comes from the almost universal applicability of the language. Whether you know it or not, a compiler generating code for ARMv7 on a Pi 3 has to care about concerns that only matter on, say, an IBM System/390 running MVS, because C has to work sensibly there, too.

That's where dynamic and static analysis tools come in. 

[Warren Young]

On Wednesday, January 23, 2019 at 2:13:26 PM UTC-7, sunnyboy010101 wrote:

...compiling with "-O0" seems to help. This is a fairly huge concern to me only because "compiler optimization inroduced bugs" was was of the worst situations I've had to code through over the years. It was very common in both FORTRAN and C compilers that certain optimization levels would cause mysterious errors or even crashes and the only ultimate work-around was to use a different optimization level.

That should be largely a historical condition. I haven't encountered a genuine compiler bug in probably 20 years. Much more common, my code was at fault by depending on undefined behavior.

C is large enough these days that only experts actually know the full range of UB.

If changing the optimization level fixes the problem, I'd take that as a sign I've got a bug, not that the compiler does.

[Johnny Billquist]

I would call that a software bug, albeit an obscure one. If the code
have timing issues like that, then the code isn't done right.

Johnny

[Ian Schofield]

Dear All,

 This has prompted a bit of debate! This is clearly an opportunity for a group effort with a strategy that will define the error(s) in the software at least as Johhny suggests. Warren has suggested enabling core dumps which is indeed the standard method of dealing with problems of this kind. I agree with the qualification that my experience of these in a multi-threaded environment has not been good. Not uncommonly, gdb indicates a corrupted stack. Nonetheless, is anyone up to create a modified version of quickmake for a suitable executable? If this is run on as many machines as possible, we may get an answer.....

Regards, Ian.

[Warren Young]

On Thursday, January 24, 2019 at 2:15:15 AM UTC-7, Ian Schofield wrote:

my experience of [core dumps] in a multi-threaded environment has not been good. Not uncommonly, gdb indicates a corrupted stack.

That's one of the reasons I like Valgrind: it stops the program right at the point where damage would occur if it let the program continue, so the stack and heap are in a more debuggable state. 

(Incidentally, if you have core dumps enabled, Valgrind will cause a "vgcore" to be dropped on error, so my prior claim that Valgrind requires a trained operator isn't entirely correct.)

Unfortunately, Valgrind has a pretty good chance of not catching this particular problem, because Valgrind operates something like a software CPU emulator, so it slows your program waaaay down. It'll probably turn this particular problem into a Heisenbug.

The GCC memory sanitizer is a better bet. It doesn't have as much performance impact, but like Valgrind, it stops the program just before the point of actual damage, not after it's done so much damage that you get a segfault, as with core dumps.

There are other sanitizers in GCC. See the docs I pointed to.

[Jörg Hoppe]

Mark,
> ...

>   Now to my main point, normally at boot up the voltage reads about
> 5.20 volts and drops to ~4.99-5.01 volts on both units when the
> PiDP-11 is up and running in my case RSX. One day this last weekend, I
> saw the older PiDP-11 had frozen and only had one single LED on in the
> address line on maybe the mode line. When I looked at the back to see
> if the Pi showed any disk activity with the green led to the microSD
> card through the clear back panel, I was surprised to see the
> voltmeter reading 4.90 Volts, lower than I have ever seen it. The
> wireless keyboard and mouse did not produce any response on the HDMI
> screen which lit but static. I had no choice but to power off the Pi
> and I wondered if I had a bad connection somewhere, but when I powered
> it up I saw the 5.20V during boot uo and later as the panel lit up it
> dropped to the normal 4.99 Volts I see on that unit.
>

> ...

Just an idea: Is power drop better if you feed-in the +5V over PiDP PCB
and the RPi expansion connector instead over the micro USB?

Joerg

[Mark Matlock]

Joerg,

   I can certainly give that a try. In my case I don't think that it was a low voltage condition that caused the problem,

but that the problem caused the RPi3B+ to start drawing more power than normal pulling the power supply's

voltage down from 4.99 to 4.90. This extra current draw occurred during the lock-up state. Also, during that state

only one LED was on and it was bright,

   This may not be helpful, but the lock up state seemed to cause a tight loop or something causing the RPi to draw extra power.

The HMDI display was active so I'm thinking I'll leave a extra terminal window open with top running continuous with the 1

hit so I see activity on all 4 processor cores. It will probably only show client11 or server11 looping pegged but maybe that

info helps a bit. At idle running RSX client11 is running about ~50% CPU and server11 is running about ~25% with two or three

cores 98% idle and the voltage never fluctuates from 4.99V.

   This unit however has only froze once in a couple weeks of solid running.

Best,

Mark

[oscarv]

All,

The crash point is not that mysterious - two of the four crash reports I've had came with the same bit of output:

Option: server11: ../../07.0_blinkenlight_api/historybuffer.c:128: historybuffer_idx2pos: Assertion `idx < _this->endpos' failed.
                                                 localhost: RPC: Unable to receive; errno = Connection refused
                               (in .//../../../07.0_blinkenlight_api/blinkenlight_api_client.c, line 296)

And some race condition looks to be the cause of it. Jörg already mentioned that he'll check in to it.

Kind regards,

Oscar

[Upi Tamminen]

About porting new version of simh to BlinkenBone, as the manual states:

> Remember: simh->BlinkenBone->PiDP-11. If you want to port a new simh into BlinkenBone, that is non-trivial. Jörg Hoppe has kept up with changes and additions into simh, but doing it yourself will require a good mastery of the diffutils.

Indeed merging can be a bit of a chore, especially since the two projects don't share the same git history. I went ahead and merged the pdp11 changes from blinkenbone into the latest release of simh. This was done by taking a fresh copy of simh, and placing changes from BlinkenBone on top of it. This way the repository and it's makefile appears just like simh upstream, and should make merging a bit easier.

Caveats:

* Unfortunately this effort will probably not be very useful to anyone except PiDP-11 users, since I skipped all the other systems.

* No idea if the panel functionality still works fine with all the new changes in simh, I only did some quick tests with stepping instructions

* While merging new changes from simh is easier with "git merge", merging changes from BlinkenBone is still manual work

* While simh git history is there, blinkenbone git history is gone

I've uploaded my merge to github (see the realcons branch):

https://github.com/desaster/simh-realcons-pdp11

[Neil Higgins]

Warren: Good to see you here, (as always) bringing us back to earth with exhortations to gather hard evidence.

All: Given that I was among the early reporters of the bug, I am sorry that I am not currently in a position to help. My PiDP-11 is wrapped in bubble wrap at the bottom of a box while our house undergoes renovations.

[James Hagerman]

Any chance the manual could be provided in an easier to manage format? ODT files don't open very gracefully on a lot of computers.

James

[Raymond Domp Frank]

What's difficult to manage about an ODT file?

If you like, open the ODT in LibreOffice (runs well on most PC's) and Export as PDF or another format. The PDF automatically contains very convenient bookmarks.

Raymond

[Will Senn]

Ooreader for iphone will open it and convert to pdf for import to ibooks, etc.

[oscarv]

It opens up OK in MS Word, I've seen OpenOffice break off the pages slightly incorrectly.

The idea is to put the document on Google Docs so others can edit it (apologies for the two people who suggested it, I haven't moved on that yet but will!).

Once it stops growing, we can make it a PDF.

Kind regards,

Oscar.

[ShadowTron Blog]

I know this is an ongoing issue but wanted to add my experience with it.

I'm seeing the issue with server11 crashing. I did a fresh download of the simh package last night so I should have the latest published versions. I believe I have a repro that somehow exposes the issue.

Note that I've ran the idled demo for several days on end without any issue.

I see the error message has previously been captured; I'm seeing the same error.

# server11: ../../07.0_blinkenlight_api/historybuffer.c:128: historybuffer_idx2pos: Assertion `idx < _this->endpos' failed.

localhost: RPC: Unable to receive; errno = Connection refused

(in .//../../../07.0_blinkenlight_api/blinkenlight_api_client.c, line 296)

For the repro the following code has lead to server11 failing to the blank front panel 3 time within 12-16 hours of running it. One time under unix7 and twice under 211BSD. I'm not sure how/if code running in a VM could cause server11 to fail but that seems to be what I'm seeing.

#include <stdio.h>

void main()

{

  long i;

  while(1)

  {

    for (i=0; i<=1000000; ++i)

    {

      printf("%10ld Hello World!\n",i);

    }

  }

}

[Oscar Vermeulen]

Hi,

The server crash bug has been fixed - see this post.

I'll add it to the next software update, but for now this will patch your setup.

Kind regards

Oscar.

--

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/251e8c5e-166f-4ad3-9798-3f2adc7bc746%40googlegroups.com.