Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[sevenlayermuddle]

I'm rather sick of BT's DLM and its mistaken attempts to 'stabilise' my line when the only real instability in the past year was caused by OR digging up the ducts in the road outside.

So, I have an idea.    DLM makes its decisions based on the stats obtained by interrogating the router, yes?   

... And, with my current billion router,  I can  reset the stats via the GUI.   So the plan... I have a server that already runs 24x7.   So if I set up a script on that server that resets the router stats every (say) 10 seconds for a few weeks, then the error counters when polled by DLM will always be nearly nothing.   DLM will rcognise my line for the model of perfection that if is, and allow me to use the bandwidth.     

Any predictions, will this plan work? Or is it flawed?   

[burakkucat]

DLM makes its decisions based on the stats obtained by interrogating the router, yes?   

Erm . . . the DLM interrogates the MSAN/DSLAM. If one has an appropriate modem, the MSAN/DSLAM will share its statistics with the modem.

... And, with my current billion router,  I can  reset the stats via the GUI.

With my Huawei HG622 I can issue an xdslcmd info --reset command.

So the plan... I have a server that already runs 24x7.   So if I set up a script on that server that resets the router stats every (say) 10 seconds for a few weeks, then the error counters when polled by DLM will always be nearly nothing.   DLM will rcognise my line for the model of perfection that if is, and allow me to use the bandwidth.     

Any predictions, will this plan work? Or is it flawed?   

An interesting idea but I predict failure. However, if you are willing, why not suck it and see, then report back with your findings? 

[Black Sheep]

I'm with B*Cat in as much as my prediction is DLM will kick you hard in the shins for that kind of action ?
Again, to mirror B*Cats sentiments ….. why not try it and see by way of an experiment ?? It may be a scientific breakthrough ??.

[sevenlayermuddle]

Erm . . . the DLM interrogates the MSAN/DSLAM. If one has an appropriate modem, the MSAN/DSLAM will share its statistics with the modem.

Hmmm, I did not think that the MSAN/DSLAM had any way of 'knowing' that an error had been detected in the downstream, orher than by 'asking' the router whether it has seen any errors?

An interesting idea but I predict failure. However, if you are willing, why not suck it and see, then report back with your findings? 

Indeed, I think I might.

[sevenlayermuddle]

I'm with B*Cat in as much as my prediction is DLM will kick you hard in the shins for that kind of action ?

Yes that is the risk 

But my line proved its capability by going over a year at DLM controlled 6dB, before being hoisted up to 12 during the OR work in the village (now complete).  It did recover to 9dB, but the Top Secret DLM algorithms appear to make it hyper-sensitive in the period immediately following any reduction, and it was set back to 12 yesterday as probable a 'thank you' for installing a new router, which obviously entails a few resets.

Anyway, now I'm on 12, when it should be 6.   Worst that can happen would be 15, I'm still tempted to give it a go!

[burakkucat]

Hmm . . . I've given it some more thought.

You are, of course, referring to a VDSL2 circuit between the FTTC and your CPE as part of the Openreach GEA product. In this case, it is known that the flow of statistics is as follows:

CPE <-----> MSAN/DSLAM -----> DLM

The CPE tells the MSAN/DSLAM and the MSAN/DSLAM tells the DLM. (The MSAN/DSLAM also tells the CPE . . . )

I still predict failure but it's worth a try . . . 

[sevenlayermuddle]

You are, of course, referring to a VDSL2 circuit between the FTTC and your CPE as part of the Openreach GEA product. In this case, it is known that the flow of statistics is as follows:

No I am plain old adsl 'max' IPStream.

I guess it comes down to how the router updates the DSLAM.  My reasoning was that if these updates are event-driven, such that the DSLAM is notified in real time for each error, my efforts would be doomed to pointless.   But if DSLAM periodically polls the router, and if I can reset the stats at a rate much faster than it is being polled then, most of the time the values perceived by DLM  would be vastly reduced.

BUT I have thought of a drawback, and am getting cold feet.   

Suppose my exploit worked as planned, DLM would then calculate (for example) the HEC count over a given period by subtracting the previously reported value from the current value.   And if I have rest the stats in the interim then the current value is less than the old value, DLM will end up with a negative number. 

Now imagine the credible proposition that the DLM code-path has never been tested for negative numbers and that it fails to handle signed arithmetic propery.   It could then conclude from that small negative number that (assuming 32 bit arithmetic) the best part of 4 billion HECs had occured.

