With help from Mark Pizzolato, I've been looking at why RSTS (DECnet/E)
operates so slowly when it's dealing with one way transfers. This is
independent of protocol and datalink type; it shows up very clearly in NFT (any
kind of file transfer or directory listing) and also in NET (Set Host). The
symptom is that data comes across in fairly short bursts, separated by about a
second of pause.
This turns out to be an interaction between the DECnet/E queueing rules and the
very fast operation of SIMH on modern hosts. DECnet/E will queue up to some
small number of NSP segments for any given connection, set by the executor
parameter "data transmit queue max". The default value is 4 or 5, but it can
be set higher, and that helps some.
The trouble is this: if you have a one way data flow, for example NFT or FAL
doing a copy, the sending program simply fires off a sequence of send-packet
operations until it gets a "queue full" reject from the kernel. At that point
it delays, but the delay is one second since sleep operations have one second
granularity. The other end acks all that data quite promptly, but since the
emulation runs so fast, the whole transmit queue can fill up before the ack
from the other end arrives, so the queue full condition occurs, then a one
second delay, then the process starts over.
This sort of thing doesn't happen on request/response exchanges; for example
the NCP command LOOP NODE runs at top speed because traffic is going both ways.
I tried fiddling with the data queue limit to see if increasing it would help.
It seems to, but it's not sufficient. What does work is a larger queue limit
(32 looks good) combined with CPU throttling to slow things down a bit. I used
"set throttle 2000/1" (which produces a 1 ms delay every 2000 instructions,
i.e., roughly 2 MIPS processing speed which is at the high end of what real
PDP-11s can do). Those two changes combined make file transfer run smoothly
and fast.
Ideally DECnet/E should cancel the program sleep when the queue transitions
from full to not-full, but that's not part of the existing logic (at least not
unless the program explicitly asks for "link status notifications"). I could
probably add that; the question is how large a change it is -- does it exceed
what's feasible for a patch. I may still do that, but at least for now the
above should be helpful.
paul
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
