RSX getting slow

[Paulo Rebordão]

I run my PiDP-11 exclusively on RSX-11 as it's the DEC OS that I found more appealing to me.

Lately, it became slower and slower to respond. Running a single terminal session, it takes about 3 seconds for the editor to open a 200 line text file.

In the beginning, it was remarkably faster.

My PiDP runs on a Pi 3+ but I don't think it has anything to do with the processor or network as any native Debian session runs pretty fast.

What could it be ? Maybe some setting in the SIMH config ?

Thanks

[Johnny Billquist]

Probably something around simh, yes. But exactly what I wouldn't know.
Try restarting simh, and see if things get better again?

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 visit https://groups.google.com/d/msgid/
> pidp-11/1ebf52e4-a1d4-47f5-8870-a44f9435d8a1n%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/1ebf52e4-a1d4-47f5-8870-
> a44f9435d8a1n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Paulo Rebordão]

I tried that and it stayed the same.

For now, I removed throttling and it's much better. It was set at 50%

[Todd Goodman]

From past experience, I'd check dmesg for Pi OS disk errors (especially if you're running a micro SD card.)

Todd

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/f498a002-bf5f-4ab3-bbed-af026f650762n%40googlegroups.com.

[Johnny Billquist]

Good point! SD card performance can definitely be an issue.

Throttling is also kindof affecting things in weird ways, but I wouldn't
expect a significant difference in performance over time for that one.
Same story about throttling of I/O that simh does on terminals.

Johnny

>> <http://40googlegroups.com>
>> > <https://groups.google.com/d/msgid/pidp-11/1ebf52e4-a1d4-47f5-8870-
>> > a44f9435d8a1n%40googlegroups.com?
>> utm_medium=email&utm_source=footer <http://40googlegroups.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.
>> To view this discussion visit https://groups.google.com/d/msgid/
>> pidp-11/f498a002-bf5f-4ab3-bbed-af026f650762n%40googlegroups.com

>> <https://groups.google.com/d/msgid/pidp-11/f498a002-bf5f-4ab3-bbed-
>> af026f650762n%40googlegroups.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 visit https://groups.google.com/d/msgid/

> pidp-11/216b53c6-5ea7-4bc8-b36a-45c9bae76ce0%40gmail.com <https://
> groups.google.com/d/msgid/pidp-11/216b53c6-5ea7-4bc8-
> b36a-45c9bae76ce0%40gmail.com?utm_medium=email&utm_source=footer>.

[Clem Cole]

Sorry - I accidentally didn't hit reply all (servers me right for using the iPhone). 

Sent from a handheld expect more typos than usual

---------- Forwarded message ---------
From: Clem Cole <cl...@ccc.com>
Date: Wed, Mar 18, 2026 at 9:31 AM
Subject: Re: [PiDP-11] RSX getting slow
To: Paulo Rebordão <pjreb...@gmail.com>

If you believe SIMH was configured properly to start [i.e. enough memory, reasonable cpu model], I would suspect the underlying Linux host before I would suspect SIMH. You should check the error logs, and particularly look for issues in the disk I/O system if you are using a micro-SSD card [particularly if its generic and not designed for a heavy write load].

You can easily eliminate RSX (or any hosted OS) being the issue by using scp(1) or similar to copy the boot.ini file, the virtual disk image and like from the systems/XXX directory on the RPi to your local Mac, winders, or Linux box.  Then you can fire up a copy of the current OpenSIMH binary for your PC and see what happens. Note OpenSIMH will give you warning about the REALCONS statements in boot.ini.  Those warnings are harmless and OpenSIMH just warns, but ignores them. But you can comment them out first if you want, as otherwise the boot.ini between the two versions are the same.  If you try that,I suspect you will find RSX will runs just fine; so you know the issue is in the RPi host. 

Sent from a handheld expect more typos than usual

