30 Jul
2019
30 Jul
'19
9:39 a.m.
On 2019-07-30 02:46, Paul Koning wrote:
I know. But then you have Murphy. Packets can be lost at more levels
than the link as well.
The delay factor is in units of 1/16th (except in PyDECnet where you just give the float
value). So 32 means 32/16 or 2.0 which is the default given in the spec.
Ah. Silly unit in this context, but I guess it makes some sort of sense.
Nice computerized fraction, except that the timers in DECnet/RSX are
actually in 0.1s resolution.
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.
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 29, 2019, at 8:38 PM, Johnny Billquist
<bqt at softjar.se> wrote:
On 2019-07-30 01:49, Paul Koning wrote:
It makes a lot of sense to add a little extra, or else you into a silly race condition
with a single lost or corrupted packet. Will the next one manage to come in before or
after the listen timer expires... With a few extra seconds, you create a window making it
much more reliable...
True, but as I said, one PtP links there isn't supposed to be packet loss. The x2 is
there to handle delays caused by packet drops recovered at the data link layer. ...
That's the phase IV definition. The rule is just a simple integer multiple of
the hello timer at the other end. There is no "plus jiffy" in the spec, but
using a larger than specified listen timer (within reason) is not a problem. For Ethernet, occasional packet drops are expected;
the theory is that 2 in a row are quite unlikely.
Yes. Which makes total sense. But the 3x hello plus some small amount
makes it resilient against that too. You would have to loose 3 packets
in a row for the adjacency to be considered lost.
...
Delay factor is the multiplier applies to the estimate to get the ACK timeout It's a
number with a fraction for some reason. The default is 2, which is a good number if round
trip delays are pretty consistent. If they vary significantly, you might want a larger
value to reduce the number of retransmits that occur when an ACK is only delayed. But of
course, the larger this value, the longer it takes to do a retransmit that's actually
needed because of real packet loss.
John, as well as your comments, jogged my memory a little, and I obviously was confusing
the retransmission timeouts with the hello and listen timers here.
Funny thing, though. In RSX, the delay weight is 2, and delay factor is 32. Assuming
that's with a fraction, it would imply 3.2. So defaults are somewhat the other way
around, in RSX at least.