PDP-11 DROPS INPUT CHARACTERS on KL (console) and DZ telnet SIM 4.0 Beta

[WILLIAMCORCORAN]

SIM 4.0 Beta, PDP-11, UNIX v7m (2.1)

ISSUE: The console (KL) and DZ ports via telnet drop input characters during paste operation.

Note: The UNIX console (KL) and other KL ports handled paste operations flawlessly on SIMH V.3.9.

EXAMPLE on SIMH 4.0 Beta:
ls -l /sys/dev/kl.c
-rw-r--r-- 1 sys 3639 Aug 1 1981 /sys/dev/kl.c [Notice kl.c is 3639 bytes]
cat /sys/dev/kl.c [All characters in kl.c are flawlessly typed to the screen under SIMH 4.0]
cd /tmp
cat -> myNewFIle.c
[Now, select all of the text of kl.c (the entire kl.c driver source) and PASTE into console window]
ctrl-d
ls -l /tmp/myNewFIle.c
-rw-rw-r-- 1 root 275 Nov 10 05:15 /tmp/myNewFile.c [Notice: only 275 bytes]
[trumpet fail: wuh wuh wuh wuuuuuuuuuh]

Now, it is key to remember, that on SIMH V.3.9, this operation worked perfectly on the console---always. Plus, this operation worked flawlessly on many drivers.

It is worth noting, that on SIMH V.3.9, some canonical processing took place with tabs and spaces. However, the copy was perfect in that it would compile without error. Nevertheless, the paste operation was not an exact copy under SIMH 3.9, but it was close enough. Only tabs and spaces on SIMH V3.9 would be changed during a paste operation such as this.

The bottom line: Under SIMH 4.0 Beta, I am unable to complete a paste operation as nearly all characters are dropped, excepting about 275 bytes. Smaller paste operation (under the ~256 bytes seem to work fine.)

I have tried various incantations of modem control, etc with no success.

I want to be clear that the KL and DZ devices work beautifully for the most part. The output always seems fine under SIMH 4.0. But. input processing (such as pasting) no longer works like it did in Version 3.9.

Of course, all of this could be a simple misconfiguration on my part. But, until this gets reviewed by the team here, it does seem like a potential defect.

Below you will find the build information requested from the README.md file. I would like to add one point: The SIMH software is an amazing gem of software engineering. For years, I have read every vintage UNIX manual I could get my hands on. However, I was only left to imagine. SIMH has brought my imagination to life. As each day passes, the value of SIMH increases. 100 years from now, SIMH (or its progeny) will be used to demonstrate the dawn of automation. I thank each and every contributor to SIMH.

PDP-11 MACHINE V4.0-1 delta 1 Production (Local Port, native V4.0 Beta Code)
Simulator Framework Capabilities:
32b data
32b addresses
Ethernet Packet transports:PCAP:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
Asynchronous I/O support
FrontPanel API Version 1
Host Platform:
Compiler: GCC 5.2.0
Simulator Compiled: Oct 29 2015 at 22:38:50
Memory Access: Little Endian
Memory Pointer Size: 64 bits
Large File (>2GB) support
RegEx support for EXPECT commands
OS clock tick size (time taken by msleep(1)): 2ms
OS: Darwin corky 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64

    git commit id: 9ee290ac

[markpizz]

Hi William,

What you are describing seems to be that during paste operations input characters seem to be presented to the simulated system/os faster than they can be dispatched...

Some work was done of several simulators to specifically support better behavior during paste operations, but I'm not sure that the PDP11 was one of them, and I certainly am surprised that this is worse now than under v3.9.

Can you supply me with:

1. the configuration file you are running with
2. a system disk image that you are using on the simulator

You can contact me offline at: mark@infocomm.com so we can exchange details of how to get the disk image file.

Also, can you explain why your simulator's SHOW VERSION says:
"PDP-11 MACHINE V4.0-1 delta 1 Production (Local Port, native V4.0 Beta Code)"
and mine says:
"PDP-11 simulator V4.0-0 Beta"
(i.e. what have you changed??)

• Mark

[WILLIAMCORCORAN]

Hello Mark,

Thank you for your prompt reply. Sure, I will provide you with a disk image that reduces the issue to its trivial case.

I will send you the config file, too. This might take me a day to put this together.

Also, for all purposes, I am using the 4.0 Beta. I did revert and it had the same issues.

I made some local changes that were superficial.

Yes, this baby was absolutely perfect under 3.9.

Although 3.9 has some major problems that are totally resolved in 4.0 beta. For one thing, I wrote a script called “killer” that I would run with 16 DZ/login/telnet sessions open. Version 3.9 would panic in less than a hour. However, version 4.0 kicks butt! My klller script would not take down SIMH 4.0 even after 48 hours! Killer just does a lot of crazy CPU and IO processing—simultaneously. SIMH 4.0 is BRILLIANT!

I went so far as to have a dedicated server running 4.0 Beta with UNIX v7m 2.1. It so cool. It is ROCK solid. I feel like I have discovered the cure for the common cold. SIMH 4.0 just blows me away. Worse, I had no clue 4.0 even existed. I just happened upon it. The SIMH site has 3.9 frozen for eternity.

Thank you so much!

I will get what you’ve requested. I live for this stuff.

Truly,

Bill Corcoran

[Rhialto]

I noticed the same, and I patched my local copy a bit to work around
this for VH devices. I've included it below.

diff --git a/PDP11/pdp11_vh.c b/PDP11/pdp11_vh.c
index 81b1af1..e3ccd8a 100644
--- a/PDP11/pdp11_vh.c
+++ b/PDP11/pdp11_vh.c
@@ -275,6 +275,7 @@ static const int32 bitmask[4] = { 037, 077, 0177, 0377 };

 static int32    rbuf_idx[VH_MUXES]      = { 0 };/* index into vh_rbuf */
 static uint32   vh_rbuf[VH_MUXES][FIFO_SIZE]    = { { 0 } };
+static int      vh_maxchars = 20;

 /* TXQ state */

@@ -345,6 +346,8 @@ static t_stat vh_setnl (UNIT *uptr, int32 val, char *cptr, void *desc);
 static t_stat vh_set_log (UNIT *uptr, int32 val, char *cptr, void *desc);
 static t_stat vh_set_nolog (UNIT *uptr, int32 val, char *cptr, void *desc);
 static t_stat vh_show_log (FILE *st, UNIT *uptr, int32 val, void *desc);