--
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 visit https://groups.google.com/d/msgid/pidp-11/1ebf52e4-a1d4-47f5-8870-a44f9435d8a1n%40googlegroups.com.

[Paulo Rebordão]

What would be the appropriate SD cards to buy ?

What logos should I look for ?

Paulo Rebordão

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/oiPIwkG1oKQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/baa304e4-2487-4c01-8e99-1a16c0ca297b%40softjar.se.

[Clem Cole]

These may be behind pay walls but look here: https://reviews.chicagotribune.com/camera/accessories/best-sd-memory-cards and http://www.nytimes.com/wirecutter/reviews/best-microsd-card/

I personally have a number of Samsung and SanDisk and have worked well for me.  Just becareful, if you order from overseas there are a number of that are counterfits/forgeries.  I got a bunch that were being advertised as Lexar but they were not.

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/CA%2BgrvcorPyq7tJpcX5Mm1Yy3Twbc-VzCPWmu68jEczDiaYH01w%40mail.gmail.com.

[Peter Ekstrom]

Have you looked at the Linux-level on your Pi to see if it is swapping? That can greatly affect performance if it is at a high rate.

It can also shorten the life of your sdcard. Have you tried rebooting the Pi and, if so, did that help for a while?

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/CAC20D2PZMvES1%3DoK96-2Q2%2BzF%2BhvsESUZf6COWzg9RYZvOvMxg%40mail.gmail.com.

[terri-...@glaver.org]

On Wednesday, March 18, 2026 at 6:46:58 AM UTC-4 pjreb...@gmail.com wrote:

My PiDP runs on a Pi 3+ but I don't think it has anything to do with the processor or network as any native Debian session runs pretty fast.

What could it be ? Maybe some setting in the SIMH config ?

Your RSX install (or any PDP-11 OS) is doing repeated writes to a small area of the SD card. Most SD cards don't do wear leveling (with the exception of specialized cards like the ones used for continuous video recording). And video recording uses most of the card, not just a small area that's an emulated PDP-11 hard drive.

I've had SD cards that were plenty fast in the beginning fail the bare minimum Pi SD card speed test after a few years, or even fail outright.

On my systems I've switched to Raspberry Pi 5 boards which support an NVMe SSD, but you need a Pi 5 for that. The Raspberry Pi folks also offer a USB flash drive designed for write-intensive applications: https://www.raspberrypi.com/news/raspberry-pi-flash-drive-available-now-from-30-a-high-quality-essential-accessory which might help.

There's another issue you can run into that can clobber performance - on a real PDP-11, there was only a finite amount of memory dedicated to buffering data to / from disk. So when a PDP-11 OS said "This is a directory write, flush all buffers to disk" there was maybe 64KB of data at most that needed to be written before the OS was told "All done, back to work". On a PiDP-11, you have a Pi with a minimum of 1GB RAM (256 times the maximum RAM on a PDP-11) or up to 16GB RAM (4096 times the maximum), plus maybe 32MB of cache on your SD/USB/NVMe card. The Raspberry Pi OS doesn't know that the cached data should be flushed to disk until one of those synchronous writes comes through, at which point the PDP-11 OS stalls waiting for a lot of cached data to be flushed to storage. Remember, the PDP-11 OS is expecting maybe 64KB needing to go to disk, not megabytes or gigabytes. This is particularly pathological if you're emulating a VAX, since BACKUP sends a synchronous write to update each source file's backup date (unless you use /NORECORD) and at least in some versions, whenever it finishes a redundancy group.

[Steven A. Falco]

I have found SanDisk Ultra uSD cards to be reliable in my RPi units; I have four RPi boards that have been in continuous use for years without problems.

I can't imagine that any reputable manufacturer omits wear leveling. It is just too basic a feature to leave it out. Of course counterfeit uSD cards are likely to be junk, so you should always buy from a reputable seller. In the US, I trust B&H to sell me genuine parts.

