On Thu, 2006-07-27 at 19:58 -0400, Michael Poole wrote: > That occurred to me. Ideally we would have both; manually initiated > ASLLs already use high priority messages.
We have manually initiated AsLLs? All I'm aware of is the /asll command, which is supposed to report the most recently collected AsLL result--for obvious reasons, that one uses high priority...but you're right, the ideal would be to have AsLL computed on both high and low priority bands. > My guess is that if the burst completes within some time -- probably > 10 to 30 seconds -- it is evidence that the link is good enough to use > given the size of the network, and that later reduction in link speed > is probably a temporary problem. In that case, we would only want to > squit if the route goes entirely away or if the problem persists for > some fairly long time. This latter is why you want to have the AsLL pings using the lower priority band--you can poll /asll and see a high latency staying high over a period of time... > If we never get around to putting "some fairly long time" analysis in > the ircd, locally opered bots could map network latencies using > privmsgs and implement the admin's policies based on those numbers. > Making link liveness decisions, rather than quality decisions, based > on the low priority latency may be a poor approximation; it also gives > the admin less freedom in setting linking policy. Right, from this standpoint, we want the high priority AsLL numbers combined with some indication of sendq liveness (is the sendq draining faster than it's accumulating, on average?). I originally conceived AsLL as a way to catch asymmetric latency--times when you get messages from the other side of a lagged link in short order, but your reply times are quite long. It's in essence another way of measuring outstanding sendq--though comparing it to sendq can show underlying network problems. There seems to be value to both approaches... > Going back to "ideally we would have both", I can imagine allowing the > admin to set latency tolerances at several levels. For example: > > high [priority] pingfreq = 5 seconds, below 20 seconds for 180 > seconds, below 60 seconds; > low [priority] pingfreq = 5 seconds, below 90 seconds for 180 > seconds, below 120 seconds; > > This would make the ircd measure both high- and low-priority link > latency (HPLL, LPLL respectively) every five seconds, unless a ping is > pending at the priority. If the HPLL exceeds 60 seconds, or the LPLL > exceeds 120 seconds, the link would be squit immediately. Once the > HPLL is at least 20 seconds, a timer or flag is set; if the HPLL stays > above 20 seconds for at least 180 seconds, the link is squit. The > LPLL "below 90 seconds for 180 seconds" is similar. I like, I think... :) -- Kevin L. Mitchell <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Coder-com mailing list Coder-com@undernet.org http://undernet.sbg.org/mailman/listinfo/coder-com
