Print

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

[broadstairs]

As some may be aware my line had been capped at 60000kbps since last August and as my efforts to get TalkTalk to do something came to nothing I have opened a complaint. Today I received a reply which I find both interesting and worrying in almost equal measures. The first part is:-

Yes indeed there is a 60Mb/s cap in place on the line. It is not possible for me to see why the DLM cap was applied (data is archived), but I can only assume it was because DLM saw some errors and/or retrains, hence has applied the cap to try and increase stability and decrease errors.

Well yes I do know when it was done and yes my line was having problems but this did NOT fix it. They go on to say:-

The cap will stay in place until a green ILQ (Indicative Line Quality) is triggered (and the profile would move up the ladder, probably gaining speed) or a red ILQ is triggered (and the profile would move down the ladder, probably losing more speed).

However, if the circuit has small numbers of errors (which this circuit does), it will trigger neither a green nor red ILQ, it will have an amber ILQ and remain at the current capping level.

and this is exactly the state my line is in mainly amber. It goes on :-

Just looking over the Yukon line history on this circuit, there are consistently small numbers of errored seconds and code violations. The numbers of ES/CVs are too high to trigger a green ILQ, and not high enough to trigger a red ILQ. The circuit looks firmly set to an amber ILQ.

We have no ability at present to request a DLM profile reset remotely for singleton cases, we can only book an Openreach field engineer who may or may not request a DLM reset. I would suggest that because of the ES/CVs, if we did request a DLM profile reset, the circuit would end up back on the current line profile (or similar) within a few weeks anyway."

just puzzled as to what they mean by code violations (might ask for an explanation of that one).

Now I guess I could argue my case some more but it would seem that they think it is unlikely to have the desired result.

If I interpret this correctly then anyone with a cap is stuck unless their line goes green completely (I guess as shown on MDWS) and the chances of most lines going green is minimal depending somewhat on which profile you are on.

I am thinking about pushing this further but would appreciate knowing what others think.

Stuart

[skyeci]

I am amber all the time but no cap. Maybe it would pay to see if g.inp ever does come back. Maybe it would help the situation..

[ejs]

1) 59995kbps
2) 62759kbps
3) 130 days
4) following about 2-3 months of problems with 3 BTOR visits
5) current SNRM 6.9 db was over 7 on initial re-sync recently

Stuart

If the above details still reflect the current state, removing the banding would only have a relatively small effect on the bandwidth. So I suppose it depends on if you think the time spent on dealing with the issue is worth the potential gain in bandwidth, if you succeed.

[roseway]

Code violations are CRCs.

[Sheepie]

can you speed limit your line to a much lower sync, then ES will reduce taking you into green ILQ, then (according to them) the DLM will start to remove banding. Once banding is removed you can then remove the speed limiting your end and as long as you are not going into the red ILQ you should be good?

[j0hn]

It would need to be a considerable cap, as he's Talktalk and using the Standard DLM profile. He would need less than 144 ES/day but the line currently sees 250-300 ES most days. It's exactly the advice I was going to give though. Setting a sufficient cap to keep the line ILQ green for an extended period would be an interesting experiment to see if the banding does remove itself. It would give further weight to any argument with the ISP that the problem lies with a broken DLM system.

[licquorice]

I'm afraid I really wouldn't be bothered with trying to increase speed from 60M to 63M, how will you tell the difference? You did ask.

[broadstairs]

The issue here is not one of 3,000kbps in speed but the fact that they put a cap on to try to fix a fault and it did not the fault continued for some weeks after the cap was in place. I have evidence that the cap was introduced way before the fault fixed itself. If you do something to try to resolve a fault that's fine but when it patently and obviously does NOT fix it then whatever was done should be removed. They are getting away with very sloppy fault finding in my view. I still get spikes of 1200 CRCs in a minute spasmodically so I think there is an issue with my line. Just because someone has an intermittent fault is no excuse, if you do something and it does not fix the problem then back off the change or all you do is end up hiding the fault and in my view this is exactly what BTOR are doing. If my line was amber for probably 6 months then it is not behaving badly and does not need a cap. Just because a line goes green does not mean it's fixed especially if someone fixes the sync speed to kid the system.

Thanks Roseway, why on earth do they call CRCs code violations, it has nothing to do with code they are Cyclic Redundancy Check errors which is not a coding error but an error detected by code which is very very different, stupid terminology in my view.

Stuart

[sevenlayermuddle]

Thanks Roseway, why on earth do they call CRCs code violations, it has nothing to do with code they are Cyclic Redundancy Check errors which is not a coding error but an error detected by code which is very very different, stupid terminology in my view.

Code violations refer to errors detected in the transmission encoding protocol.

Not to be confused with errors introduced by human 'code-writers', or programmers, who implement the software for these protocols.

[Chrysalis]

been blunt given your snrm is only 6.4db I think its not worth the hassle, the sync speed gain is going to be a very small % of your existing speed.  Your modem estimates attainable at under 62mbit, which is probably fairly accurate as you on fast path.

[broadstairs]

This is not about speed but the principle of a cap in the first place. It was put on to try to fix a fault but it did not fix it. This also means that it is unlikely should G.INP be re-introduced on the ECI estate my speed will stay at this value despite my line working very reliably when it did have G.INP running at 71000kbps and I 'd have a fight all over again. My argument the way DLM is supposed to work is that a line which can run very stably on an ILQ of amber for some 6 plus months deserves to have the cap removed. I am not a speed freak and don't do gaming etc, I just want my line to be able to negotiate any speed that the DSLAM and modem feel is correct within the contracted speed.

Stuart

[lee111s]

This is not about speed but the principle of a cap in the first place. It was put on to try to fix a fault but it did not fix it. This also means that it is unlikely should G.INP be re-introduced on the ECI estate my speed will stay at this value despite my line working very reliably when it did have G.INP running at 71000kbps and I 'd have a fight all over again. My argument the way DLM is supposed to work is that a line which can run very stably on an ILQ of amber for some 6 plus months deserves to have the cap removed. I am not a speed freak and don't do gaming etc, I just want my line to be able to negotiate any speed that the DSLAM and modem feel is correct within the contracted speed.

Stuart

Seems you have way too much time on your hands.

Ignore the details and just use the internet for its intended purpose.

[Black Sheep]

Seems you have way too much time on your hands.

Ignore the details and just use the internet for its intended purpose.

 

[broadstairs]

My problem is not way too much time on my hands I just hate sloppy work and in my view this is exactly what happened last summer. Dont bother to fix a fault just bodge it and then go to the next job.

Stuart

[lee111s]

My problem is not way too much time on my hands I just hate sloppy work and in my view this is exactly what happened last summer. Dont bother to fix a fault just bodge it and then go to the next job.

Stuart

Your internet connection works for its intended purpose.