For more information, please see this SanDisk OEM document from 2010: https://www.alliedelec.com/m/d/04db416b291011446889dbd6129e2644.pdf

Section 1.5.4 states: "Wear leveling is an intrinsic part of the erase pooling functionality of cards in the SanDisk microSD Card Product Family using NAND memory."

Steve

> --
> 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 visit https://groups.google.com/d/msgid/pidp-11/40e5b8b6-6c1b-4898-99b6-469b98182c8fn%40googlegroups.com <https://groups.google.com/d/msgid/pidp-11/40e5b8b6-6c1b-4898-99b6-469b98182c8fn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Clem Cole]

below 

On Wed, Mar 18, 2026 at 3:52 PM terri-...@glaver.org <terri-...@glaver.org> wrote:

The Raspberry Pi folks also offer a USB flash drive designed for write-intensive applications: https://www.raspberrypi.com/news/raspberry-pi-flash-drive-available-now-from-30-a-high-quality-essential-accessory which might help.

This is a great point.  The big thing that the RPi-branded flash drive supports, which many others (consumer/light use oriented), such as the SanDisk Ultra Luxe series, do not, is SSDs' TRIM function used to "trim" away invalid data blocks that are no longer in use (or for that matter, SSD's SMART health monitor feature).  The key thing here is that most consumer drives do not support either of these features. TRIM is a feature that allows the OS to inform the drive which data blocks are no longer in use, drastically reducing what the disk folks call "write amplification" [see https://en.wikipedia.org/wiki/Write_amplification].  This is a primary cause of visible flash "aging" issues, particularly when the flash is used for OS logs and swap files — i.e., an SSD will degrade faster when used in that manner. 

That said, many of the earlier Linux distributions for the RPi in particular did not enable TRIM support by default [the new releases for the RPi may, but I have not checked].  See this https://www.jeffgeerling.com/blog/2020/enabling-trim-on-external-ssd-on-raspberry-pi/ for more details.

Also if you have the an SSD the supports S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology) features to check/track the SSD health, you traditionally needed to install the Linux smartmontools on the RPi using   sudo apt install smartmontools, then sudo smartctl -a /dev/sdMUMBLE to get access to health reports, wear leveling, and temperature data.   There is a reasonable blog with more details at: https://writerforlinux.wixsite.com/website/post/self-monitoring-analysis-and-reporting-technology-smartmontools-for-linux

[Clem Cole]

BTW: Just be clear, Steve mentioned wear leveling.  They are different from TRIM and have distinct features that serve different purposes for an SSD, though they work together to maintain the drive's health.  Wear leveling is entirely internal to the SSD and ensures that write and erase cycles are evenly distributed across all physical memory cells.  The goal is to prevent any single cell from failing prematurely, and, if supported by the manufacturer, it is always active; i.e., it is not "enabled" or "disabled" by the user.  If supported by the device, TRIM is a command sent by the OS to the SSD, to tell the drive which data blocks are no longer in use so the drive can clear/reclaim them efficiently [think a "garbage collector" for the disk itself].  This has to be enabled, and the OS needs to send the commands to the drive [see: https://opensource.com/article/20/2/trim-solid-state-storage-linux ]

[Paulo Rebordão]

I'm going to give the SanDisk cards a try.

Paulo Rebordão

On Wed, Mar 18, 2026 at 9:10 PM Clem Cole <cl...@ccc.com> wrote:

BTW: Just be clear, Steve mentioned wear leveling.  They are different from TRIM and have distinct features that serve different purposes for an SSD, though they work together to maintain the drive's health.  Wear leveling is entirely internal to the SSD and ensures that write and erase cycles are evenly distributed across all physical memory cells.  The goal is to prevent any single cell from failing prematurely, and, if supported by the manufacturer, it is always active; i.e., it is not "enabled" or "disabled" by the user.  If supported by the device, TRIM is a command sent by the OS to the SSD, to tell the drive which data blocks are no longer in use so the drive can clear/reclaim them efficiently [think a "garbage collector" for the disk itself].  This has to be enabled, and the OS needs to send the commands to the drive [see: https://opensource.com/article/20/2/trim-solid-state-storage-linux ]

