28 Jul
2019
28 Jul
'19
11:47 p.m.
On 2019-07-28 22:37, John Forecast wrote:
I seem to remember also reading something about a relationship to the
executor delay weight and delay factor, but I might be mixing up several
things here, and I'm too lazy to actually go and try to find the
information. :-)
However, a couple of observations under RSX:
hello timer=15 on ethernet: listen timer=56.
hello timer=10 on ethernet: listen timer=40
hello timer=300 on ddcmp: listen timer=608
So, from that short sample, it would seem that a 3x for ethernet, and 2x
for ddcmp is the basis, but then there is a little bit more added, which
is not totally clear how it is worked out.
Johnny
On Jul 28, 2019, at 4:03 PM, John Forecast
<john at forecast.name> wrote:
I missed out one important part, xT3MULT are defined as architectural constants so
you can?t change their value, T3MULT = 2 and BCT3MULT = 3. On Jul 28, 2019, at 12:00 PM, Johnny Billquist
<bqt at softjar.se> wrote:
I should correct myself. The exact formula for how the listen timer is set, based on the
remote hello timer, is a bit more complex. I remember that I saw it described somewhere,
but cannot remember the details right now.
So my "two times hello plus some jiffy" is rather incorrect in fact. It turns
out to that for some values in the end, but it varies because of other parameters as
well.
It?s defined in the routing spec where it discusses routing parameters (section
4.1 of the 2.0.0 spec). it?s a simple multiplier of the other end?s hello timer, (T3MULT
for point-to-point circuits and BCT3MULT for broadcast circuits) so the listener timer
(T4) will be set to ?hello timer * xT3MULT? depending of the circuit type. For
point-to-point circuits, any incoming traffic will reset the listener timer.
John.
--
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
John.
But the basic principle is correct. The listen
timer is based on the hello timer, and is used to determine if a circuit is down. And the
hello timer is the interval at which hello packets are sent on the circuit.
And changing the hello timer causes less traffic, and longer time before a circuit down
is detected (unless some other mechanism allows detection of a circuit down earlier).
Johnny
On 2019-07-28 17:52, Johnny Billquist wrote:
The hello timer is essentially how long between
the node sends out the hello messages on a circuit. This in turn, is used to detect when a
circuit goes down.
The listen timer is on a per node basis for adjacent nodes, and is set to two times the
hello time, plus a few seconds. So the detection of a circuit going down is when the
listen time expires.
You cannot directly set the listen timer, but you can choose your own hello timers, and
having a longer time means the other end will take longer before it detects a circuit
going down.
All that said, I usually have long times, since I do not feel really quick detection of a
circuit down is that important, but I don't mind reducing the traffic a load a
little.
Other than that, everyone should feel free to make whatever choice they feel most
appropriate for their expectations.
Johnny
On 2019-07-28 16:41, Mark Matlock wrote:
> Johnny,
> I have one question I?ve been meaning to ask about hello timers and listen
timers. The default seems to to be 15 seconds hello and 40 seconds listen. But on MIM I
have seen some other combinations like Hello 300 secs but the Listen varies from 608 to
the default 40 (at least on IP-0-10)
> All the values seem to work ok, but on my 30.1 node which is a real PDP-11, I?d like
to use something closer to 300 and 600+ to reduce load and unneeded up and down messages
due to my flakey ISP?s internet.
>
> What are your thoughts on this topic?
>
> Thanks!
> Mark
>
>> On Jul 28, 2019, at 8:31 AM, Johnny Billquist <bqt at softjar.se> wrote:
>>
>> People, I have written a page about DECnet costs and HECnet costs, which I would
recommend that anyone interested read through. It contains a bit of elaboration on how
DECnet does routing, and gives some suggestions on how costs could be set on HECnet to
make it perform better.
>>
>> I have noticed over the years that sometimes we do get really silly routing
decisions just because of how people set, or do not set costs. The page I've written
is by no means perfect, nor are the suggestions in there. But feel free to come with
feedback, or ignore it. But I am going to try and use this myself more properly from now
on, and that means that if others don't, you probably are going to get more traffic
through your nodes. Traffic that probably do not make sense that it passes through you,
but I just feel that I prefer to try and make it work right from my point of view, and
then just at least tell people how I worked my numbers out. If someone have a different
idea, I'm open to changing my settings, but I will not try and do optimizations to
achieve:
>> a) Same paths for packets in both directions - DECnet explicitly does not do
this.
>> b) Specifically penalize one type of interface because of any subjective
preference about that type of interface in general.
>>
>> Oh - and the link to my writeup: http://mim.update.uu.se/costs.htm
>>
>> 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
>
--
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