ecu IIs

mike at BRL-TGR.ARPA mike at BRL-TGR.ARPA
Wed Jul 18 11:42:19 AEST 1984


From:      Mike Muuss <mike at BRL-TGR.ARPA>

Error threshold switches should be UP (set to 15) if your ECU--ECU
link is faster than 19.2K;  for slower links you might wish to
use a threshold of about 4.  Owning ECUs is silly if you don't use
their error correction feature, and setting the error threshold to
zero (all down) disables it.

The theory here is that it's better for your ECU's to do a retransmission
locally wherever possible, rather than stomping on the packet and
having TCP do an end-to-end retransmission across the network.
(MILNET and ARPANET trunks are only 56 Kbps;  best to conserve their
bandwidth when it's easy to do so).

As for the override switch on the ECU, the setting of this switch
really depends on two factors:  whether you are interested in
hearing about hard-retransmission errors, and whether your host
is doing RFNM counting.  If your host is doing RFNM counting,
this switch MUST be down, or your network service will
get worse, every time a RFNM from the IMP to your host is dropped.
(VAX 4.2 UNIX does do RFNM counting, I have changes which make it
selectable).  With the switch down, you will also get an

imp0:  interface reset

message (4.2 UNIX) every time you get a hard error on your ECU link.
In addition to clearing the RFNM counters, this also gives you
a record of how bad your ECU--ECU line is.  If your host is not doing
RFNM counting and does not log IMP interface resets, you might as well
leave the switch up.  (Some dumb gateways fit this description).

Best,
 -Mike

PS:  We use a 480,000 bps modem between our main gateway and our MILNET IMP,
so that no matter how noisy the line gets, we can always be sure that
the ECU's are not the limiting factor in our gateway's performance.



More information about the Comp.unix.wizards mailing list