Print

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

[Chrysalis]

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?   

my gut guess is its flawed.

1 - when resetting its entirely possibly it only resets the 'visible' stats and there is other counters kept internally for the purpose of eg. sending to the dslam.
2 - It is also possible its not the total counters sent to the dlsam but rather just daily counters. so what happens if you reset shortly after these are sent to the dlsam?
3 - The dslam will still have its own counters for its end of the connection so it doesnt solely rely on the end user modem.
4 - If I am wrong on #1 if it recieves values lower than previous values then something weird may happen.

But as others said keep it up, if it works its a breakthrough.

[sevenlayermuddle]

Owing to some unrelated equipment shuffling I had to power the router off for a while today and then, annoyingly, a second time after I screwed something up.  I'd been allowing myself to hope that when it reconnected it'd do so at a lower margin as, whilst it seems logical, I don't think we know with certainty that a margin reduction automatically causes a reconnect.

But no such luck, still 12dB.   Ah well, at least it wasn't 15.

Ideally I'd like to leave it COMPLETELY alone during this experiment as we don't know the extent to which DLM, when it's feeling a bit sensitive,  frowns upon even just an isolated disconnect.   I'll need to try harder.   

[sevenlayermuddle]

So the experiment has passed the first threshold of interest for me,  which is the (rumoured) 14 day minimum period for reduction and… nothing has happened.  I'm not giving hope, but but I'm feeling a bit less optimistic.  If it was going to have any beneficial effect at all then I'd expect it to have a massively beneficial effect, so I was hoping for rewards within 14 days. 

But the 14 days is only a rumour, DLM's algorithm may be more subtle, and there have been a few hiccups along the way.  Such as  maybe 3 or 4 manual reconnects in the period, for reasons that are not relevant.

Ah well, at least nothing bad has has happened.  And at least my current (12dB target) DLM target survived some thunderstorms that rumbled around for a good hour or two yesterday afternoon during which I noticed all error counters were really racking up, even the odd SES, until reset again by my script.

[kitz]

Please do keep us informed, I was wondering how it was going.

[burakkucat]

Yes, please keep us updated with the experiment's progress. 

I have a feeling that it may need to be run for at least a month. 

[sevenlayermuddle]

Unfortunately circumstances are not conspiring in my favour. 

There are thunderstorms rumbling on in the distance once again today.  And even though the counters  are reset after 60 seconds, a snapshot of stats via the Billion  GUI often shows massive error counts.  One from a moment ago showed, among other calamities, 496 'uncorrectable errors' with several ES and 2 SES.

That's unsurprising considering the thunder.  But it is a shame because, in the absence of these thunderstorms, it is rare to see any errors at all when randomly sampled.  And unless the thunder gets close enough to be a real threat I don't want to disconnect or power off as (1) that in itself might be seen as instability and (2) I want to do things that need online access   

[roseway]

Unfortunately the real world can impact on research.

[sevenlayermuddle]

Yes, please keep us updated with the experiment's progress. 

I have a feeling that it may need to be run for at least a month. 

Spookily accurate 

Today is a calendar month after I started the experiment, and I see the router reconnected about 8am at a speed circa 700kbps better than it was.  Whereas target was previously 12dB, current SNRM is showing as 9.2dB, so I am happy to assume my target has been reduced.   

I'm reluctant to declare the experiment a 'success' as we'll never know whether or not it would have got reduced on its own, and whilst DM may sometimes take much longer than a month, it certainly wasn't immediate.    I'll leave the script running and see what transpires.   I would expect target to drop eventually to 6dB as it has done so before given time, but if it were progress to the removal of interleaving then that would definitely be a first. 

[roseway]

It's an experiment that has been well worth doing, even if perhaps it hasn't achieved anything which wouldn't have happened anyway. It appears not to have had any undesirable consequences, and that in itself is useful information for the tinkerer.

[kitz]

I think erics said practically my thoughts.

[sevenlayermuddle]

One small point of detail is, when I said i got reconnected about 8am, it was actually exactly 7:59am.   Allowing for clock drift, one could almost conclude that the hour of 8am is somehow of significance to the DLM algorithm?   

When(/if)  the 9dB to 6dB transition occurs it will be interesting to see if it is also aligned to such a boundary.

[burakkucat]

   An interesting observation with respect to the timing of the event. I seem to recall that Bald_Eagle1 has observed that 0600 hours is the normal time for DLM intervention on a GEA FTTC line (VDSL2).

[sevenlayermuddle]

  An interesting observation with respect to the timing of the event. I seem to recall that Bald_Eagle1 has observed that 0600 hours is the normal time for DLM intervention on a GEA FTTC line (VDSL2).

Interesting.

And thinking upon it, either of these times would be a logical choice.  Since the reconnection will interrupt the service, better to do so outside of normal working and social (evening) hours. But they may also want to avoid the speed penalties of reconnecting in the middle of the night, making 6am to 8am the obvious time slot.

I'd still have expected the transactions to be scattered mind you rather than all happening 'on the hour', if only to relieve traffic peaks within whatever management network is involved.   

I hope to have further evidence soon, when my target drops to 6dB. 

[sevenlayermuddle]

Update...  It is now two more months since I got reduced to 9 dB and there has been no further reduction.

I am now abandoning the experiment, concluding that whilst it had no detrimental effect, it probably had no beneficial effect either.

[roseway]

Oh well, you've added to the body of knowledge in any event.