31 Jul
2019
31 Jul
'19
1:08 p.m.
On 2019-07-30 15:07, Paul Koning wrote:
Bugs. The code was written in a way that there is a race condition in
there that can hit if things happens fast enough. More specifically the
reception of data assuming there is a little time to do some processing
before the next packet arrives. Which is probably always true if you
have two real PDP-11 systems. The transmitter essentially cannot get the
next packet out fast enough. However, with a simulated PDP-11, this do
happen. It's all in the user level application, if my analysis is
correct. But the code is rather complicated in its design, so it will
take some work to straighten it out.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Jul 30, 2019, at 3:39 AM, Johnny Billquist
<bqt at softjar.se> wrote:
...
Oh well. It works reasonably well anyhow. With the exception of a couple of bugs DEC
never saw because they never ran as fast PDP-11s as exist today. People should not try and
use FAL between a really fast and a really slow RSX system over ethernet. A transfer of a
large file will take hours. I should try and fix that bug at some point.
Bugs? Or congestion issues causing lots of retransmission? There are congestion control
improvements that were developed shortly after the Phase IV specs were finalized; some of
these are in Phase IV-plus. And much of that work made its way into TCP.
Unfortunately it appears that the Phase IV-Plus specs have not been preserved.