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