|
|
|
Ok so let me start this by saying part of this problem is my fault and I can only accept that.
But i would love to get a view from those that know on here if
1) I'm smoking something and I'm completely wrong in my assumption below
2) What are the options to fix it are if I'm correct
So I had new line installed for Zen FTTC 80/20 service. Im about 500M from the cabinet so i knew I wouldn't get 80/20. But I already have a Sky FTTC line achieving 53/14. The speed estimate on sign up for Zen was 22-60MB (yes that wide)
Anyway over the first few daysafter install my line was giving lots off errors (FEC, ES and CRC) so DLM slowly introduced interleaving to stabilise the line and reduce speeds as a consequence. Thats as I would expect. Then I suffered a number of resyncs. I thought this strange so investigated and found that the modem cable from the BTO modem to the master socket had been damaged at some point. I replaced the cable and awaited G.INP to kick in as i knew it would eventually. A few days later G.INP did kick in and and my speeds increased and the line became very stable.
Now here is the first point I need help on. My line stats from the unlocked BTO modem are showing
Sync 43998
Attain 53124
SNR 9.6
I'm convinced that means I'm banded and it was due to the faulty cable now replaced that DLM did this.
However when I call Zen they tell me that BT line check is showing my line is at its max speed and its not banded. BUT and heres my assumption I need validated If my line was achieving its MAX and was NOT banded I would see a SNR of around 6 and my sync would be close to attain. Is that wrong ?
Assuming my assumption is correct and I am banded my understanding is that once your line is banded the DLM never removes. Even if it the line stats in MYDSLWEBSTATS for example is green on all indicators now. If so what are my options to get a DLM reset as there are no errors now to be fair DLM intervened when the line was throwing errors, but it was caused by an issue I have fixed, and Zen say the line is performing to its max, which if my point is correct is wrong.
If I'm wrong I'll shut up and get on with forgetting my missing 9MB. But am I ?
|
|
|
|
From the fact that your snrm is higher than the usual default of 6dB I would agree that you have a banded sync speed. Removing it could be a problem if Zen do not accept that the line can run faster.They should be able to tell from the GEA line profile that it is banded so I think you need to pester them to provide a GEA test result.
|
|
|
|
Thank you - so pleased I have at least one other person who agrees I'm not bonkers.
Anyone from Zen care to comment or advise how the assumption is actually flawed.
I know that BT will not normally perform a reset of DLM unless they can find an error. But I found it for them and corrected it surly there is a process for this
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
This banding lark is becoming a bit of a pain. I was banded due to the same process you describe. If banding is being applied before G.INP then the DLM algorithm is wrong it should be the other way round.
This smacks to me of poor coding on DLM with G.INP coming in at a later date and the DLM coder not programming G.INP to kick in earlier.
Only way was for mine to be DLM reset by a BTO engineer but I had an incorrect underground feed that was losing 13m downstream speed. An overhead dropwire fitted underground and not twisted pair.
I'm still waiting for BTO to put my drive back together after digging it up. Partially done today I might add.
|
|
|
zen seem not the best for pestering openreach, it is one reason I havent chosen them as an isp.
If they insist its not banded then they should have no problem pasting you the GEA test result to prove their case.
|
|
|
|
Zen are now investigating and have accepted an engineer is required to reset
Once I got to the right team it was all good
|
|
|
good news then
|
|
|
DLM reset performed
Line now going through the FEC/ES/CRC error process and applying interleaving
However in a week or so I will get G.INP back on and should return to a clean line with NO BANDING this time or at least i hope so
|
|
|
|
|
|
|
Yes Engineer
I asked them just to remove the banding and leave g.inp
Apparently thats not possible so now I have a week or so of high FEC, ES and a few resync I suspect until DLM decides I can have my g.inp back
Edited by deleted (Fri 28-Apr-17 09:21:29)
|
|
|
Banding GONE GONE GONE
DLM rest on Thursday 27th April
G.INP back on today Sat 29th April and now DS sync is back to 55MB which is what i would expect up from the banded 44MB
|
|
|
Its a relief isn't it? Must admit I get about 10m extra from G.INP.
|