On Thursday, March 26, 2015 at 4:59 PM, Rhialto wrote:
> A while ago when I was struggling^Wplaying with installing RSX on simh-
> pdp11, I noticed that pasting bits of text into the console didn't really
> work.
> Which was quite annoying since now I had to re-type all those csr and vector
> numbers by hand.
>
> When trying a bit more systematically, I found that in pretty much most
> cases, only 1 in every 2 pasted characters was echoed.
>
> With some added logging I discovered that all characters were however read
> out properly on the "inside" of TTI, in tti_rd() in pdp11_stddev.c.
> Presumably by the standalone BRU system that I used for testing.
>
> However, there I noticed a polling time-out of tti_unit.wait. On a whim, I
> tried to increase that ("examine tti state" showed a value of 100) ("deposit
> tti
> time 200"). And suddenly, pasting worked just fine. (150 didn't work).
>
> I'm not exactly sure why this helps, since seemingly all characters arrived
> fine
> through the TTI input buffer, but I'm happy to use it.
>
> I already noticed there are differences in time functions between Linux and
> NetBSD (which I use as host). For instance, simh refuses to allow the cpu idle
> settings, based on some timing test it does. I suppose that somehow this
> plays a role here too, somehow.
>
> Maybe something similar causes the VH lines to drop characters after about
> 60 or so. That is the maximum packet size that works for Kermit when
> receiving. I will look again at that later.
These issues may indeed be related, and increasing the TTI WAIT time will help
to mitigate it.
Someone once observed that pasting into the VAX simulator console didn't work
well and, generally easily lost data. At the time, I looked into that and
observed that the logic which reads the input data (in tti_svc) would always
read data without regard to whether the prior input data had actually been
digested by the simulated system yet. I changed this logic to only read new
input if the prior character had been already digested by the simulated system
OR if 500ms had elapsed since the last input character was read (this timeout
allows a simulation to be interrupted with ^E when a simulated system is in a
tight loop not processing interrupts).
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.
On the VAX simulator (running VMS), the console input no longer has issues when
pasting single lines of input, but when pasting relatively large amounts of
data, the data can still be delivered to the OS faster than the user
application can read it from the OS's type ahead buffer. When this happens,
chunks of data are lost (not single characters). SYSGEN on VMS can be used to
increase the size of the driver's type ahead buffer from the default of 78 to
much bigger values (5000+) and this problem can be significantly mitigated and
serial communication programs (Kermit, UUCP, etc.) can be well behaved and not
loose data.
I have no idea how to influence the size of the type ahead buffer used by RSX
or any other operating system. :-(
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.
- Mark
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
