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 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.

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: -- 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

I missed out one important part, xT3MULT are defined as architectural constants so you can?t change their value, T3MULT = 2 and BCT3MULT = 3.

John. > 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 >

On Jul 28, 2019, at 4:03 PM, John Forecast <john at forecast.name> wrote: 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.

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...

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.

On Jul 30, 2019, at 3:39 AM, Johnny Billquist <bqt at softjar.se> wrote: ... 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.

On Jul 28, 2019, at 9: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