+static t_stat vh_set_maxchars (UNIT *uptr, int32 val, char *cptr, void *desc);
+static t_stat vh_show_maxchars (FILE *st, UNIT *uptr, int32 val, void *desc);
 static t_stat vh_help (FILE *st, DEVICE *dptr, UNIT *uptr, int32 flag, const char *cptr);
 static t_stat vh_help_attach (FILE *st, DEVICE *dptr, UNIT *uptr, int32 flag, const char *cptr);
 static const char *vh_description (DEVICE *dptr);
@@ -432,6 +435,8 @@ static const MTAB vh_mod[] = {
         &vh_set_nolog, NULL, &vh_desc, "Disable logging on designated line" },
     { MTAB_XTD|MTAB_VDV|MTAB_NMO, 0, "LOG", NULL,
         NULL, &vh_show_log, &vh_desc, "Display logging for all lines" },
+    { MTAB_XTD|MTAB_VDV|MTAB_VALR, 0, "MAXCHARS", "MAXCHARS",
+        &vh_set_maxchars, &vh_show_maxchars, &vh_desc, "Max nr of chars to input at once"  },
     { 0 }
 };

@@ -766,7 +771,15 @@ static void vh_getc (   int32   vh  )

     for (i = 0; i < (uint32)VH_LINES; i++) {
         lp = &vh_parm[(vh * VH_LINES) + i];
-        while ((c = tmxr_getc_ln (lp->tmln)) != 0) {
+        /* Assume we're being called about 50 times per second.
+         * At 9600 bps, input can be at most 960 cps.
+         * So in each 1/50 second interval, there could be about 20.
+         * Clearly, this number needs to be tuned to how fast the
+         * emulated OS and its user programs can process these
+         * characters...
+         */
+        int limit = vh_maxchars;
+        while (--limit >= 0 && ((c = tmxr_getc_ln (lp->tmln)) != 0)) {
             if (c & SCPE_BREAK) {
                 fifo_put (vh, lp,
                     RBUF_FRAME_ERR | RBUF_PUTLINE (i));
@@ -1557,6 +1570,30 @@ for (i = 0; i < vh_desc.lines; i++) {
 return SCPE_OK;
 }

+/* SET MAXCHARS=n processor */
+
+static t_stat vh_set_maxchars (UNIT *uptr, int32 val, char *cptr, void *desc)
+{
+t_stat r;
+int32 ln;
+
+if (cptr == NULL)
+    return SCPE_ARG;
+ln = (int32) get_uint (cptr, 10, 999999, &r);
+fprintf(stderr, "setting vh_maxchars to %d\n", (int)ln);
+if (r != SCPE_OK || ln < 1)
+    return SCPE_ARG;
+vh_maxchars = ln;
+return SCPE_OK;
+}
+
+/* SHOW MAXCHARS processor */
+
+static t_stat vh_show_maxchars (FILE *st, UNIT *uptr, int32 val, void *desc)
+{
+    fprintf(st, "maxchars=%d", vh_maxchars);
+}
+
 static t_stat vh_help (FILE *st, DEVICE *dptr, UNIT *uptr, int32 flag, const char *cptr)
 {
 const char *devtype = (UNIBUS) ? "DH11" : "DHQ11";

[markpizz]

The simulator code for these devices is delivering the incoming data (from the paste) to the simulator as soon as the OS driver has removed the previously arrived data from the simulated hardware. The OS got the data. It will be useful to know how this worked in simh v3.9 and why it is a problem now. Since this problem appears to be a general one across all mux devices a general solution is probably that doesn't burden each device simulation with dealing with this would make sense.

I still want to see the failure case.

Thanks.

• Mark

[WILLIAMCORCORAN]

Hello Mark,

I created the trivial failure case. I have a pristine v7m disk with a kernel configured with the hp driver, a KL console, and sixteen (16) working DZ devices.
I also have a stripped down config file that allows booting of the v7m 2.1 disk.

The failure mode as described is fully reproducible.

Compressed and combined, the files are about 10 Megabytes.

Can you tell me how I should deliver this to you? Do you have an FTP site?

Thank you.

Bill Corcoran

[markpizz]

Hi Bill,

Shared on Google Drive is easiest. You can post here or preferably contact me directly at mark@infocomm.com.

• Mark

[WILLIAMCORCORAN]

Hello Mark,

I was able to eliminate some fluff and get the entire thing below 6MB. Most mailers can handle that today.
If your mailer refuses to accept it, then I will use the Google Drive option for sure.

Thank you so much.

Whenever you’re ready, here is what to do:

1. I understand I don’t even need to tell you amy of these steps.
2. However, I put together a README file that spells out the steps.
3. Maybe it will be useful for something, if not, just ignore it.

Please copy the attached file 246.tgz to a folder on as OS/X system.
Yes, you can use any system supported by SIMH and everything should work.
However, I am using OS/X in my case, so if you have OS/X it may be worth using.

The OS/X system has a tar command that knows how to gzip and gunzip.

If your tar does not understand how to deal with compression, then please use gunzip first.

Once you have copied down 246.tgz into a clean folder:

1. mkdir 246test
2. cd 246test
3. tar xf ../246.tgz
4. cd bin
5. copy your pdp-11 4.0 binary into ./bin as ./pdp11-4000
   6, ./run

From there, you can boot v7m 2.1 UNIX:

1. b rp0
2. boot
3. hp(0,0)unix

Next, you will be in single user mode, check the filesystem to ensure all is well:

1. fsck -t /tmp/scratch
2. Ctrl-d [to start multiuser]

If all looks good, you are ready to perform the KL console test:

1. Login to UNIX via the SIMH console as root.
2. Cat /sys/dev/kl.c
3. Select/Copy all of the text by scrolling your window to the start of the stdout of the cat command.
4. cd /tmp
5. cat -> myTestFile.c
6. Ctrl-d
7. ls -l myTestFile.c /sys/dev/kl.c
8. Compare the sizes as they should be close.
9. The defect always shows the myTestFile.c as something less than 300 bytes.

Next, repeat the test with DZ line test:

1. telnet localhost 8883
2. Follow steps 1..9 above.

Note: There is a detailed README file (too much detail) located in the TLD and doc folders.

Now, let’s hope you see the defect.
If you see the defect, then patching SIMH should have the file sizes similar

CAUTION: As you know, do not try to end up with the exact same sizes of the file.

THIS SHOULD NOT BE YOUR GOAL. Why? Canonical processing will invariably process
the data sufficiently so that you and up with the same binary after compiling the .c file transferred
via a paste operation. But, the canonical processing will convert spaces and tabs in various ways producing a dissimilar target. So, the files do not have
to be precise copies for this operation to be successful. Tabs and spaces may not be converted 1 to 1.

Now, one last thing. I have heard you talk about the timing operations as the root source. But, should not the flow control kick in
and prevent the loss of data in the stream? I am sure your answer is NO, but I thought I would run it by you.

Finally, if you need the full UNIX v7m 2.1 distribution and not the parred down version I supplied, just let me know and I will make it so!

Thank you again.

Truly,

Bill Corcoran

[markpizz]

Hi Bill,

Thanks for the detail.

Meanwhile, I did not receive any email directly and I can't find any suggestion in my mailserver log data that any such attempt was actually tried.

Please either send directly or simpler yet make this available via Google Drive.

Thanks.

• Mark

[markpizz]

While I'm waiting for Bill's test case I've started to look closer at the details raised here.
The console and DZ implementation models are completely different from the VH case. The VH device is aware of the concept of flow control (XON/XOFF) in the serial data stream and it has a reasonably large FIFO which data is delivered through. Prior to Olaf's patch mentioned above, no changes have been made to this device to accommodate excessive data arrival rates. The native hardware paradigm of sending XON and XOFF across the serial line to manage flow control has been precisely emulated and these characters are inserted into the TCP data stream which the telnet session uses. The problem is that data can arrive faster or in much larger chunks than the fifo can tolerate AND the tcp telnet session is using binary mode telnet and XON and XOFF don't have particular meaning when sent towards the telnet client. The right solution here is to let TCP's flow control come into play to regulate the arriving data. That is simply achieved by not reading data from the tmxr layer when there is a desire to slow things down. Olaf's patch puts a user exposed knob to regulate this, however that may not be necessary at all.

Can you test this patch against the existing github pdp11_vh.c module:

--- a/PDP11/pdp11_vh.c
+++ b/PDP11/pdp11_vh.c
@@ -765,17 +765,17 @@ static void vh_getc (   int32   vh  )
     TMLX    *lp;

     for (i = 0; i < (uint32)VH_LINES; i++) {
+        if (rbuf_idx[vh] >= (FIFO_ALARM-1)) /* close to fifo capacity? */
+            continue;                       /* don't bother checking for data */
         lp = &vh_parm[(vh * VH_LINES) + i];
         while ((c = tmxr_getc_ln (lp->tmln)) != 0) {
             if (c & SCPE_BREAK) {
                 fifo_put (vh, lp,
                     RBUF_FRAME_ERR | RBUF_PUTLINE (i));
-                /* BUG: check for overflow above */
             } else {
                 c &= bitmask[(lp->lpr >> LPR_V_CHAR_LGTH) &
                     LPR_M_CHAR_LGTH];
                 fifo_put (vh, lp, RBUF_PUTLINE (i) | c);
-                /* BUG: check for overflow above */
             }
         }
     }

With this in place, when data arrives at excessive rates, it won;t get lost in the pdp11_vh device simulation, and things should then be in a similar place to the DZ and console cases (where data has been handed off to the OS, but the driver is probably over-running the type ahead buffer). I don't see any overruns on my test VAX simulator (running VMS) with or without this patch even when I past a 40KB file into a telnet session.

Olaf can you test this in the PDP11 environment that inspired your patch?

Thanks.

• Mark

[markpizz]

I got the link. I sent you a message to gmail account you sent me the message from explaining that you need to make that file publicly visible.

Clearly, if you're getting the github messages at some email address, you didn't use that account to provide the Google Drive link, or you would have gotten my direct response.

Thanks.

• Mark

[markpizz]

I now have the file.

Thanks.

[markpizz]

Hi Bill,

I have confirmed that I can reproduce the problem observed on the current simulator and the fact that it does not appear on the v3.9 simulator.

I have not yet had the chance to analyze what is really happening. I'll let you know.

Thanks.

• Mark

[WILLIAMCORCORAN]

Hello Mark,

Thank you so much. I know all of this works on an indefinite timeline. But, please lean on me for any testing that you need. I can at least help test Version 6/7 and 7m BTL UNIX.

The work that you and the team are doing here is brilliant. The recognition of SIMH, the value of SIMH, is itself historic.

You are bringing to life and maintaining our Founding Father’s technical achievements. SIMH is akin to the FPS video games. Not only does SIMH preserve, portray and project historic operating systems in three dimensions, SIMH adds the critical temporal dimension that could only previously be provided by having a working hardware—as time goes on that will become harder and harder.

As time goes on, it is reasonably foreseeable that some kind of SIMH will be developed for all of the current modern platforms that SIMH currently runs on as they too become ancient. The beauty, of course, is that 30 years from now, we may be running a SIMH for today's OS/X. Well, if true, we can run the PDP11 SIMH underneath the OS/X SIMH to be able to boot Version 7 UNIX. It simply won’t be necessary to keep maintaining SIMH codebase for the PDP-11 on future modern OS platforms. You see, 30 years from now, we will all be running a SIMH of the PDP11 under a SIMH of OS/X, for example.

That’s why the work you and the team here is doing is so important. Once the SIMH hits its perfection stroke, the code you write today may be frozen and usable for the next century—if not for(;;). There simply won’t be a need to hammer out a native PDP-11 port of SIMH on whatever OS is king 30 years from now.

Finally, the improvements of SIMH from V.3.6, V.3.9, and V.4.0 are large. This thing is getting better and better. It is of mind-blowing importance. I cannot stress that enough. Thank you and the team for all of your sweat and tears. You have all made a fantastic contribution to the preservation of history.

Truly,

Bill Corcoran

[markpizz]

Hi Bill,

I'm looking over details here and I don't see success with your simple test when running on a simh v3.9 PDP11 when using a DZ device. I see the same failing behavior on the lastest code and on the V3.9 code. Can you confirm that you have good or bad behavior when using a DZ telnet connection?

Thanks.

• Mark

[WILLIAMCORCORAN]

Hello Mark,

Yes, if you read my initial post, I almost get this across. But, near the end of my initial post, I muddied it a bit.

Let me clear it up.

1. The KL (console) and DZ drivers drop characters as described under SIMH 4.0. Beta.
2. The KL (console) driver (and even other KL tty devices) work just fine (as described) in SIMH 3.9.
3. The DZ Driver drops characters in SIMH 3.9 and 4.0 Beta
4. Thus, the heading is factually correct: Re: [simh] PDP-11 DROPS INPUT CHARACTERS on KL (console) and DZ telnet SIM 4.0 Beta (PDP-11 DROPS INPUT CHARACTERS on KL (console) and DZ telnet SIM 4.0 Beta #246).
5. However, DZ does not work in 3.9 or 4.0.
6. The KL devices on 3.9 are fine.

I am sorry I failed to make this clear.

Truly,

Bill Corcoran

[Rhialto]

On Sun 15 Nov 2015 at 11:38:30 -0800, Mark Pizzolato wrote:

Olaf can you test this in the PDP11 environment that inspired your patch?

I did a quick test but alas it doesn't seem to help.

It may be a bit tricky for others to replicate the situation so I'm
still looking for a simpler version. My original problem was Kermit-11
running on RSX-11M-PLUS 4.6 (the latest). Kermit is supposed to be able
to receive data packets of at least 200 characters (or more), but in
practice there was character loss if they were larger than about 65.
Kermit does set RSX's line buffer to the required length, so maybe it is
RSX which drops characters somehow after fetching them from VH's fifo.
Kermit-11 does not do the "sliding window" extension, so after sending
the 200 characters, no more would be sent until the receiver
acknowledges they were received correctly. So we're not seeing (I think)
a too large overall speed, but just a too big burst.

I would say to first concentrate on Bill Corcoran's issue, and see if my
problem remains if that is fixed. At that time, if needed, I could make
a disk image and config file available privately, with instructions, if
that is still useful.

-Olaf.

___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl -- 'this bath is too hot.'

[markpizz]

Bill and Olaf,

Can you test to see if the current github code addresses the issues you observed?

Thanks

• Mark

[markpizz]

Can someone test the DCI device as well?

[WILLIAMCORCORAN]

Hello Team,

It is lunchtime on the East Coast. I will confirm the new code works with KL, DZ and DC.

Truly,

Bill Corcoran

[WILLIAMCORCORAN]

Hello Team:

This confirms that the KL and DZ drivers appear to be working perfectly.

I copied a 50,000 bytes (1600 line C program) via paste.

Yes, canonical processing changes spaces and tabs, but both KL and DZ drivers' pasted code compiled flawlessly producing the identical objects.

Next, I will test DC later and report back.

[Rhialto]

On Thu 19 Nov 2015 at 08:57:39 -0800, Mark Pizzolato wrote:

Can you test to see if the current github code addresses the issues
you observed?

This is indeed a rate limiter! :-)

Of course I had some interesting effects with it. I basically got the
rate limited to approx. 50 cps (500 bps), no matter what I set the
terminal speed to.

Another emulator already complained that NetBSD's sleep functions are
too imprecise for its liking. I think that is what's the cause here too.
Basically they sleep longer than asked for (which is perfectly allowed
by POSIX).

In sim_tmxr.c:tmxr_getc_ln() you effectively get only one character
every time it is called. Even if the sleep time, between calls, was
longer than intended. If that sleep time was, say 5 character arrival
times, then it still sets lp->rxlasttime to "now". That prevents the
immediately next call from returning any characters. Only after the next
(too long again) sleep it will produce another one.

Ok, so I thought to fix that by increasing lp->rxlasttime not to "now"
but by lp->rxdelta (a smaller increment). The idea being that the next
call will still find that rxlasttime + the delta is not yet in the
future, and more characters are returned.

On the other hand, rxlasttime needs to "catch up" to now sometimes,
otherwise the above mechanism will still allow bursts if they occur
after some quiet time. So rxlasttime would be set to "now" if there
was no character available (a quiet time).

But rxdelta is in microseconds and rxlasttime is in milliseconds. So
I have to do the divide-by-1000. Which at speeds from 19200 up leads to
truncation to zero. That in turn makes the rate limiting ineffective.

The solution to that seemed to be to scale the time keeping from
milliseconds to microseconds. That saves some divisions by 1000 as well
(but introduces some multiplications by 1000, which should be cheaper).
A disadvantage is that this probably needs an uint64_t.

The resulting version works well for 19200 (RSX doesn't allow speeds
higher than 19200), but somehow it fails for 300 and lower. The failure
mode is that it accepts character "bursts" only once in many many
seconds.

Then I realised that the above adjustments of rxlasttime also happen
when the rxdelta time has not passed yet. Moving that into the
conditional fixed this last issue.

With that, I present the below diff.

I would further change rxlasttime to rxnexttime, in analogy with
snd->next_time, and to make the time checks simpler, but I refrained
from including that.

diff --git a/sim_console.c b/sim_console.c
index bcba790..023f2db 100644
--- a/sim_console.c
+++ b/sim_console.c
@@ -1922,8 +1922,10 @@ t_stat c;
 if (sim_send_poll_data (&sim_con_send, &c))                 /* injected input characters available? */
     return c;
 if (!sim_rem_master_mode) {
+    uint64_t now_usec;
+
     if ((sim_con_ldsc.rxbps) &&                             /* rate limiting && */
-        ((sim_con_ldsc.rxlasttime + (sim_con_ldsc.rxdelta + 500)/1000) > sim_os_msec ())) /* too soon? */
+        ((sim_con_ldsc.rxlasttime + sim_con_ldsc.rxdelta) > (now_usec = sim_os_msec () * 1000L))) /* too soon? */
         return SCPE_OK;                                     /* not yet */
     c = sim_os_poll_kbd ();                                 /* get character */
     if (c == SCPE_STOP) {                                   /* ^E */
@@ -1932,8 +1934,12 @@ if (!sim_rem_master_mode) {
         }
     if ((sim_con_tmxr.master == 0) &&                       /* not Telnet? */
         (sim_con_ldsc.serport == 0)) {                      /* and not serial? */
-        if (c && sim_con_ldsc.rxbps)                        /* got something && rate limiting? */
-            sim_con_ldsc.rxlasttime = sim_os_msec ();       /* save last input time */
+        if (sim_con_ldsc.rxbps) {                           /* got something && rate limiting? */
+            if (c)
+                sim_con_ldsc.rxlasttime += sim_con_ldsc.rxdelta;  /* avoid rounding issues */
+            else
+                sim_con_ldsc.rxlasttime = now_usec;         /* save last input time */
+            }
         return c;                                           /* in-window */
         }
     if (!sim_con_ldsc.conn) {                               /* no telnet or serial connection? */
diff --git a/sim_tmxr.c b/sim_tmxr.c
index 68208b7..8a8d7e5 100644
--- a/sim_tmxr.c
+++ b/sim_tmxr.c
@@ -1544,11 +1544,12 @@ int32 tmxr_getc_ln (TMLN *lp)
 int32 j; 
 t_stat val = 0;
 uint32 tmp;
+uint64_t now_usec;

 tmxr_debug_trace_line (lp, "tmxr_getc_ln()");
 if ((lp->conn && lp->rcve) &&                           /* conn & enb & */
     ((!lp->rxbps) ||                                    /* (!rate limited | enough time passed)? */
-     ((lp->rxlasttime + (lp->rxdelta+500)/1000) <= sim_os_msec ()))) {
+     (((lp->rxlasttime + lp->rxdelta) <= (now_usec = sim_os_msec () * 1000L))))) {
     if (!sim_send_poll_data (&lp->send, &val)) {        /* injected input characters available? */
         j = lp->rxbpi - lp->rxbpr;                      /* # input chrs */
         if (j) {                                        /* any? */
@@ -1561,11 +1562,15 @@ if ((lp->conn && lp->rcve) &&                           /* conn & enb & */
             lp->rxbpr = lp->rxbpr + 1;                  /* adv pointer */
             }
         }
+    if (lp->rxbps) {                              /* if a char was recv'd, */
+        if (val)                                  /* add only its delta time, */
+            lp->rxlasttime += lp->rxdelta;        /* in case we get here less */
+        else                                      /* often than we hope. */
+            lp->rxlasttime = now_usec;
+        }
     }                                                   /* end if conn */
 if (lp->rxbpi == lp->rxbpr)                             /* empty? zero ptrs */
     lp->rxbpi = lp->rxbpr = 0;
-if (val && lp->rxbps)
-    lp->rxlasttime = sim_os_msec ();
 tmxr_debug_return(lp, val);
 return val;
 }
@@ -1886,7 +1891,7 @@ return;

 int32 tmxr_rqln (TMLN *lp)
 {
-if ((lp->rxbps && (lp->rxlasttime + (lp->rxdelta + 500)/1000) > sim_os_msec ()))
+if ((lp->rxbps && (lp->rxlasttime + lp->rxdelta) > sim_os_msec () * 1000L))
     return 0;
 return (lp->rxbpi - lp->rxbpr + ((lp->rxbpi < lp->rxbpr)? lp->rxbsz: 0));
 }
diff --git a/sim_tmxr.h b/sim_tmxr.h
index 8d24994..5106862 100644
--- a/sim_tmxr.h
+++ b/sim_tmxr.h
@@ -167,8 +167,8 @@ struct tmln {
     uint32              rxpbsize;                       /* rcv packet buffer size */
     uint32              rxpboffset;                     /* rcv packet buffer offset */
     uint32              rxbps;                          /* rcv bps speed (0 - unlimited) */
-    uint32              rxdelta;                        /* rcv inter character min time (ms) */
-    uint32              rxlasttime;                     /* time last received character was read */
+    uint32              rxdelta;                        /* rcv inter character min time (microsec) */
+    uint64_t            rxlasttime;                     /* time last received character (microsec) */
     uint8               *txpb;                          /* xmt packet buffer */
     uint32              txpbsize;                       /* xmt packet buffer size */
     uint32              txppsize;                       /* xmt packet packet size */

[markpizz]

I'll look at this tonight (or tomorrow).

The 500bps is somewhat close to the speed that happened on console input with v3.9...

Meanwhile, you do know that you can build a kernel which has HZ set to 1000....

[Rhialto]

Ah, but I don't use Linux :) I don't think NetBSD has such a HZ setting.

[WILLIAMCORCORAN]

TESTING REPORT:

Hello Team,

I encountered an unusual anomaly that may be related to the #246 patch:

1. After stressing the system with a large number of paste operations, and idle disabled:
2. All sessions became dreadfully slow. Typing a key might take 1000 to 1500 milliseconds to echo. This happened on the console and several DZ telnet sessions. The simulated system was idle for 2 hours before encountering this issue.
3. I was able to clear this condition and restore full operational performance by taking the following steps:

a. On the console, type Ctrl-E to gain access to the SIMH Console.
b. At the simh> prompt, type "cont "
c. Everything returned to normal on all sessions.

Normally, I would refrain from reporting a defect like this until I had time to understand and reproduce it on demand. But, I am reporting this now to plant the seed just in case something strikes you whilst you're doing a code review.

I RESPECTFULLY ASK THAT NO FURTHER ACTION BE TAKEN ON THIS ISSUE UNTIL I UNDERSTAND IT BETTER.

I am creating additional tests and I am testing DC. I will report my findings.

Nevertheless, so far, the paste operations have been absolutely perfect with nary a missing byte.

Truly,

Bill Corcoran

[markpizz]

Linux already has a small clock tick. NetBSD can build a kernel with HZ set to 1000 and it will be well behaved. I don't recall exactly how that is specified.

[markpizz]

Bill,

When the strange timing behavior happens, and you hit ^E to get to the sim> prompt, save the output of SHOW CLOCK before you do anything else.

Thanks.

Mark

[WILLIAMCORCORAN]

Hi Mark,

I am not sure why is says 88833. I always use port 8883.

Something must have happened when I pasted it into the web page.

Next, I was using the github website and directly entering my message to you.

When I hit tab and space, the dialog lost focus and the space bar hit the “ok” button.

Sometimes, I subconsciously enter vi escape sequences when I am typing into web forms and such.

So, my message was truncated prematurely. But, if you actually go to the website on github, you will see that I wrote a long
message about port speed findings.

Let me know if you want me to email it to you or if you can grab if from the website—if you have interest in reading it.

Truly,

Bill Corcoran

[markpizz]

Hi Bill,

I now see the complete message. I didn't earlier. FYI: I almost always use the github web interface to deal with the issue system.

As for your point of limiting output speed, that is a completely separate issue and, I expect not something that users are concerned about. Faster is always better as long as no data is lost. It was the data loss problem which caused me to provide the most natural speed limiting design as a solution. Olaf's (Rhialto's) original approach merely attempted to limit input to groups of a certain number of characters. This was potentially workable for the VH device, but wasn't a natural solution for other MUX device simulators and the console.

As for the full speed output behavior causing the simulated system not to have any cycles left to do anything else, well, that might be partly the problem of the OS running in the simulated system...

Back to the Faster is always better. It is this concept which is still driving Olaf and me to get full speed input behavior at 19200bps and possibly 38400bps since these were speeds that the original PDP11 and VAX systems actually could handle (in theory, but they might be quite saturated processing interrupts while doing it depending on the actual model of the hardware).

Have you gotten to test the DCI device yet? I don't have any personal experience with an OS that has driver support for this device so I haven't tested any of the changed code.

Mark

[WILLIAMCORCORAN]

Hello Mark,

Understood. I just wanted to let you know my findings. There are plenty of ways to add blocking if this should ever cause problems.
I am pretty sure that the DCI devices actually work at the set speeds. I will confirm when I test it.

Now, turning to the DZ device, I read an early AUUG article (If you can call it that) where the complainant was upset that his real DZ device prevented large numbers of users because his DZ device generated constant interrupts on the CPU.

So, as a simulator designer, do you build in the bad too? You don’t need to answer that—it’s rhetorical.

Yes, I will get this DCI tested today. I have been distracted wth other project issue now that my paste is working!

Truly,

Bill Corcoran

[Rhialto]

On Mon 23 Nov 2015 at 17:58:57 -0800, Mark Pizzolato wrote:

+msec = (((uint32) cur.tv_sec) * 1000) + (((uint32) cur.tv_usec + 500) / 1000);

I did a bunch of tests with this and without, and on the HZ=100 system
and on HZ=1000 with cpu idle and noidle.

Starting from the situation with HZ=100 and without the above +500,
there are 2 dimensions to change: towards including the +500, and
towards HZ=1000. Each of those is a (very slight) improvement, and so is
again the combination. That is true both for 9600 bps and 19200 bps,
even though in all cases 19200 keeps going mysteriously slowly.

When testing HZ=1000 with "cpu idle", this definitely makes a big impact
on cpu usage! It has to stabilize for a minute to get there, but it
almost sinks to zero when RSX is idle too.

It has a weird effect on the observed speeds though. Over the time of
transmitting my test file, the speed kept varying both down and up, but
it trended down and when the file was done it was somewhere around
450-485 cps. I would estimate such a margin of error that there even
didn't really seem a difference between 9600 and 19200 bps, although the
latter seemed to vary a bit more wildly, if my impressions were correct.
Differences between with and without the +500 seem rather insignificant
here.

To be honest, I didn't really expect any change from including the +500,
since it just seems to shift the clock a bit forward. The difference is
quite small (like from 760 cps to 787 cps, which may well be mostly
within the margin of error).

So summarizing, the +500 has a small positive effect, and doesn't seem
to hurt.

-Olaf.

___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl -- 'this bath is too hot.'

[WILLIAMCORCORAN]

Hello Mark, This entry confirms that the DCI device is working perfectly as regards to input flow control and paste. First, I used the awesome git command you gave me to load the latest master. Then, I mak[ed] a pdp11. I booted a previously built image of DEC's cleaned up version 7 UNIX: v7m 2.1 I created 16 DCI devices in the UNIX kernel (character major 3) as mkconf input "16dc." I built a PDP11/70 (*separated instruction and data) kernel. Next, I enabled init serving up some gettys via the ttys file. I also created an appropriate series of entries in the dev makefile for easy recreation. As a final affirmation and confirmation that I am using an appropriately configured DCI device, opening a telnet session on the assigned port says: Connected to the PDP-11 simulator DCI device, line 0. Next, I take a large c program, after eliminating all spaces and tabs, and cat it to standard out. Next, I select the text using the modern host's OS and then copy to the clipboard. Next, I access the PDP-11 OS and issue this command: cat - > /tmp/test.dat Now, we paste the contents of the clipboard and hit ctrl-d. Next, we compare the source and target with sum and diff: source and target the same. Finally, the DCI hangup works absolutely beautifully: stty 0 This is music to my ears: The line immediately drops taking the shell with it and the modern host OS's telnet detects the line hangup and exits with a return code of "1". This is a basic security test, lest someone telnet into some poor soul's retired, but active session. Truly, Bill Corcoran (*) Fred Canter explains that v7m UNIX was designed to run on much of DEC's PDP Series systems. Some smaller systems required an overlay text kernel used on non-separated instruction and data space processors. Understanding this distinction is important during the initial setup, configuration, software and kernel regeneration. A simple SIMH setting for the CPU type must be aligned with the kernel type.

[markpizz]

Hi Bill,

Now, turning to the DZ device, I read an early AUUG article (If you can
call it that) where the complainant was upset that his real DZ device
prevented large numbers of users because his DZ device generated
constant interrupts on the CPU.

The point of the article is that the DZ and DL and DC) devices all generate
an interrupt to the CPU for each character going in OR out. So, the
processing load is significant for high speed and continuous use.

Alternatively the VH device is capable of DMA output. This means that
the a whole buffer of output data can be sent and the CPU will only be
interrupted when the the whole transfer is complete. Input characters
still usually generate one interrupt per arriving character. The VH device
has a 200ish character input FIFO so a relatively large chunk of
characters can arrive while the host CPU is busy while the DZ device
only has a 16 character buffer for data arriving on all lines.

So, as a simulator designer, do you build in the bad too?

The simulations of these devices must act how the software expects
them to so, the same interrupt characteristics are provided by each
device simulation that the software is expecting. On the other hand,
the buffering is in no way limited to the original hardware limits and
we can leverage the flow control that TCP provides to push data all
the way back to the telnet client without data loss.

Mark

[markpizz]

Bill,

This entry confirms that the DCI device is working perfectly as regards to input flow control and paste.

This is great news.

Thanks.

Mark

[markpizz]

Olaf and Bill,

We're down to the input speed inconsistencies of arriving data when the line speed is set above 9600.

I'm going to think about how to understand this over the next few days.

Mark

[WILLIAMCORCORAN]

Hello Mark,

This is fantastic. Please let me know if you think I can help you test anything.

Also, someday, I look forward to debating the reasons for limiting simulated serial device speeds to their real world counterparts.
(The main reason is that even a single simulated serial device has the potential capability to saturate a single host CPU. Thus, all protection logic and timing control could be placed under stress). The cascading effects of such saturation could undermine even the highest quality timing logic.
Anyway, this is a discussion for a rainy day.

Truly,

Bill Corcoran

[markpizz]

Olaf,

The approach you started down attempting to manage delays more precisely than the 1ms clock available with sim_os_msec() was indeed the right approach.

I think that all the MUX devices we've been looking at now have reasonably consistent input rates for all supported speeds the original hardware supported.

Please give the latest github code a try and let me know if you agree or disagree.

Thanks.

Mark

[Rhialto]

Hi Mark,

this works great! Thanks! 19200 bps now indeed works at a proper speed,
and other speeds too.

I tested 19200 on both my machines (HZ=100 "cpu noidle" and HZ=1000 "cpu
idle"; didn't test the other combinations again). The case with "cpu
idle" also had a much more constant speed than before. The effective
speeds are certainly in a very reasonable range; maybe only tests on
real hardware would show how close exactly to reality it would be, but
I'm sure it is close enough.

It's a pity that RSX doesn't let me set a higher speed than 19200, but
I'm sure that 38400 would work properly now too.

Thanks!

-Olaf.

___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl -- 'this bath is too hot.'

[markpizz]

Hi Olaf,

It's a pity that RSX doesn't let me set a higher speed than 19200, but
I'm sure that 38400 would work properly now too.

Well, I was discussing the new input speed limit behaviors with the
developer of the HP2100 simulator and he pointed out that we should
also allow other arbitrary speeds since the simulated CPUs often run at
least one and possibly two orders of magnitude faster than the original
hardware. So I'm looking at providing a mechanism to specify an
optional speed factor which will be applied to the programmatically set
speed. Using this paradigm you'd could set the factor to 2 and the RSX
would really see 19200 data arriving at 38400.

Mark

[markpizz]

The latest code provides a way to specify a multiplier factor for the
programmatic input speeds as well as the devices with static input speeds:

sim> attach DL port,speed=19200*4

will get you a port which will deliver input to the simulator at the designated
speed of 19200 times 4 or 76800bps.

The multiplier factor defaults to 1, and can be specified as large as 32.

The devices which have programmable speeds (DZ and VH) can specify in
initial speed and factor at attach time and the factor will persist across
programmatic changes to the port speed.

One more change is still coming... The input speed limits which work here
are currently implemented to work fine for input on a single line at a time,
but will produce erratic results if data is arriving on more than one port at
or around the same time. This problem will be fixed and data arriving over
independent telnet sessions to the same MUX will be properly passed to
be correctly behaved for each line's speed (and speed factor).

[WILLIAMCORCORAN]

Hello Mark,

This is great! Three things:

1. My gcc 5.2 on OS X compiles SIMH without a single compiler warning.
2. Just to confirm, this new speed factor control only applies to input speed and has no affect on output speed correct?
3. Is there a facility for us users to donate a few $ to the SIMH project to help you out?

Truly,

Bill Corcoran

[markpizz]

Hi Bill,

1. The goal is always to have clean (warning or error free) compiles. Please let me know if you ever see otherwise.
2. Speed factor and limits are absolutely only on input data. Output speed is delivered at the rate it is generated and will only be held back if the receiving end of the connection can't digest it. In any case, since the flow control is being done at the TCP level, it isn't part of the data stream, and no output data should ever be lost.
3. No, but thanks for the thought.

By the way, the latest code now should correctly rate limit incoming traffic on multiple lines concurrently. I'm pretty sure I didn't break any of what was already working. I have not rigorously tested this though. If you can at least confirm the basics and if it looks OK for you, please close this issue.

Thanks.

Mark

[WILLIAMCORCORAN]

Hello Mark,

[RED ALERT!]

[ UNIX v7m 2.1 HANGS AFTER TELNET]

My initial testing on the latest master:

Using the stripped down UNIX v7m that I previously gave to you:

1. Install the latest sim binary and update the run command; Or,
2. [with the latest binary]:

./pdp11 xrun40.conf

Next:

b rp0 [enter]
boot [enter]
hp(0,0)unix [enter]

[UNIX boots fine]

[Please run FSCK]
fsck -y -t /tmp/fs.scratch [enter]

[Now: hit Ctrl-d to go to multi user]

Ctrl-D [all is well so far]

[login as root on the console]

root [enter]

All is good!

[Now, telnet localhost 8883]

[login is root]

root [enter]

BAM! THE ENTER SYSTEM FREEZES!

See below for Version info!

Truly,

Bill Corcoran

PDP-11 simulator V4.0-0 Beta

Simulator Framework Capabilities:

32b data

32b addresses

Ethernet Packet transports:PCAP:NAT:UDP

Idle/Throttling support is available

Virtual Hard Disk (VHD) support

Asynchronous I/O support

FrontPanel API Version 1

Host Platform:

Compiler: GCC 5.2.0

Simulator Compiled: Nov 28 2015 at 19:09:13

Memory Access: Little Endian

Memory Pointer Size: 64 bits

Large File (>2GB) support

RegEx support for EXPECT commands

OS clock resolution: 1ms

Time taken by msleep(1): 2ms

OS: Darwin corky 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64

    git commit id: 0938d31e

[WILLIAMCORCORAN]

Hello Mark,

Hello Mark,

I was distracted by another issue…

Let me clarify my report:

I cut in the latest SIMH master on my production box,
All was well. Until, I tried to login to a DZ port via telnet.

As soon as the network connection (telnet) was established, the console session and the telnet DZ session hung.
Here are some corrections to my previous email:

. . .

[login as root on the console]

root [enter — no password needed]

All is good!

[Now, open a modern host’s telnet session: and "telnet localhost 8883"]

[login as root, again no password required on this test distribution.]

root [enter]

BAM! THE TELNET DZ SESSION AND THE CONSOLE SESSION SYSTEM FREEZES!
NOTE: I can confirm that the DZ telnet session and the console sessions hang.
I don’t yet know what the underlying v7m 2.1 host OS is actually doing, but the CONSOLE and the DZ Telnet are hung.
NOTE: CTRL-E works fine—even during the hang. CONT does nothing, QUIT exits properly.

See below for Version info!

Truly,

Bill Corcoran

PDP-11 simulator V4.0-0 Beta
Simulator Framework Capabilities:
32b data
32b addresses
Ethernet Packet transports:PCAP:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
Asynchronous I/O support
FrontPanel API Version 1
Host Platform:
Compiler: GCC 5.2.0
Simulator Compiled: Nov 28 2015 at 19:09:13
Memory Access: Little Endian
Memory Pointer Size: 64 bits
Large File (>2GB) support
RegEx support for EXPECT commands
OS clock resolution: 1ms
Time taken by msleep(1): 2ms
OS: Darwin corky 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64

    git commit id: 0938d31e

[markpizz]

Hmmm...

Did you select a speed with the ATTACH command?

If not, was a speed set programmatically?

If you can ^E to get to a sim> prompt, please send the output of SHOW MUX

Thanks.

[WILLIAMCORCORAN]

Mark,

Re: pdp11 UNIX v7m hang after telnet

1. See SHOW MUX below.
2. See xrun40.conf below
3. I made no explicit call to SPEED.

Truly,

Bill Corcoran

Multiplexer device: DZ, lines=16, ModemControl=enabled,

attached to 8883, 1 current connection, sessions=1

Line: 0, Speed=9600 bps

Connection from IP address 127.0.0.1

Connection [127.0.0.1]:8883->[127.0.0.1]:60351

Connected 00:00:15

Modem Bits: DTR RTS DCD CTS DSR

Telnet protocol

input (on) queued/total = 1/16

output (on) queued/total = 0/11

bytes in buffer = 11

Line: 1, Speed=300 bps

Line disconnected

Modem Bits: DTR RTS DSR

Line: 2, Speed=300 bps

Line disconnected

Modem Bits: DTR RTS DSR

Line: 3, Speed=300 bps

Line disconnected

Modem Bits: DTR RTS DSR

Line: 4, Speed=300 bps

Line disconnected

Modem Bits: DTR RTS DSR

Line: 5, Speed=300 bps

Line disconnected

Modem Bits: DTR RTS DSR

Line: 6, Speed=300 bps

Line disconnected

Modem Bits: DTR RTS DSR

Line: 7, Speed=300 bps

Line disconnected

Modem Bits: DTR RTS DSR

Line: 8, Speed=300 bps

Line disconnected

Modem Bits: DTR RTS DSR

Line: 9, Speed=300 bps

Line disconnected

Modem Bits: DTR RTS DSR

Line: 10, Speed=300 bps

Line disconnected

Modem Bits: DTR RTS DSR

Line: 11, Speed=300 bps

Line disconnected

Modem Bits: DTR RTS DSR

Line: 12, Speed=300 bps

Line disconnected

Modem Bits: DTR RTS DSR

Line: 13, Speed=300 bps

Line disconnected

Modem Bits: DTR RTS DSR

Line: 14, Speed=300 bps

Line disconnected

Modem Bits: DTR RTS DSR

Line: 15, Speed=300 bps

Line disconnected

Modem Bits: DTR RTS DSR

SET cpu 11/70
SET cpu 2048k
SET tto 7b
SET pclk enable
SET noidle

SET DZ enable
SET DZ lines=16
SET DZ 7b
ATTACH -am DZ 8883

SET PTP DISABLED
SET CR DISABLED
SET PTR DISABLED

SET TM DISABLED
SET RK DISABLED
SET RL DISABLED
SET HK DISABLED
SET RX DISABLED
SET RQ DISABLED
SET TQ DISABLED

SET rp0 rp06
ATTACH rp0 ../dev/volume00.hp
ATTACH lpt ../lpd/printer.txt

SET tm locked
SET tm enabled
SET tm0 CAPAC=0
ATTACH tm0 ../rmt/userReel.tm

[Rhialto]

For me, I'm happy to report that the VH device works fine with multiplier. (git commit id: 0938d31) Speed 19200 * 2 definitively goes faster than plain 19200 (alhough we seem to get diminishing returns at higher speeds, probably due to the way I'm measuring). I wonder if the multiplier can be changed while a telnet connection is in progress; I tried to issue a new "attach vh speed=19200*4" while I was logged in, but did not measure an effect.

[markpizz]

Bill,

Sorry about the non functional DZ device. I thought I'd tested each device before committing the last changes. Clearly I missed the DZ. It was the odd case due to it using the tmxr input queue as the device 'silo'.

Olaf,

The SHOW MUX command will show the current line state information. If it indicates a speed factor, then that will indeed be used. A bare speed=value specifier without also indicating a listening port doesn't change anything on the MUX configuration and it doesn't report an error. You should be able to enter the same attach command you originally used only specifying a different speed value and the results should be effective.

Mark

[WILLIAMCORCORAN]

Hello Mark,

Please, never apologize for these things. I am just so happy to see that SIMH is constantly being improved.

Let me know whenever you're ready for me to test. I have a pre-defect 4.0 that's working just fine so this defect is not hurting me in the least.

Finally, I have delved into 32v. I am struggling with an alignment issue with 32v process accounting and ps commands.

Is there a SIMH/32v expert around herethat has an interest in these things? At this point, I think I an completely convinced it's more of an issue with 32v and not SIMH. I am going to instrument the 32v kernel to see where the issue might be rooted. I am no expert in these things, so I am very limited in what I can do.

Truly,

Bill Corcoran

[markpizz]

Let me know whenever you're ready for me to test.

It is ready. Please test.

Is there a SIMH/32v expert around herethat has an interest in these things?
At this point, I think I an completely convinced it's more of an issue with 32v
and not SIMH.

If the unmodified code ran/runs on real hardware then I would certainly believe
that the problem is a simh one and I'll be interested in fixing it. As before,
providing the details of how to reproduce the problem will probably make finding
a solution possible and maybe even easy. :-)

Otherwise if you are just poking around with that OS and tripping over
something you need help with then you might want to ask questions on the simh
and probably other domain specific mailing lists.

Mark

[WILLIAMCORCORAN]

Mark,

I will test PDP11 and VAX11/780 and now. I will report my findings.

As far as 32v, do you want me to create an issue in GitHub? This way you can review it and decide if it's worth pursuing.

Or, as an alternative, I can write up the 32v issues and send them to your private email you gave me. Then you can tell me if I should open a SIMH issue re 32v.

Truly,

Bill Corcoran

[WILLIAMCORCORAN]

Mark,

This email confirms that SIMH PDP11(UNIX v7m 2.1) and VAX780(32V) experienced no system hangs in connecting to the DZ port (over telnet) on the latest SIMH.
Moreover, I ran through our standard paste test on both the PDP11 and VAX780. Both targets, after removing all canonical differences, matched the sources perfectly via sum and diff.

As a final verification of this testing, I kindly ask that you confirm the “SHOW VERSIONs” below (for PDP11 and VAX780) matches your expectations as the “latest SIMH port.”

Thank you for all of your hard effort and promptness here!

Truly,

Bill Corcoran

SHOW VERSION FOR PDP11
PDP-11 simulator V4.0-0 Beta
Simulator Framework Capabilities:
32b data
32b addresses
Ethernet Packet transports:PCAP:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
Asynchronous I/O support
FrontPanel API Version 1
Host Platform:
Compiler: GCC 5.2.0
Simulator Compiled: Nov 29 2015 at 14:52:36
Memory Access: Little Endian
Memory Pointer Size: 64 bits
Large File (>2GB) support
RegEx support for EXPECT
OS clock resolution: 1ms
Time taken by msleep(1): 2ms
OS: Darwin PDP-11-70.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64

    git commit id: fc001cad

SHOW VERSION FOR VAX780
VAX 11/780 simulator V4.0-0 Beta
Simulator Framework Capabilities:
64b data
64b addresses
Ethernet Packet transports:PCAP:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
Asynchronous I/O support
FrontPanel API Version 1
Host Platform:
Compiler: GCC 5.2.0
Simulator Compiled: Nov 29 2015 at 15:14:02
Memory Access: Little Endian
Memory Pointer Size: 64 bits
Large File (>2GB) support
RegEx support for EXPECT commands
OS clock resolution: 1ms
Time taken by msleep(1): 2ms
OS: Darwin corky 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64

    git commit id: fc001cad

[markpizz]

That is indeed the latest commit.

Please send an email about your 32v concerns and close this issue.

Thanks.