The reason I am willing to consider the above is that, actually, it would fit in with the fact DLM raised my margin after I spent a day playing with a new router.   It may be the fact I reset the connection a few times but I'm unconvinced as I was very careful, restricting myself to no more than one reset an hour, I learned that the hard way.     

But I did manually reset the errors stats several times.   Could that (by above reasoning) explain why I got 'hit' by DLM in the first place?

[Black Sheep]

DLM collates the circuits data every 15minutes. It passes this info to RAMBo, which in turn 'summarises' the 24hrs worth of 15mins data, and 'Stabilises' accordingly.

There are 'over-rides' built-in for extremely poor-performing circuits, which allow RAMBo to react in real-time with regard to 'Stabilising'. I fear this is exactly what will happen with regard to your 'experiment' ?? 

[sevenlayermuddle]

DLM collates the circuits data every 15minutes. It passes this info to RAMBo, which in turn 'summarises' the 24hrs worth of 15mins data, and 'Stabilises' accordingly.

There are 'over-rides' built-in for extremely poor-performing circuits, which allow RAMBo to react in real-time with regard to 'Stabilising'. I fear this is exactly what will happen with regard to your 'experiment' ?? 

Well in the course of today I have reset the connection just once, for about two hours, when I disassembled the 'comms shelf' to mount the Billion on the wall and in a cooler place.   It looks very smart on its wall mount over a doorway, even SWMBO agreed it looks tidy, but that's off topic. 

But I have reset the stats several times, just to make it easier to keep an eye on the trends.   If I wake up tomorrow to a 15dB margin, I shall know what conclusions to draw.   

[Black Sheep]

DLM is completely automatic, how it decides to 'act' still cannot be fully second-guessed ?!.   

I think to draw conclusions with your experiment, a longer period of time is required, IMO. 

[burakkucat]

You are, of course, referring to a VDSL2 circuit between the FTTC and your CPE as part of the Openreach GEA product. In this case, it is known that the flow of statistics is as follows:

No I am plain old adsl 'max' IPStream.

Oops! Where is b*cat's paper bag? 

Suppose my exploit worked as planned, DLM would then calculate (for example) the HEC count over a given period by subtracting the previously reported value from the current value.   And if I have rest the stats in the interim then the current value is less than the old value, DLM will end up with a negative number.

But now please give a thought to what must happen when the counter reaches its upper limit of ...999 With the next increment it rolls over to 0. Logically, every line must have experienced the previous_value > current_value scenario at some stage. So I predict that your concern for the DLM to fail to handle signed arithmetic correctly is unfounded. 

[sevenlayermuddle]

But now please give a thought to what must happen when the counter reaches its upper limit of ...999 With the next increment it rolls over to 0. Logically, every line must have experienced the previous_value > current_value scenario at some stage. So I predict that your concern for the DLM to fail to handle signed arithmetic correctly is unfounded. 

Assuming 32 bit unsigned arithmetic, the upper limit would be 2^32 - 1. At (say) 10,000 HEC a day, by my calculations (and I have just emptied the wine bottle  ) , a router would need to have been powered up for about 400,000 days ( over 1,000 years) before the counter wrapped.   

I can well believe that BT might have overlooked, in their testing, a '1000 year' bug in DLM.

[burakkucat]

Ah but I did not explicitly specify the HEC counter. I was referring to any counter, in general. 

CRC perhaps? 

[kitz]

Quick reply I will have to mull over your suggestion fully...  But I think the dlm should be more than used to having a < situation.   People who physically turn off their routers, people buy new routers, people reset routers etc.

As long as you can reset totals without a resync, then you could possibly be on to something..

Certainly if downstream errors are where you rack up any big figures.  Just checking that you can just error counters can be reset and it doesn't affect your uptime?

Would certainly be an interesting experiment.   Yes it could go wrong, but with you being on adsl rather than vdsl, if worse comes to worst you could approach your ISP for a dlm reset.

Flow of stats is the same as described for max, there's a diagram on the main site which shows the flow and it is def every 15 mins.

--

I know I'm on vdsl, and uptime is monitored at the RAS... But look how last year when I had a line fault, how quite often a very quick resync wouldn't actually record on the system.   I will think about this some more today.

[les-70]

    I would say give it a try.      I would very surprised if it made anything worse.  My guess is that it may mean that the dlm is then not aware of the rate of error correction that occurs without a re-transmit of a packet.  This may encourage a drop in snr and or interleaving.  On fastpath with no interleaving I think a CRC often causes a re-transmit and not an FEC.  The dlm may well be counting those re-transits itself and it may not need to get those errors from the modem.