|
|
Hi guys,
Just noticed that the line has resynced and there have been several changes made to it by DLM.
Here's the line stats before and after.
Just wondering if it looks like the new implementations announced by Openreach have been activated on the line?
Before:
xDSL
Mode VDSL2
Traffic Type PTM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 6.8 6.0
Attenuation (dB) 26.0 0.0
Output Power (dBm) 12.2 5.5
Attainable Rate (Kbps) 42250 8748
Rate (Kbps) 40844 8748
B (# of bytes in Mux Data Frame) 243 227
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 0
R (# of redundancy bytes in the RS codeword) 10 10
S (# of data symbols over which the RS code word spans) 0.1902 0.8289
L (# of bits transmitted in each data symbol) 10682 2297
D (interleaver depth) 8 4
I (interleaver block size in bytes) 254 238
N (RS codeword size) 254 238
Delay (msec) 0 0
INP (DMT symbol) 48.00 46.00
OH Frames 0 0
OH Frame Errors 0 0
RS Words 80201240 1295108
RS Correctable Errors 102067 111
RS Uncorrectable Errors 0 0
HEC Errors 0 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 300831147 0
Data Cells 3517590 0
Bit Errors 0 0
Total ES 0 0
Total SES 0 0
Total UAS 30 30.
After:
xDSL
Mode VDSL2
Traffic Type PTM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 5.2 6.4
Attenuation (dB) 26.0 0.0
Output Power (dBm) 12.0 4.8
Attainable Rate (Kbps) 45875 8531
Rate (Kbps) 45327 8531
B (# of bytes in Mux Data Frame) 227 227
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 0
R (# of redundancy bytes in the RS codeword) 10 10
S (# of data symbols over which the RS code word spans) 0.1600 0.8500
L (# of bits transmitted in each data symbol) 11901 2240
D (interleaver depth) 4 4
I (interleaver block size in bytes) 238 238
N (RS codeword size) 238 238
Delay (msec) 0 0
INP (DMT symbol) 55.00 47.00
OH Frames 0 0
OH Frame Errors 585 0
RS Words 48041396 495669
RS Correctable Errors 29141 21
RS Uncorrectable Errors 0 0
HEC Errors 0 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 168230857 0
Data Cells 2244583 0
Bit Errors 0 0
Total ES 14 0
Total SES 11 0
Total UAS 68 57.
Edited by deleted (Sat 21-Jan-17 20:07:28)
|
|
|
Just wondering if it looks like the new implementations announced by Openreach have been activated on my line? Do you mean the lower allowed sync-time noise margins? Doubtful. The only way to be sure is to read the stats within seconds of a re-sync.
The changes in your figures overall look to me look like your first set were due to sync'ing at a relatively noisy time and the noise went away. The re-sync at a less noisy time and at the time you read the stats the noise level was a fraction higher than at sync-time.
The only noticeable change I see is that DLM has slightly reduced the downstream interleaving depth. (And associated parameters). Both sets suggest that G.INP is active, but your modem does not displaying Bearer 1 figures. Only Bearer 0. I'm saying this because interleaving at these very low levels is typical of "with G.INP". Without G.INP downstream interleaving is normally in the high hundreds or a few thousands.
Upstream interleaving is quite rarely seen on these forums. Is it a Draytek modem?
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 54999/14466Kbps @ 600m. BQMs - IPv4 & IPv6
Edited by RobertoS (Sat 21-Jan-17 14:33:59)
|
|
|
Hi Bob,
Yes, I have to admit, the first set of stats were at a noisy time, but the second set were taken just minutes after the resync and with such an increase in the downstream rate, I thought something had changed, which, as you can see is true by what you've explained.
No, I'm using a Billion 8800AXL router, I was also surprised to see Upstream G.INP too, this made me also think something had changed, though I have noticed that more Huawei lines are now using Upstream G.INP.
Thanks for your help!
Edited by deleted (Sat 21-Jan-17 15:23:16)
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
|
You could possibly now be on a 5dB downstream profile, it is going to have to start somewhere. I guess the only way to be sure will be to check your SNRM at the next resync.
|
|
|
|
Hi underzone,
It's nice to see you on the forum, I hope you're well.
I should think so, here's an update:
xDSL
Mode VDSL2
Traffic Type PTM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 5.1 6.5
Attenuation (dB) 26.0 0.0
Output Power (dBm) 12.0 4.8
Attainable Rate (Kbps) 45867 8531
Rate (Kbps) 45327 8531
B (# of bytes in Mux Data Frame) 227 227
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 0
R (# of redundancy bytes in the RS codeword) 10 10
S (# of data symbols over which the RS code word spans) 0.1600 0.8500
L (# of bits transmitted in each data symbol) 11901 2240
D (interleaver depth) 4 4
I (interleaver block size in bytes) 238 238
N (RS codeword size) 238 238
Delay (msec) 0 0
INP (DMT symbol) 55.00 47.00
OH Frames 0 0
OH Frame Errors 585 0
RS Words 306802436 2136261
RS Correctable Errors 260564 97
RS Uncorrectable Errors 0 0
HEC Errors 0 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 1073890647 0
Data Cells 23613584 0
Bit Errors 0 0
Total ES 14 0
Total SES 11 0
Total UAS 68 57.
|
|
|
Unless he is on a trial cabinet on a trial exchange, then nope. General release isn't scheduled until March.
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 54999/14466Kbps @ 600m. BQMs - IPv4 & IPv6
|
|
|
Oh, I thought it was in February. I wonder why this is the case then. I'll keep monitoring over the next few days and report back if there's any changes.
Edited by deleted (Sat 21-Jan-17 16:12:07)
|
|
|
I concur with one of the other reports ... your new INP level has changed, but both old and new are values that go with G.INP. The small level of interleaving depth (8 before, 4 after) are also both indicative of G.INP
I note too that G.INP is active in both the upstream and downstream. Both before and after.
Your new sync looks suspiciously like it is targeting 5dB. The current SNRM level is at 5.1dB and the actual & attainable speeds are close enough to not worry about.
That would make me wonder, and monitor...
Unless he is on a trial cabinet on a trial exchange, then nope. General release isn't scheduled until March.
From Kitz, we know what exchange William is on ... and it is one of the trial exchanges.
It is therefore plausible that this is indeed step 1 of the trial ... to shift a line to a 5dB profile.
I'll keep monitoring over the next few days and report back if there's any changes.
It is very worthwhile monitoring. Can you turn your MDWS logging back on?
In particular, watch the error rates in a few different forms
- Errors fixed by correction: the FEC counters
- Errors fixed by retransmission, the RTX_TX, RTX_Corr and LEFTRS counters
- Errors not fixed - CRC, ES and SES rates
|
|
|
|
Hi WWWombat,
Thanks for your help, I hope you're well.
Sure, I'll turn MDWS back on once I get it all set up, I should be back on within the next hour.
Cheers!
|
|
|
|
Uploading now as requested. Should be interesting to watch.
|
|
|
Wait, I've just read the post that WWWombat linked to, it just shows that I'm pretty lucky to be in this trial! I wonder why my line was selected?! That's just awesome!
Edited by deleted (Sat 21-Jan-17 19:43:10)
|
|
|
William has won the lottery!
1st guy to report having one of the new SNRM profiles.
Stats look good:
http://imgur.com/a/0DQ5l
Edited by deleted (Sat 21-Jan-17 20:04:41)
|
|
|
|
If this is a trial then a resync of the modem should show whether your line is indeed on the trial as it should be persistent rather than one of those caused by a crosstalk event we get from time to time
|
|
|
Definitely not crosstalk as the downstream attainable rate is very close to the rate.
underzone, is it time to get out the bubbly? 
|
|
|
Just saying as i had resync yesterday and the snrm on both went down to 5dB and attainable increased and so did the sync until the modem did a resync and now back to target margin of 6db
Edited by deleted (Sat 21-Jan-17 20:11:24)
|
|
|
Sure, but don't know if you've seen the stats but the downstream attainable rate is above the rate frequently so I doubt that. The other thing is that the upstream SNR margin hasn't been affected and several other line characteristics have changed suggesting a DLM resync.
Edited by deleted (Sat 21-Jan-17 20:16:02)
|
|
|
If this is a trial then a resync of the modem should show whether your line is indeed on the trial as it should be persistent rather than one of those caused by a crosstalk event we get from time to time I suggest he doesn't do that. Especially if setting up the monitoring needed one.
Complete stability wrt his own actions is essential if he wants to keep the lower SNRM, and the possibility of an even lower one.
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 54999/14466Kbps @ 600m. BQMs - IPv4 & IPv6
|
|
|
Yes, it does beg the question if it'll drop even further over the next few days... Ok, I won't get excited just yet.
|
|
|
|
You don't get G.INP on the upstream on a stable line this only happens during instability probable best to leave that modem alone for the time being
|
|
|
|
That's true, I'm curious as to what instability there was as the line is stable.
|
|
|
|
maybe to many errored seconds has been seen by the DLM on the upstream and maybe the reason why your modem has resynced at those lower snrm values who knows
|
|
|
|
Ah, no Upstream G.INP was enabled before the resync today.
|
|
|
|
your g.inp downstream interleaving depth has gone from 8 to 4 and your INP has increased to 55.00 so your needing more impluse noise protection and you have g.inp on the upstream looks like a rather noisy line at the moment
|
|
|
your g.inp downstream interleaving depth has gone from 8 to 4 and your INP has increased to 55.00 so your needing more impluse noise protection and you have g.inp on the upstream looks like a rather noisy line at the moment
Have you even looked at his stats? They are great.
https://www.mydslwebstats.co.uk/
|
|
|
The line's always been noisy. The drop in interleaving is a good thing as it reduces latency and the increase in INP is good as it doesn't add latency but protection and increase in rate. underzone, he'll need an account to view the line stats.
Edited by deleted (Sat 21-Jan-17 21:28:17)
|
|
|
Ah, no Upstream G.INP was enabled before the resync today. Your interleaving depth "Before" gives 8/4. Your "After" gives 4/4.
I have my doubts about the upstream figure, unless it relates to a questionable modem. I say this because with two HG612s I never saw upstream interleaving, on my Billion I do not have upstream interleaving, but on either my ZyXel in modem/router mode or my DrayteK Vigor 130, (sorry I don't remember which and it doesn't matter at this stage even though I could probably find out with 20 minutes research  ), it did show a depth of 4 upstream.
Whether or not upstream G.INP is enabled is only determine with certainty if we can find the Bearer 1 stats. I think you are already using telnet to get the stats, so using that isn't the solution. As I remember it, despite whichever of my modems showed this "4", G.INP was not enabled on the upstream.
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 54999/14466Kbps @ 600m. BQMs - IPv4 & IPv6
|
|
|
My line usually stays in sync for months at a time. I recently upgraded the firmware on my router, but prior to that, noise margin had steadily crept down to a little over 3dB and I was still connected at 80 down and 20 up without any issues. On reconnection I was only able to sync at about 74 down - obviously the target was still about 6dB.
I've recently seen an increase in attainable to over 80 again and am currently synced at 80 down with a margin of 6.3dB. I don't plan to reboot my router any time soon
|
|
|
I have my doubts about the upstream figure, unless it relates to a questionable modem. I say this because with two HG612s I never saw upstream interleaving, on my Billion I do not have upstream interleaving, but on either my ZyXel in modem/router mode or my DrayteK Vigor 130, (sorry I don't remember which and it doesn't matter at this stage even though I could probably find out with 20 minutes research ), it did show a depth of 4 upstream.
Whether or not upstream G.INP is enabled is only determine with certainty if we can find the Bearer 1 stats. I think you are already using telnet to get the stats, so using that isn't the solution. As I remember it, despite whichever of my modems showed this "4", G.INP was not enabled on the upstream.
It could be related to the line being on the new trial which doesn't just include SNR margin but also DLM changes as described in the post WWWombat linked to.
Edited by deleted (Sat 21-Jan-17 22:16:24)
|
|
|
Very true. But we can't tell. We all seem agreed you are almost certainly on the trial, and currently at 5dB.
Let's just hope all goes well for you and the trial overall .
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 54999/14466Kbps @ 600m. BQMs - IPv4 & IPv6
|
|
|
|
Thanks, Bob!
|
|
|
Need to know how long after sync the figures are from
Suspect with the vagaries of moving real time margins rather than target and accuracy of reporting by modems (i.e. differences in how they calculate SNR across the 6 frequency blocks) that old data was a 7dB margin and the new one is a 6dB and not a new low one.
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
No, the downstream SNR margin was 5 dB straight after resync. Also, if you look at the line stats on MDWS, you can see the downstream attainable rate is higher than the rate at a downstream SNR margin of 5 dB which proves that the line now has a downstream SNR margin of 5 dB.
Please can users not make false presumptions before reading the line stats, thanks.
Edited by deleted (Sun 22-Jan-17 10:57:03)
|
|
|
5dB as the current margin looks real enough at http://imgur.com/a/0DQ5l at what time was the resync.
Still not sure, and the FEC plot is interesting, if you have gone down by 1dB wonder how long it will last.
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
I don't understand your post. The resync was at when the uptime figure was 0d 0h 0m.
The FEC plot has always been like that and doesn't concern me seen as DLM monitors CRC's and ES' not FEC's.
Edited by deleted (Sun 22-Jan-17 11:01:05)
|
|
|
You don't get G.INP on the upstream on a stable line this only happens during instability probable best to leave that modem alone for the time being
I thought G.INP is no longer on upstream say openreach?
|
|
|
|
Not true. Upstream G.INP is active on some lines connected via a Huawei cabinet.
|
|
|
maybe to many errored seconds has been seen by the DLM on the upstream and maybe the reason why your modem has resynced at those lower snrm values who knows
Make no different as mine was 67342 ES on the upstream
|
|
|
|
That's worrying! Over what duration?
|
|
|
No, the downstream SNR margin was 5 dB straight after resync. Also, if you look at the line stats on MDWS, you can see the downstream attainable rate is higher than the rate at a downstream SNR margin of 5 dB which proves that the line now has a downstream SNR margin of 5 dB.
Please can users not make false presumptions before reading the line stats, thanks.
I don't think you are not on the trial because it would put u on downstream target SNR at 3 dB as your 5 dB got nothing to do with openreach New SNR Margin On FTTC Line Connected To Huawei Cabinet.
|
|
|
That's worrying! Over what duration?
392 days!
|
|
|
I don't think you are not on the trial because it would put u on downstream target SNR at 3 dB as your 5 dB got nothing to do with openreach New SNR Margin On FTTC Line Connected To Huawei Cabinet.
Sorry, I can't understand this post as it doesn't make any sense. The line is definitely on the trial. You can see this if you look at the line stats on MDWS. If a line is included in the trial the downstream SNR margin doesn't have to be set at 3 dB, it can be 3, 4 or 5 dB.
Edited by deleted (Sun 22-Jan-17 15:07:42)
|
|
|
ok, we have to keep an eyes on it! I be shocked if DLM decided to try target 4 dB at the next level if the line remain stable!
I used to be on MDWS but not anymore because I can't view everyone's on it. Only myself can see it.
Edited by adslmax (Sun 22-Jan-17 12:33:03)
|
|
|
Sorry, but why would that be the case? That's not how lines work. The more stable a line is, the lower the SNR margin's are set not the opposite!
Edited by deleted (Sun 22-Jan-17 12:34:58)
|
|
|
I used to be on MDWS but not anymore because I can't view everyone's on it. Only myself can see it.
That is wrong. You can select another line either by the individual username, or you can see everyones lines in the multi user view.
|
|
|
|
I presume you've got to have an account though?
|
|
|
I presume you've got to have an account though? Correct.
100% Linux and, previously, Unix.
|
|
|
|
Yes u have to pay for it first by donate £10 or more which I ain't doing this.
|
|
|
|
No, you don't have to pay anything, that's only if you want access to more than 5 days of data.
|
|
|
No, the downstream SNR margin was 5 dB straight after resync. Also, if you look at the line stats on MDWS, you can see the downstream attainable rate is higher than the rate at a downstream SNR margin of 5 dB which proves that the line now has a downstream SNR margin of 5 dB.
Please can users not make false presumptions before reading the line stats, thanks.
I don't think you are not on the trial because it would put u on downstream target SNR at 3 dB as your 5 dB got nothing to do with openreach New SNR Margin On FTTC Line Connected To Huawei Cabinet.
No Sir, they are trialling profiles with 3, 4 and 5 dB margin.
|
|
|
|
Exactly. adslmax, please can you read up on the facts before posting inaccurate content. It would help us all out. Cheers.
|
|
|
Just 1ES for William in the last 24hrs. I wonder if 4dB could on the horizon for his line?
http://imgur.com/a/f3inz
Edited by deleted (Sun 22-Jan-17 20:05:29)
|
|
|
|
Yes, I reckon it's possible. I'm eagerly waiting for the next DLM resync on the line.
|
|
|
|
If DLM decides to drop the downstream SNR margin further, when would I expect to see this happen?
|
|
|
Given this is a trial of a new feature, and yours is the first probable example, the probability of anyone having any idea of the answer is somewhat low  . Except it would probably be overnight rather than in the daytime.
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 54999/14466Kbps @ 600m. BQMs - IPv4 & IPv6
|
|
|
|
Fair enough, but then the downstream SNR margin was set to 5 dB in the daytime so why would it be different?
|
|
|
Ermmm. I plead the 5th Amendment.
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 54999/14466Kbps @ 600m. BQMs - IPv4 & IPv6
|
|
|
|
The upstream seems to have gone a bit haywire, though it tends to be when it's sunny, I've no idea why.
|
|
|
|
Ah, I forgot to say that the downstream BRAS rate didn't increase correctly, let's hope it's corrected on the next resync.
|
|
|
Ah, I forgot to say that the downstream BRAS rate didn't increase correctly, let's hope it's corrected on the next resync. Do you mean the IP Profile? What is the current sync and IP Profile?
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 54999/14466Kbps @ 600m. BQMs - IPv4 & IPv6
|
|
|
Yes. 45327/41.35.
Edited by deleted (Tue 24-Jan-17 20:20:54)
|
|
|
41.35 is higher that you would have had with the "Before" figures in your OP, but low for 45327. The 45327 is in the "After" stats there. Have you checked it hasn't fallen since?
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 54999/14466Kbps @ 600m. BQMs - IPv4 & IPv6
|
|
|
|
No, it hasn't.
|
|
|
Ah.
Now I understand your previous post. I took it to mean it hadn't adjusted at all.
I need to repeat some arithmetic I did a couple of weeks ago. The result was written in a newspaper margin. Which is now where ...?
I have had an anomalous IP Margin for a while, Mine has a consistent percentage error, and I have a clue as to why. I need to check it out again and compare with your percentage anomaly. If they are the same, we will have an interesting fact.
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 54999/14466Kbps @ 600m. BQMs - IPv4 & IPv6
|
|
|
Yes, the downstream SNR margin on the line is now at 4 dB!
Though, I'm not impressed with the downstream line rate, the line must've synced up at a bad time, typical hey! 
Oh, and the IP profile is 42.3 Mbps, which is incorrect.
Edited by deleted (Wed 25-Jan-17 15:34:19)
|
|
|
A resync today looks to have moved this to 3dB.
There's still plenty of FEC and retransmission going on, but it isn't resulting in anything becoming a CRC (save for a side-effect of the resync itself) or an ES.
https://s24.postimg.org/bk3y7d485/William5_4_3d_B.png
The SNRM moves around some, around 1dB, so we should see the outcome...
Edited by deleted (Fri 27-Jan-17 18:03:16)
|
|
|
And .... breathe out again.
The line seems to have resync'd, but this time it is not good news.
https://s28.postimg.org/8k9duiu6l/William5_4_3d_B_2n...
It looks like the SNRM target has gone back to 6dB, and DLM has intervened: downstream G.INP (with INP=55) has been deactivated, and plain FEC+interleaving has been turned on (with INP=3). Upstream has lost G.INP but has not gained FEC+interleaving.
As a consequence, speed has not just gone down, but gone down to below the starting point (William report a "before" sync speed of 41Mbps; now it is 36Mbps.
Why?
No obvious reason.
|
|
|
That's the way of DLM a horrible way! Oh by the way BT Openreach loving this, quickly reduced sync but have to wait for a very long time before higher sync.
I think it time to calling on BT Openreach to scrap DLM on FTTC only.
I mean what the point of having DLM on all FTTC? Pretty daft to be honest!
Edited by adslmax (Sun 29-Jan-17 15:45:00)
|
|
|
|
most of the before sync speed has been lost after g.inp was turned off for interleaving so was this a 3dB trial certainly looked the part if it was then the trial has major issues that will need addressing
|
|
|
I wonder if the trial has ended and the trialling lines' DLMs reset?
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 54999/14466Kbps @ 600m. BQMs - IPv4 & IPv6
Edited by RobertoS (Sun 29-Jan-17 16:57:17)
|
|
|
|
not impressed with the gains from 5dB to 4dB it is only when you get to 3dB then it shows some promise
|
|
|
|
My line gained 4Mbps going from 6dB to 5dB
|
|
|
I mean what the point of having DLM on all FTTC? Pretty daft to be honest!
I could explain it to you, but then I'd have to shoot you.
|
|
|
not impressed with the gains from 5dB to 4dB it is only when you get to 3dB then it shows some promise
The line exhibited some amount of variation of SNRM over the course of a day, around 1dB, so the actual gain of any one resync was partially masked or enhanced by the underlying line conditions at the time. You need to be able to see beyond that.
In a static environment, the gain should be pretty equivalent for each dB.
Edited by deleted (Sun 29-Jan-17 21:10:36)
|
|
|
I could explain it to you, but then I'd have to shoot you.
is that a threat or hate crime?
|
|
|
This variation was why I was not getting terribly excited by the possibility of this being a low margin trial line to shout about, if it was that
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
That's the way of DLM a horrible way! Oh by the way BT Openreach loving this, quickly reduced sync but have to wait for a very long time before higher sync.
I think it time to calling on BT Openreach to scrap DLM on FTTC only.
I mean what the point of having DLM on all FTTC? Pretty daft to be honest! It might not be the best system I've seen, but scraping it is a ridiculous suggestion. What do you suggest they do? Make all lines run fastpath, resulting in huge packet loss for longer noisy lines or lines with problems. Alternatively just add FEC & high interleaving to everyone's line, because who cares about latency right?
Ideally they should give ISP's more control. They should be able to perform resets, set target SNRM, or like some LLU ADSL2 providers turn it off for individual lines. Getting rid of it altogether would cause a mass of problems.
|
|
|
|
Are you from the real world?
How on earth could it be a hate crime?
It's a little known thing called a joke.
|
|
|
It's a little known thing called a joke.
Indeed, given the secrecy with which BT treats DLM. The post is also born from the same frustration shown by J0hn83. Chicken little thinks the sky has fallen in, so throws the baby out with the bathwater. Just to mix a few metaphors.
I didn't realise the first saying originated with Sherlock Holmes though.
|
|
|
This variation was why I was not getting terribly excited by the possibility of this being a low margin trial line to shout about, if it was that
It wasn't obvious at first, but when you take the three (SNRM-reducing) resyncs into account together, it looks like the behaviour I would be expecting on the trial.
But the recovery into FEC+interleaving has been a *dire* step, with higher ES's than any of the profiles that included G.INP. It has even mucked-up the upstream, which hadn't changed one iota.
We can only hope that someone (someone with clout, this is) is monitoring the outcome on this line.
|
|
|
... when you take the three (SNRM-reducing) resyncs into account together, it looks like the behaviour I would be expecting on the trial.
The big issue with a trial like this (and the expansion to all lines later) is to quickly figure out whether you are making gains or causing harm.
I was expecting one or two behaviours when the trial started:
a) That lines progressed from 6 to 5 to 4 to 3 very slowly, as evidence (over lots of lines) grew slowly.
In this mode, BT would likely have to manually authorise each step after reviewing results of the previous step, and setting new thresholds.
b) The lines progressed from 6 to 5 to 4 to 3 and back to 6 quickly, as BT acquired evidence very quickly ... even if some lines went bad for a couple of days.
In this mode, things would then stop for a while, as BT poured over the results, to extract good and bad behaviour, and fine-tuned the process.
It really depends how much evidence BT have gathered from the labs.
|
|
|
Getting rid of it altogether would cause a mass of problems.
In Ireland, Eircom (Open eir now?) don't run DLM on their FTTC setup. To reduce any problems (to them and to their customers), they run at a 9dB SNRM margin instead (or they did, a year ago; I haven't checked recently).
Prior to turning on G.INP and vectoring, they also turned on FEC+interleaving on every line.
Those extra 3dB are worth 2-11Mbps. If we can get away with another 3dB from this trial, it can become 4-22Mbps.
And, as we know, running FEC+interleaving tends to steal another 10% of your line's bandwidth.
DLM could be buying gains of 6-30Mbps.
|
|
|
Not privy to how they are managing the trial DLM, but ready to see if the announced exchanges start to show a change from their history patterns as a collective group.
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
DLM is not a necessity as proven by the likes of BE and ukonline. Even sky in their early days.
But DLM probably saves a fair amount of money on tech support staffing as it will reduce the amount of people complaining about unstable lines.
So DLM as you say is better than perma interleaving, but not as good as fast path without DLM.
|
|
|
|
variable snrm that swings about 1dB over 24 hours then if your put on 3dB then at some point if it goes below 2.5dB then that is a fail on the trial, to me it looks like you need a steady snrm to gain from this 3dB trial which longer lines don't have
|
|
|
if it goes below 2.5dB then that is a fail on the trial,
Do you have a source for that? I've not seen any technical details for the trial.
to me it looks like you need a steady snrm to gain from this 3dB trial
It isn't a 3dB trial. It is a 3, 4 and 5dB trial.
If the line can't cope with 3dB but can cope with 4dB, then DLM should leave it at 4dB. And it'd still gain.
which longer lines don't have
What counts as "longer" in the context of FTTC?
In ADSL days, I had a line whose SNRM barely moved, on 2.2km of cable. There are very few FTTC subscribers on 2.2km of cable.
Is length much of an indicator?
|
|
|
What counts as "longer" in the context of FTTC?
In ADSL days, I had a line whose SNRM barely moved, on 2.2km of cable. There are very few FTTC subscribers on 2.2km of cable.
Is length much of an indicator?
I know of one group customers with around 3 km FTTC lines there could be around 10 to 15 of them along with another 10 or 20 at around 2.5 km
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
I know of one group customers with around 3 km FTTC lines there could be around 10 to 15 of them along with another 10 or 20 at around 2.5 km
Aye, it can happen - I've even heard of 4km - but for such lines it becomes more important what the electrical length is that the physical length.
Use of 0.9mm copper, for example, can make a line behave electrically like one that is a third to a half of the physical length that uses plain 0.5mm copper.
Who gets 0.9mm copper? Places which would have presented problems in receiving a voice signal: places well over 5km from the exchange. You'd guess they were predominantly rural.
|
|
|
I dont think length is a sole cause of varying snrm.
In my adsl days both me and a friend had very similar attenuation which was 50db. His line was pretty stable and hardly any snrm fluctuations, this I believe was due to him having good copper and the entire line been underground, whilst mine was all over the place.
On FTTC short lines have and do get snrm fluctuations which can be caused by disturbers turning their modems on and off as well as things like electrical interference.
|
|
|
The next houses - another 500m away have no FTTC!
Exchange is around 9km away ... and may be more. Yes, it is almost certainly .9mm = provided Zarjaz gets it right!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
|
for me, g.inp has always shown interleave, even when its not currently active, i dont know why, im guessing its just a bug.
without interleave i had about 10-12ms, with interleave it was around 20ms.
dlm is the devil, luckily g.inp stopped it for me.
im hoping to see a new target of 3db for my area, due to the fact crosstalk dropped my max sync almost 15Mbps in one hit.
im in the process of going back to vdsl, virgin media sucks, especially latency wise.
|
|
|
The next houses - another 500m away have no FTTC!
Exchange is around 9km away ... and may be more. Yes, it is almost certainly .9mm = provided Zarjaz gets it right!
In truth, the full length of a phone line probably has a variety of gauges - perhaps 0.4mm or less for the first couple of hundred yards out of the exchange (to help minimum the physical duct space needed), then switched to 0.5mm to the PCP, which then splits ... so D-sides for close properties can be 0.5mm, and D-sides for really remote get 0.9mm.
The maximum physical length might depend just what proportion of 0.5mm copper gets used, and how much 0.9mm.
In one previous property, a detached house on an estate built in 1995, you got estimates consistent with 0.5mm copper. However, the estate also had a few small blocks of flats ... and those had estimates that were markedly better than the neighbouring houses. The best conclusion was that the flats got fed with 0.6mm D-side cables, while all the houses got 0.5mm.
|
|
|
for me, g.inp has always shown interleave, even when its not currently active, i dont know why, im guessing its just a bug.
DLM always sets up a G.INP retransmission line with small amounts of interleaving and FEC; in this mode, the "small amount" seems to cause about 0.2ms of extra latency, so probably isn't noticeable.
Prior to G.INP retransmission, DLM could only choose to add FEC and Interleaving at relatively high levels, that tended to cause 8, 12 or 16ms of extra latency. Very noticeable.
dlm is the devil, luckily g.inp stopped it for me.
Strictly, DLM is what gave you G.INP retransmission. Retransmission is just one of the "tools" that DLM can activate to keep your line stable.
|
|
|
G.INP when available kicks in generally to replace the high levels of interleaving that Openreach DLM imposes when too many errors are occurring on Fast Path. It does not remove interleaving completely.
Its most common setting is to reduce interleaving to depth 8. We see the occasional 4 and 16s. At the same time it removes the "Delay" that normal interleaving add to the Fast Path latency. The delay introduced by normal interleaving is usually 8ms. I think I have seen a few of 16ms.
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 54999/14466Kbps @ 600m. BQMs - IPv4 & IPv6
|
|
|
you forgot the 0.3 copper and ali lines
I had an engineer tell me he reckons about 1/3 of the network is 0.3 and 0.5+ copper is actually only on a minority of the network. I think he was only talking about my area tho not nationwide.
|
|
|
We know that there is a reasonable amount of large guage in teh last 3km from cabinet to premises. A couple of years back the cable were damaged twice and it took around 3 weeks to restore whilst BT ran new cables for around most of the connection. When that happened, their 300-400k ADSL jumped no near 1Mb ... suggesting a significant lowering of attenuation.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
you forgot the 0.3 copper and ali lines
I think my posts are wordy enough already...
|
|
|
I had an engineer tell me he reckons about 1/3 of the network is 0.3 and 0.5+ copper is actually only on a minority of the network. I think he was only talking about my area tho not nationwide.
I think it very much does depend.
I'm pretty sure the area where I live right now is mostly 0.4mm for most of the E-side and D-side distance. But the buildings here are very much the kind of places that would have been early adopters back in the 20's.
My last place (half a mile away) was very much similar ... but the D-side was different to most surrounding properties. Instead of arriving at the front of the building, underground, it arrived at the back from poles in the alley. That D-side behaved properly for 0.5mm, but the poor ADSL speed suggests the E-side was still 0.4mm. The surrounding houses had poorer estimates, suggesting that the underground feed was probably 0.4mm.
My previous place (other end of the country) was very much spot-on for 0.5mm throughout.
Just to mix things up a bit, here are some records of the E-side feeding a cab.
There is a mix of 0.32mm, 0.4mm and 0.5mm copper, but there is also a mix of 3 separate cables where the gauges are used for differing proportions
http://forum.kitz.co.uk/index.php/topic,16585.msg306...
|
|
|
It looks like the SNRM target has gone back to 6dB, and DLM has intervened: downstream G.INP (with INP=55) has been deactivated, and plain FEC+interleaving has been turned on (with INP=3). Upstream has lost G.INP but has not gained FEC+interleaving.
As a consequence, speed has not just gone down, but gone down to below the starting point (William report a "before" sync speed of 41Mbps; now it is 36Mbps.
Two days on, and the massive FEC+interleaving intervention has gone again.
G.INP has been restored on downstream, but with a lower INP of 48 (instead of 55). Upstream is on fastpath.
Sync speed has returned to the original 41Mbps.
|
|
|
That is exactly what I would expect, as in my earlier post when it went back to "off trial":- I wonder if the trial has ended and the trialling lines' DLMs reset? DLM reset, nothing for two days as per an initial activation but interleaving applied under the 24/7 principle, (the two days wait before intervention in SIN498 clearly referring to banding rather than "normal" adjustments), then G.INP kicks in to override the interleaving.
Whether the trial has ended overall, or this line has proved unsuitable for a lower SNRM, or the required data has been gathered from this line so no longer needed on the trial, is a different question.
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 54999/14466Kbps @ 600m. BQMs - IPv4 & IPv6
|
|
|
I agree with you, I think they simply disabled the trial on his line and as such a DLM reset back on current rollout config.
|
|
|
|
Agreed. On a sample of 1, the answer to the question is unknowable.
|
|
|
|
the operator had g.inp on the upstream during the so called trial as some of you know this is only applied to a line during a instability event and g.inp on the upstream is then turned off after 2- 4 days this looks more like the action of the DLM rather than the action caused by the snrm trial
|
|
|
|
I'd bet my mortgage his line was in the trial. He uploads 24/7 to MyDSLWebStats and his line showed 100% what would be expected. It showed it on 5dB, then 4dB, and finally 3dB. He's also on an exchange across in the trial.
|
|
|
Yes, and it's back on it once again, round and round we go. Watching the line has been quite interesting! Let's just hope that when/if the downstream SNR margin drops to 3 dB that 2 days later a DLM reset doesn't occur. Though, like Bob said, I think the DLM reset occurred because that trial had ended.
Edited by deleted (Tue 07-Feb-17 16:50:21)
|
|
|
|
My FTTC have been re-sync this morning. That's the first time since 2014 February that my full rate of 79999k is now reduced possible the cabinet is full or SNR trial or crosstalk?
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 6.2 6.4
Attenuation (dB) 11.3 0.0
Output Power (dBm) 12.4 -1.2
Attainable Rate (Kbps) 78575 23977
Rate (Kbps) 76437 19999
B (# of bytes in Mux Data Frame) 130 237
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 42
R (# of redundancy bytes in the RS codeword) 8 16
S (# of data symbols over which the RS code word spans) 0.0518 0.3781
L (# of bits transmitted in each data symbol) 21468 5374
D (interleaver depth) 16 1
I (interleaver block size in bytes) 139 127
N (RS codeword size) 139 254
Delay (msec) 0 0
INP (DMT symbol) 48.00 0.00
Download speedachieved during the test was - 69.7 Mbps
For your connection, the acceptable range of speedsis 40 Mbps-73.90 Mbps .
Additional Information:
IP Profile for your line is - 73.90 Mbps
|
|
|
That's most likely crosstalk, however the interleaver depth is 16 which is higher than the normal 8, so could be DLM intervention. Do you remember seeing your downstream attainable rate being lower than the rate before the resync?
Edited by deleted (Tue 07-Feb-17 21:53:29)
|
|
|
|
Before resync:
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 6.3 6.1
Attenuation (dB) 11.3 0.0
Output Power (dBm) 12.4 -1.2
Attainable Rate (Kbps) 85528 28977
Rate (Kbps) 79999 19999
B (# of bytes in Mux Data Frame) 130 237
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 42
R (# of redundancy bytes in the RS codeword) 8 16
S (# of data symbols over which the RS code word spans) 0.0518 0.3781
L (# of bits transmitted in each data symbol) 21468 5374
D (interleaver depth) 16 1
I (interleaver block size in bytes) 139 127
N (RS codeword size) 139 254
Delay (msec) 0 0
INP (DMT symbol) 48.00 0.00
|
|
|
|
interleaver depth is 16 is always still the same since G.INP put on my line can't remember when was it.
|
|
|
Thanks. Seen as the interleaver depth was 16 then it's either crosstalk or a slight degradation in line quality.
It's set at 16 because DLM thinks your line needs more continuous noise but less impulse noise protection (INP).
Edited by deleted (Tue 07-Feb-17 22:00:17)
|
|
|
|
Don't think it not my line quality, probably crosstalk? I asked Plusnet to test my FTTC via GEA test from BTw and they found nothing wrong with my line and can't tell if it was crosstalk. They can't reset my FTTC.
|
|
|
Yes, I would say it's crosstalk then. 
|
|
|
|
What's the estimation for the line from the Wholesale DSL checker?
|
|
|
My line is getting worse.
Not happy with overall speed.
http://www.thinkbroadband.com/speedtest/results.html...
|
|
|
|
Probably a stupid question, but was that test conducted wired?
|
|
|
High Low High Low
VDSL Range A (Clean) 80 61.5 20 20 55 Available -- -- Yes --
VDSL Range B (Impacted) 70.8 40 20 13.2 32.4 Available -- -- Yes --
Edited by adslmax (Tue 07-Feb-17 22:05:01)
|
|
|
Probably a stupid question, but was that test conducted wired?
yes via ethernet
How to tell if the cabinet is on crosstalk how many percent does the cabinet take up?
Where is Ribble? He probably know more!
Edited by adslmax (Tue 07-Feb-17 22:07:16)
|
|
|
|
Ah ok, that's probably just congestion or some other factor, nothing to do with your line if it's stable.
|
|
|
|
Until you drop below 61.5meg sync. No fault.
|
|
|
The fact your attainable has dropped by 7mb but the SNRM is lower would initially suggest an additional crosstalker.
The number of users on the cabinet isn't the main factor with crosstalk. It's the copper pairs next to yours in the bundle that causes crosstalk. A neighbour who's line is close to yours in the bundle may have just signed up for FTTC. If that's the case then your line will likely remain roughly where it is now.
A single resync isn't enough to tell for definite though. It could be another source of noise on the line. Do you have a QLN graph before and after? Do you run DslStats or HG612_Modem_Stats? If so did the SNRM or attainable drop before the resync?
With the advice out of the way, is it really that big a deal? Many users would love to sync at those levels. I very much doubt if you weren't looking at the stats that you could ever tell the difference. Asking an ISP to run a GEA test because you sync a couple mb below the maximum is a bit excessive.
Edited by j0hn83 (Tue 07-Feb-17 23:07:34)
|
|
|
|
I am paying for the service 80/20 not 61/20 as I did sign up on BTw estimated of 80/20 last Feb 2014 but it rather annoyed me when BTw change to 61/20.
|
|
|
Thanks. Seen as the interleaver depth was 16 then it's either crosstalk or a slight degradation in line quality.
It's set at 16 because DLM thinks your line needs more continuous noise but less impulse noise protection (INP).
I'm not sure that's correct. Needs more continuous noise? Less protection?
DLM actually sets the INP parameter, which has remained at 48 across the resyncs. It is that parameter that tells the DSLAM and modem how much impulse noise protection is required, and (via the delay parameter) how much additional latency can be used to achieve that protection.
The interleaving depth and block-size are chosen by DSLAM and modem during sync, alongside the FEC blocksize and parity sizes, and the retransmission parameters, in order to achieve that amount of protection.
IMO, the interleaving depth is chosen by the modem to be as high as it can be while still achieving "delay=0", so it probably reduces if the sync runs the risk of a latency delay getting above 0.5ms. If the depth changes amongst 4, 8 or 16, it is almost certainly a side-effect of other changes.
|
|
|
Needs more continuous noise?
No, I said the opposite.
Edited by deleted (Wed 08-Feb-17 07:12:13)
|
|
|
|
Post deleted by WilliamGrimsley
|
|
|
|
You're paying for a connection, of UP TO 80mbps with an estimated sync speed range of 61.5-80mbps on a clean libe.
Stop obsessing with speeds and stats, and just use the internet.
|
|
|
Stop obsessing with speeds and stats, and just use the internet. Given that for a considerable period he used to run frequent speed tests, and if following a few perfectly good ones he got a fractionally worse one would migrate because the ISP was no good, that isn't going to happen.
/me @ adslmax
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 54999/14466Kbps @ 600m. BQMs - IPv4 & IPv6
|
|
|
Seriously? 
|
|
|
Seriously.
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 54999/14466Kbps @ 600m. BQMs - IPv4 & IPv6
|
|
|
Fair enough, whatever rocks your boat I suppose!
|
|
|
What a life he must lead
|
|
|
Don't mock. I have considerable regard for adslmax. Eccentric, often posts fiction, sometimes comes up with good stuff that the rest if us didn't know or hadn't thought of. Which to various degrees is surely a description that can be applied to all of us, barring the fiction bit that we try not to.
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 54999/14466Kbps @ 600m. BQMs - IPv4 & IPv6
|
|
|
|
Line has been resync again this morning
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 3.3 6.0
Attenuation (dB) 11.3 0.0
Output Power (dBm) 12.4 -1.2
Attainable Rate (Kbps) 80249 29133
Rate (Kbps) 79999 19999
B (# of bytes in Mux Data Frame) 130 237
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 42
R (# of redundancy bytes in the RS codeword) 8 16
S (# of data symbols over which the RS code word spans) 0.0518 0.3781
L (# of bits transmitted in each data symbol) 21468 5374
D (interleaver depth) 8 1
I (interleaver block size in bytes) 139 127
N (RS codeword size) 139 254
Delay (msec) 0 0
INP (DMT symbol) 49.00 0.00
|
|
|
Aha, you're on the new trial!
|
|
|
I don't know! I have no idea!
My speed has returned to max speed.
http://www.thinkbroadband.com/speedtest/results.html...
|
|
|
|
Praise the lord!
|
|
|
|
IP Profile isn't picked up by BTw.
FAQ
Results Image not loaded
1. Best Effort Test:
Download Speed : 74.96 Mbps
2. Upstream Test:
Upload Speed : 17.67 Mbps
Your speed test has completed and the results are shown above, however during the test an error occurred while trying to retrieve additional details regarding your service. As a result we are unable to determine if the speed you received during the test is acceptable for your service. Please re-run the test if you require this additional information.
|
|
|
Yes, the IP profile is being set too low on lines in the trial. LOL.
Edited by deleted (Wed 08-Feb-17 16:25:08)
|
|
|
In what way please? Or more correctly, to what extent and what evidence?
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 54999/14466Kbps @ 600m. BQMs - IPv4 & IPv6
|
|
|
Because the IP profile is set at 96.69% if the line has G.INP and the IP profile is currently set lower if a line is in the trial...
Edited by deleted (Wed 08-Feb-17 17:18:50)
|
|
|
My IP Profile has been lower than expected for a while, and I am definitely not on the trial.
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 54999/14466Kbps @ 600m. BQMs - IPv4 & IPv6
|
|
|
|
Interesting, I only noticed this when my line was on the trial. I wonder why it's set wrong?! Is there a way to report this error?
|
|
|
|
I have emailed Openreach to find out if my cabinet are one of the trial for new SNR Margin on my FTTC. I didn't realize that my SNR has drop to 3 dB.
Case Reference : C******** for Customer
**************@openreach.co.uk
19:07 (5 minutes ago)
to me
Dear Customer
Thanks for contacting us.
We have given a reference number to your issue and it�s C***********. This number is unique to your issue so if you do contact us about it again, please quote this reference to us.
We need to look into the detail of your issue in order to advise you appropriately so we�ll be back in touch with you within 5 days.
Thank you
Openreach Team
|
|
|
|
Are you located in Devon or Somerset?
|
|
|
|
No, I live in Telford, Shropshire. Exchange is Cuckoo Oak.
|
|
|
|
Ah, good old Cuckoo Oak. It may be that their expanding the trial.
|
|
|
|
I don't think Cuckoo Oak isn't on trial. That's why I was wonder why is my FTTC got downstream of 3dB SNR?
Nov 16 - 11.7dB
Dec 16 - 9.9dB
Jan 17 - 6.9dB
Feb 17 - 3.3dB
|
|
|
|
I would have expected you to start on 5dB, then 4dB, then 3dB.
Being outside the trial area and going straight to 3dB i would be hesitant to jump to conclusions.
FTTC lines have been running at 3dB long before any new target was set.
|
|
|
|
Really?! I thought this was a new introduction?
|
|
|
FTTC lines have been running at 3dB long before any new target was set. Are you sure about that? You aren't by any chance thinking of ADSL2+ lines?
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 54999/14466Kbps @ 600m. BQMs - IPv4 & IPv6
|
|
|
|
as far as i know there has been lines that were set direct to the snrm of 3dB that was going on last year this was a random trial test on vdsl
|
|
|
FTTC lines have been running at 3dB long before any new target was set. Are you sure about that? You aren't by any chance thinking of ADSL2+ lines?
I mean from noise, crosstalk, rebooting DSLAM's etc. The target margin is new, seeing a line at 3dB is NOT. Just because a line is at 3dB does not mean it's on a trial, especially on an exchange not on the trial list.
|
|
|
Perhaps your earlier post could have explained that.
Quite apart from the fact that noise margin varies after sync, which most people are more than slightly aware of, is hardly pertinent in the context. A pointless and confusing post to those who don't know.
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 54999/14466Kbps @ 600m. BQMs - IPv4 & IPv6
|
|
|
|
Well, to say his line's downstream attainable rate was higher than the downstream rate would prove that the downstream SNR margin was set at 3 dB. What's bizarre is why it dropped from 6 to 3 dB in one resync. It could be that Openreach have already started the rollout nationwide and the downstream SNR margin could be set at 3 dB in one resync instead of having a stepped approach.
|
|
|
I'm not closely following the argument at the moment, but the settings and varying of them on each line involved in a trial are very likely to differ. Though groups of lines with the same pattern are probable.
So a line starting at 5, then later dropping to 4, then finally 3 is one option. Starting at 3 is another. In both cases then seeing what DLM does, if both those lines are expected to be stable at 4dB.
Guessing how the trial is constructed is impossible.
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 54999/14466Kbps @ 600m. BQMs - IPv4 & IPv6
|
|
|
|
Well said, Bob.
|
|
|
Guessing how the trial is constructed is impossible.
+1.
"BT and chill." Pass the popcorn...
|
|
|
|
Another resync again this morning look like DLM is doing my line [censored] all this week.
xDSL
Mode VDSL2
Traffic Type PTM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 4.5 6.1
Attenuation (dB) 11.3 0.0
Output Power (dBm) 12.4 -1.2
Attainable Rate (Kbps) 85243 29858
Rate (Kbps) 79999 19999
B (# of bytes in Mux Data Frame) 130 237
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 42
R (# of redundancy bytes in the RS codeword) 8 16
S (# of data symbols over which the RS code word spans) 0.0518 0.3781
L (# of bits transmitted in each data symbol) 21468 5374
D (interleaver depth) 8 1
I (interleaver block size in bytes) 139 127
N (RS codeword size) 139 254
Delay (msec) 0 0
INP (DMT symbol) 49.00 0.00
|
|
|
|
What modem are those stats being gathered from?
|
|
|
|
Another resync this morning.
xDSL
Mode VDSL2
Traffic Type PTM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 6.9 15.0
Attenuation (dB) 11.3 0.0
Output Power (dBm) 12.4 -1.2
Attainable Rate (Kbps) 85467 28750
Rate (Kbps) 79999 19999
B (# of bytes in Mux Data Frame) 130 237
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 42
R (# of redundancy bytes in the RS codeword) 8 16
S (# of data symbols over which the RS code word spans) 0.0518 0.3781
L (# of bits transmitted in each data symbol) 21468 5374
D (interleaver depth) 16 1
I (interleaver block size in bytes) 139 127
N (RS codeword size) 139 254
Delay (msec) 0 0
INP (DMT symbol) 48.00 0.00
|
|
|
What modem are those stats being gathered from?
Billion BiPAC 8800NL firmware: 2.32d.dh14
|
|
|
Ok, now the upstream SNR margin is set to 5 dB!
Edited by deleted (Tue 14-Feb-17 08:29:03)
|
|
|
|
Post deleted by radiomarko
|
|
|
Is it possible that i could be on the trial? I have had BT infinity 2 for almost 2 years now and my line speed has never been more than 66Mbps in the the last week i have noticed my download speeds are a bit faster than usual. I checked my router page and the line is now syncing at almost 74Mbps.
Here`s a screenshot of my router
http://imgur.com/a/EurgR
Edited by deleted (Thu 16-Feb-17 21:29:09)
|
|
|
|
With a 6.1SNR that would be a no.
You do seem to have G.INP enabled though which is the likely reason.
|
|
|
Probably as Lee says. In the past, did you have interleaving on instead of Fast Path?
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 56203/14254Kbps @ 600m. BQMs - IPv4 & IPv6
|
|
|
Probably as Lee says. In the past, did you have interleaving on instead of Fast Path?
No. it has always been fastpath
|
|
|
That's strange. As far as I know G.INP only gets activated to largely replace interleaving. But the "largely" is important as G.INP doesn't come with Fast Path - or didn't until now . It drops the interleaving depth to 4, 8 or 16 and removes the additional latency that normal interleaving brings.
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 56203/14254Kbps @ 600m. BQMs - IPv4 & IPv6
|
|
|
|
G.INP always comes with interleaving. It's a reporting error.
|
|
|
Im not too clued up on the technical side of how fibre works so im not sure what all this means. But any increase in download/upload is a good thing in my book
|
|
|
|
Yes, G.INP being activated would've caused that. Enjoy.
|
|
|
That's strange. As far as I know G.INP only gets activated to largely replace interleaving. But the "largely" is important as G.INP doesn't come with Fast Path - or didn't until now . It drops the interleaving depth to 4, 8 or 16 and removes the additional latency that normal interleaving brings.
Beware...
During last year's abortive attempt to turn on G.INP on ECI cabinets, I recall seeing that G.INP came with interleaving depth of 1. IIRC, it still used some amount of FEC protection, but didn't use interleaving.
BT are expected to re-start the ECI trial soon, so we could be seeing that here. Switch-on of G.INP, on a line that was "only" fastpath before, might explain a speed increase too.
However...
That screenshot looks like an ASUS modem ... and I always mistrust what the ASUS devices say about the VDSL2 status.
Altogether, a healthy dose of careful "wondering" about the options is warranted.
|
|
|
It looked rather like my ASUS screens as well. But that's a router, not modem router, so I couldn't see what it reports for me even if I was using it.
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 56203/14254Kbps @ 600m. BQMs - IPv4 & IPv6
|
|
|
However...
That screenshot looks like an ASUS modem ... and I always mistrust what the ASUS devices say about the VDSL2 status.
Altogether, a healthy dose of careful "wondering" about the options is warranted. Absolutely spot on. The Asus modems always report fastpath and interleave depth 1 with G.INP enabled. You can just pretty much ignore every stat the Asus's report. Look at the Max Rate (attainable), remembering that line is already syncing 8mb higher than usual. My DSL-AC68U reported my max rate about 20mb higher than sync.
That screenshot also looks like a possibly banded line, though hardy an issue having banding well above the usual sync.
I'd be inclined to try another modem on that line if it were mine, especially if you've been using the Asus for the 2 years you've never synced above 66mb.
|
Pages in this thread: 
Print Thread
