31 Jul
2019
31 Jul
'19
10:51 p.m.
For broadcast circuits, bridges or not, doesn?t the router priority on a router?s Ethernet
circuit play a part too?
Keith
On 31 Jul 2019, at 12:08, Johnny Billquist <bqt at
softjar.se> wrote:
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.