[HECnet] Emulated XQ polling timer setting and data overrun

[Johnny Billquist]

On 2014-06-05 21:12, Paul_Koning at Dell.com wrote:

On Jun 5, 2014, at 2:46 PM, Mark Pizzolato - Info Comm <Mark at infocomm.com> wrote:

...
All of this is absolutely true, but it would seem that no one is trying to push full wire speed traffic between systems.   It would seem that given high quality signal levels on the wires in the data path (i.e. no excessive collisions due to speed/duplex mismatching), that the natural protocol on the wire (with acknowledgements, etc.) should be able to move data at the speed of the lowest component in the datapath.   That may be either the Unibus or Qbus or the PDP11's CPU.

True, provided congestion control is working.   In the days of DECnet Phase IV, congestion control was a topic of active research, rather than a well understood problem.   (Things like the TCP/IP    DEC bit    are an outcome of that work as well as a lot of other less obvious knowledge that made its way into other protocols.)   So in Phase IV, you probably don   t have effective congestion control, and scenarios with widely differing bandwidth points are likely to behave poorly.   In Phase V, that should all be much better.

I don't even know what the "DEC bit" in TCP/IP is. Never heard of it. (Feel free to educate me.)
But TCP have the slow start control, the ICMP source quench, handling of out of order packets, and I'm sure a few more tricks to better deal with this kind of situation.

...
Hmmm...Grind...Grind... I do seem have some vague recollection of an issue with some DEQNA devices not being able to handle back-to-back packets coming in from the wire.   This issue might have been behind DEC's wholesale replacement/upgrading of every DEQNA in the field, and it also may have had something to do with the DEQNA not being officially supported as a cluster device...

I   m not sure about that for QNA.   It certainly was an incorrigible device, which is why VMS dropped it, but I don   t remember back to back packets being its specific issue.

I do remember that the 3C901 had this issue, and DECnet/DOS (Pathworks) ran into big trouble with that.   There was even a proposal to throttle sending speeds across all DECnet implementations as a workaround for that design error; that proposal went down in flames very quickly indeed.   So at that point it was even more clearly understood that back to back packets at the wire end of a NIC must always be handled.

Yeah. And I do not think that it is actually back-to-back packets that is the issue.

	Johnny