Print

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

[Chrysalis]

Theory why no DLM reset was done by the engineer is that he was called in for a voice fault, officially a engineer doing a voice fault cannot mess with the broadband specifically.  He did what he could I expect, sort of like when I had a voice engineer fix my adsl sync several years ago, but doing a DLM reset would have stood out like a sore thumb on a voice visit.

[broadstairs]

I fully understand that and he did explain all that.

I'm really wondering if what I'm being told by TT is a load of waffle or whether something really has changed and the DLM stuff will happen in 48 hours (I presume from the fault fix time) so it should kick in by teatime on Sunday.

Stuart

[WWWombat]

I've not heard anything as you described in the edit - the stuff about a new max attainable that could be less than before. It'd be interesting to see what this means in practice, if true. I'm not sure that anything other than the existing DLM reset process makes sense, though.

The part about an automatic reset after a voice line fix does actually make sense, but again, I've not heard of it.

[broadstairs]

I am content to wait the 48 hours as requested by TT BUT if nothing happens by then OR I am left with a lower max speed than I was running with before all this kicked off then I WILL complain LOUDLY and see what happens. It is good to know that running DSLStats and MDWS gives me quite a lot of actual evidence about how my line was behaving prior to all this.

Stuart

[NewtronStar]

BT systems will reset DLM within 48 hours of the fault being fixed.

That is just a fancy way of saying wait for the DLM to adjust your line don't understand the 2 days wait that is normally reserved for a DLM reset open profile like a new FTTC line which would start off on fastpath

[broadstairs]

DLM re-sync this morning and now at 12000kbps up and 55844kbps down. Not good enough and I've told TT this is unacceptable. Now to see if they will do anything.

Stuart

[WWWombat]

It looks like the upstream banding changed from 10M to 12M, but no change on the downstream settings. That still looks to be limited by the FEC/interleaving settings (but I'm guessing - MDWS doesn't have the full set of data to check this).

This looks more like standard DLM recovery, in small gradual steps, rather than some new-fangled DLM reset.

[broadstairs]

Yes gradual steps... another this morning with up at 14993kbps and down still hit by interleaving. I have complained to TT about this. When a fault on the line is fixed in my view they should set the line back to the same state it was in prior to the fault rather than this ridiculously cautious approach. Dont know if they will do anything but at this rate it cold take several more days before it gets back to what it was before. Error rates are still very low and there is a lot more it cold cope with easily in my view.

Its also interesting that each time DLM intervenes I see a burst of CRCs and ES right on the minutes the re-sync happens, dont know why but I'm guessing the router is a bit puzzled by whatever DLM does to drop the line.

Stuart

[Dray]

What if the line is dropping because of these errors and not DLM?

[broadstairs]

What if the line is dropping because of these errors and not DLM?

The evidence of the graphs on DSLStats does not support. DSLStats shows a light coloured line on the rising side of the graph and solid colour line on the falling side of the line. This tends to indicate that there are showing as the line is coming back, if they were happening prior to the error the line would show the other way round. Also we are not talking huge numbers, plus these ONLY happen at the exact minute after the line drops and the error rate at other times is very very low. The re-sync is detected at 7:42 and the errors show at 7:43. Also if DLM was intervening because of these errors I would NOT expect it to increase line speeds etc.

Stuart

[Dray]

As the errors are happening after the resync they are therefore not responsible for the resync. If they are the same ones I see I think they are a normal event after a resync anyway and I usually ignore them, but from your description I thought they weren't.

[broadstairs]

Sorry I probably didn't explain it as well as I could have the first time.

Stuart

[WWWombat]

Its also interesting that each time DLM intervenes I see a burst of CRCs and ES right on the minutes the re-sync happens, dont know why but I'm guessing the router is a bit puzzled by whatever DLM does to drop the line.

Yup - that's notable too. Similar sized bursts of CRC, ES and SES each time. Can't be a co-incidence ... and I reckon it is indeed the modem being confused by the resync, or the manner that DLM brings it about.

You've got to wonder why DLM is choosing to relent on the upstream, but making no adjustments to the downstream - both look worthy.

And, while it is academically interesting for us to watch the improvements happen, this is surely is a case where TT ought to be asking for a DLM reset - even if it needs a broadband engineer to perform it.

[Ronski]

It is crazy that the DLM is not reset automatically when a voice fault is repaired, as surly a large proportion of voice faults would have affected the broadband connection.

[Dray]

Surely that's down to the often repeated mantra when reporting a voice fault of, "don't mention the broadband"? How is the technician supposed to know you have broadband?