Recap: My line #3 has for a long time had a problem with the upstream SNRM, which drops sharply for approx half the day and then sharply shoots back up again. The height of the drop is 5.7dB and dropping from 6dB like that isn’t funny so you have to hope that it’s in the ‘low’ state when initiating a retraining of the modem, so that later it will shift up to a very high level harmlessly. I have tried setting the upstream target SNRM to 9dB to help deal with the case of a retrain when at the high level (of the target) which is either 6dB or 9dB but the latter being safer as a drop from 9dB isn’t
tooo bad.
This really really slows the upstream down, by 25%, eg 500k->420kbps Line 3.
But now I’m seeing a similar thing with my
line 1. It started fairly recently, can’t say when exactly. The drop is not as high so it isn’t quite such a disaster. There will be the same thing; if there is a resynch at the wrong time then the upstream will be really slow.
The other badness is that if the speeds change dramatically then the Firebrick’s egress / tx rate limiter values assigned to each modem by kludgey external software (which does not run automatically in timely fashion) will be wrong so the fraction of total upstream traffic assigned to each modem will be be wrong too, as it will have been set according to out-of-date upstream tx / egress speed capability values.
Line #3:
Line #1:
Digressing seriously, for the moment. This makes me wish there was some kind of local site info broadcast/multicast system, I may have written about this before? DHCP does some of this effectively and a radical expansion of DHCP would seem to be the way to go. It would be better from the point of efficiency and robustness though if there were a system based on multicast and one that supported both IPv6 and IPv4. DHCPv4 isn’t suitable because of IPv6-only clients. If multiple multi casting info servers could gather information and then distribute it, also synchronising data so they all carry a complete copy, and with the capability of electing a new master if a machine is seen to have died or is not performing its function. Maybe the other machines could take it in turns to poll the master, asking it questions that require some very small amount of intelligence in the response. If clients subscribe to multicast then that would cut the load of noise imposed on the network dramatically.
Such an info server system could tell clients all kinds of things about the local site; such things could enhance TCP’s behaviour by tuning.
In the present case modems could be queried and the speeds converted into tx / egress rate data - as IP PDU rates - for routers. But most importantly, modems’ resynchs could be detected and when modems’ speeds change then routers could be informed with a real-time event with new upstream / tx speed values as IP PDU rates.