[Simh] Pasting into the console

[Rhialto]

On Fri 27 Mar 2015 at 04:42:53 -0700, Mark Pizzolato - Info Comm wrote:
> Once I made this change, the user's pasting problem went away.  I just
> added the same logic to the PDP11 TTI's device.
> 
> However, it seems that since you logged data delivered through
> tti_rd() and all data was logged, the data loss you were seeing wasn't
> here, AND increasing the TTI WAIT time helping suggests that the data
> loss is happening in the OS's TTY driver input buffer.

Indeed, that seems the only possible explanation.
I'm not sure though why the OS is so keen on reading all bytes from the
hardware, even when its own internal input buffer is already full.
But it seems to be that way.

I tried your change, and for me it didn't make a difference (which was
to be expected).

> I have no idea how to influence the size of the type ahead buffer used
> by RSX or any other operating system. :-(

Kermit sets it larger, up to 200. But even that doesn't seem to work for
all cases (see below).

> You might want to give the latest code a try and see if it helps,
> otherwise the increased TTI WAIT time seems to be the best
> accommodation.

I made an experiment with throttling the VH device at the place where
the data from telnet gets moved into VH's fifo. I appended the diff
below, for reference. The results were "interesting".

Assuming vh_getc() gets called about 50 times per second, I throttled
there to deliver a maximum of 20 characters to each serial line, but I
made the value settable.

For pasting when just running a command line, this didn't help. I can
paste around 65 characters, and the rest gets dropped. I asked a friend
running Linux (I run NetBSD) to try the same and she had the same
result. So this likely isn't due to some subtle timing effects in simh
itself.

But if I reduced the throttle to 1 char/poll, pasting 80 characters
started to work. Both on the command line, but also in EDT for instance,
where it is quite convenient if you can just paste a couple of lines
from the outside.

Kermitting in this mode also worked with large packets (uploading), but
as to be expected, the speed was less than 50 cps.

But for Kermit I could crank the throttle up to about 60 chars/poll,
resulting in Kermit reporting an effective cps of around about 1690 on
my (binary) test file.  That is much more in line with my expectations.
But Kermit sets input processing to be as little as possible, which
could also have some influence on buffering behaviour, possibly.

> - Mark

diff --git a/PDP11/pdp11_vh.c b/PDP11/pdp11_vh.c
index cf8a9d1..5893b55 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";

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl    -- 'this bath is too hot.'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150402/cb58e14c/attachment.sig>