--

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/oiPIwkG1oKQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-11+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/CAC20D2OPibk_DttwRor-iVK4vubiKg7A9fQnyu6WkxqfG7J%3Dtw%40mail.gmail.com.

[Steven A. Falco]

I recommend getting larger uSD cards than you might really need. For example, as long as the price isn't too high, I would choose a 256 GB card instead of a 32 GB card.

The reason is that larger uSD cards tend to have more "erase blocks", and that can help with wear leveling.

Steve

On 3/18/26 05:29 PM, Paulo Rebordão wrote:
> I'm going to give the SanDisk cards a try.
>
> Paulo Rebordão
>
>
>

> On Wed, Mar 18, 2026 at 9:10 PM Clem Cole <cl...@ccc.com <mailto:cl...@ccc.com>> wrote:
>
> BTW: Just be clear, Steve mentioned wear leveling.  They are different from TRIM and have distinct features that serve different purposes for an SSD, though they work together to maintain the drive's health.  Wear leveling is entirely internal to the SSD and ensures that write and erase cycles are evenly distributed across all physical memory cells.  The goal is to prevent any single cell from failing prematurely, and, if supported by the manufacturer, it is always active; i.e., it is not "enabled" or "disabled" by the user.  If supported by the device, TRIM is a command sent by the OS**to the SSD, to tell the drive which data blocks are no longer in use so the drive can clear/reclaim them efficiently [think a "garbage collector" for the disk itself].  This has to be enabled, and the OS needs to send the commands to the drive [see: https://opensource.com/article/20/2/trim-solid-state-storage-linux <https://opensource.com/article/20/2/trim-solid-state-storage-linux> ]

>
> --
> 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/oiPIwkG1oKQ/unsubscribe <https://groups.google.com/d/topic/pidp-11/oiPIwkG1oKQ/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to pidp-11+u...@googlegroups.com <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pidp-11/CAC20D2OPibk_DttwRor-iVK4vubiKg7A9fQnyu6WkxqfG7J%3Dtw%40mail.gmail.com <https://groups.google.com/d/msgid/pidp-11/CAC20D2OPibk_DttwRor-iVK4vubiKg7A9fQnyu6WkxqfG7J%3Dtw%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 visit https://groups.google.com/d/msgid/pidp-11/CA%2BgrvcqMFYCgneUn3Os9K8WG%2B7qeC_qXtt%2BmoovC_e-LEVX7Qg%40mail.gmail.com <https://groups.google.com/d/msgid/pidp-11/CA%2BgrvcqMFYCgneUn3Os9K8WG%2B7qeC_qXtt%2BmoovC_e-LEVX7Qg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Steven A. Falco]

Forgot to include a link to justify my recommendation. While this article is about SSDs, it applies to uSD cards too, as they are both using NAND memory internally: https://www.adata.com/us/quikTips/33/

Steve

[Warner Losh]

On Thu, Mar 19, 2026 at 8:04 AM Steven A. Falco <steve...@gmail.com> wrote:

I recommend getting larger uSD cards than you might really need.  For example, as long as the price isn't too high, I would choose a 256 GB card instead of a 32 GB card.

The reason is that larger uSD cards tend to have more "erase blocks", and that can help with wear leveling.

A more complete explanation is that if you only populate part of the drive, then the pool of erase blocks that are empty will be large (overprovisioned blocks + free space) which allows better wear.

If you aren't writing more than a few percent of the drive every day, it likely doesn't matter a lot.  For SD cards you rarely have redundancy in the NAND (like in NVMe drives) so a single chip failure in the SD card will still take out the drive.

Warner

 

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/2a9fda56-1fe2-4fcc-9196-9db864958214%40gmail.com.