Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Black Sheep on April 03, 2017, 08:11:27 PM
-
I was thinking about something Mr Cat mentioned on the forums a while back, about 'Attainable synch' being simply a theoretical value.
It certainly answered the reason why, when at the EU's premises I've seen the 'Attainable' speed on my JDSU different from the 'Actual' final speed acquired, even when a fault had been rectified.
My query is, a handful of times over the years when the EU has generally had multiple engineering visits about a drop in speed, our DCoE use this 'Attainable' figure as a yardstick when looking to perform a 'Lift & Shift' ?? I can absolutely confirm that I do get variable 'Attainable' readings when sat right on top of the DSLAM. How can this be if it is purely theoretical ?? The attenuation will be very similar and obviously a small integer such as 1.2dB for example. What else does the 'Attainable' theorise about ??? It's doing my nut in. :-X :) :)
-
The attainable rate calculation is based on the modem's assessment of the line conditions, the SNR measurements, which would be affected by crosstalk and any other noise.
-
Attainable and Sync are normally 1/1 until my line is on Interleaving or when the RFI lowers the the SNRM in the evening
-
Same here my Current is 44 and attainable is 54 with a 6db margin and interleaving, although my ISP has told me it should be off.
-
The attainable rate calculation is based on the modem's assessment of the line conditions, the SNR measurements, which would be affected by crosstalk and any other noise.
That was my line of thought as well, ejs, but surely when I test at the cabinet, the SNR would be pretty much similar for all ports ??? Yet I can have differences of 'Attainable' by over 45Mbps !!
Surely there must be some kind of actual measured calculation going on somewhere ?? :'(
-
Why would 'interleaving' include an increase in overheads ? If 'interleave depth' is meant, then it can't cause any difference, other than latency obviously, if the use of terms is anything like that in G.992.3 (because I have not yet got around to reading the VDSL2 spec). What am I not understanding? Total guess: Perhaps this is something that comes along for a free ride in a _DLM profile_ called something like 'interleave'? If so then it's not a very helpful name.
-
I was thinking about something Mr Cat mentioned on the forums a while back, about 'Attainable synch' being simply a theoretical value.
It might have been from me, although I have no memory of mentioning it. ??? Could it, perhaps, have originated from WWWombat? :-\
-
I definitely recall reading a comment from yourself regarding this, Mr Cat ......... not a clue in which post/thread though ??
I'm not questioning its validity in any way whatsoever, I'm just keen to understand how the 'Attainable' is actually derived ? :) :)
-
Its a projected figure. Calculation should in theory be based on the current line conditions and Target SNRm but without any INP/Interleaving or rate limiting.
Actual can be affected by such things as banding, rate limiting, type of product ie 40/10 or INP.
The BCM chipset modems dont appear to do a very good job at projecting the attainable though if the line already has INP applied. :(
I think I know why this is - its possibly something to do with broadcoms interpretation of the 'SNR gap'. I believe they may be using the lines current SNR gap rather than recalculating one without INP.
There was a topic about this a couple of weeks ago which I need to go back to and try explain things better.
I'd made the post in a hurry the night before a funeral and as I had a guest staying for a few days, I forgot about it.
-
We have come to take for granted that when a line becomes interleaved Broadcom or ECI the attainable goes skew whiff the reason for this as told is because of overheads a chuck of sync is held back as a buffer but for some reason the modems attainable still sees or thinks that sync is still available to the user that is my penny's worth
-
if on fast path on a fresh sync the attainable and actual sync should be very close to each other unless either snrm has shifted very quickly or the calculation is duff.
On interleaving at least pn broadcom devices the estimator code seems broken and cannot be relied on for anything accurate.
-
Pinched this post made by WWWombat which goes in to a bit of detail when explaining how attainable (ATTNDR) is calculated.
It seems that VDSL2 modems are allowed to do different things.
The current G.993.2 specification includes 2 methods for calculating the attainable rate: a "basic" and an "improved" method. The basic one is mandatory, and the improved one is optional. And there are two variants of the improved method.
Worse, it seems that the one mandatory method, the "basic" one, wasn't fully specified in earlier versions of VDSL2, so the current specification recommends a vendor upgrades - but that recommendation is, of course, not mandatory.
The calculated attainable net data rate (ATTNDR) can be requested from the other end of the link (via messages on the EOC channel).
ATTNDR calculation:
https://s24.postimg.org/l5lzqdvyt/ITU_VDSL2_ATTNDR.png
"Basic" method:
https://s28.postimg.org/imthy6s1p/ITU_VDSL2_ATTNDR_basic1.png
Note that it takes account of "all coding gains", which probably explains why it gets a higher value when FEC is turned on.
"Improved" method:
http://s29.postimg.org/80ygjon47/ITU-_VDSL2-_ATTNDR-improved1.png
If you look at the screenshots of the ITU VDSL2 pages you can see there's a huge amount of info taken into account when calculating ATTNDR. This will go some way to explaining why BS gets different readings even at the cabinet.
-
I can absolutely confirm that I do get variable 'Attainable' readings when sat right on top of the DSLAM. How can this be if it is purely theoretical ??
The attenuation will be very similar and obviously a small integer such as 1.2dB for example. What else does the 'Attainable' theorise about ??? It's doing my nut in. :-X :) :)
Allow me to add some soothing lotion ;)
As in the links that @J0hn posted for me, the determination of max attainable is derived from calculation involving the SNR on all tones. It is a real calculation, not a theory (although some of the allowances it makes in that calculation are based on theory).
The calculation entirely hinges on the SNR on each tone - by which I mean the real signal-to-noise ratio, not the SNRM. (Reminder: SNRM is the margin, or the amount of "unused" SNR after the modem has "used" some of the SNR by deciding how many bits can be carried on a particular tone).
The SNR for each tone can be seen in the SNR/tone graphs on MDWS, and varies from over 50dB down to 6dB.
Why can N vary?
(With the expectation that you make your measurements in the PCP, not in the FTTC cab...)
Crosstalk will already exist on the line, even at the PCP, from the signals being carried on the tie pairs. This noise will increase in proportion to the length of the tie pair, and the number of neighbouring lines carrying a VDSL2 signal.
I'd expect to see more noise on longer tie pairs. I'd expect to see more noise on a line when all 10 pairs in the internal bundle have been allocated, than in a line where the other 9 pairs haven't yet been allocated (if tie-pairs are grouped in 10s, not 25s). I'd expect to see more noise on a line as all the other bundles fill up.
How much? I don't know ... if the JDSU has a QLN graph, it might give you an idea. It wouldn't surprise me if the noise could reach more than a couple of dB on the longer tie pairs. I'd guess that crosstalk from 100m of tie pair will be worse than from 100m of plain D-side, where the disturbers are statistically spread out more. And I certainly get more than 12Mbps-worth of crosstalk on my 100m D-side, where the DSLAM sits side-by-side with the PCP.
Why can S vary?
Two main reasons... One you have mentioned (attenuation), one not mentioned on here yet.
a) The length of the tie pair plays a significant role.
10m distance might put an attenuation of 0.5dB on the line, while 50m might put 2.5dB attenuation on the line, and 100m leaving 5dB (using attenuation as measured on Broadcom VDSL2 chipsets, anyway).
b) The transmission power of the signal varies from tone to tone, and from DSLAM to DSLAM, controlled by the PSD masks that protect the ADSL/2+ spectrum.
Those PSD masks are governed by the distance between DSLAM and exchange. The main controlling factor (as you'd expect) is really the electrical distance, so is measured in dB, and is known as CAL (Cabinet Assigned Loss)
CAL is the loss measured at 300kHz, so is the same as the old attenuation values seen on ADSL modems; I believe Mr Sheep has confirmed this to be 10dB per km of 0.5mm copper. It varies between 0 and 50, in steps of 2. I guess that means it increases for every 200m from the exchange, up to 5km, adjusted for different gauges.
I've attached the graph from the ANFP, which shows how the transmission power is attenuated for some selected CAL levels. The more the power is attenuated, the lower the SNR will be, even when measured at the PCP.
- The red line, CAL=0, doesn't reduce power at all. This is for cabinets within 200m of the exchange, so these should have the best speeds.
- The green line, CAL=20, reduces most power over most frequencies, so is probably about the worst case, where resulting SNR is lowest and speed reductions greatest. This is for cabinets around 2km from the exchange.
- The blue and purple lines, CAL=40 and 50, reduce power over a more limited set of frequencies, so should have lesser speed reductions.
Summary
If you are seeing 45Mbps differences, then I could believe such a value - with the cause split across these 3 aspects.
Overall, your worst case ought to be a cabinet 2km from the exchange, where the DSLAM is furthest from the PCP, and take-up is high on that tie-pair cable.
The best case, conversely, will be with side-by-side PCP and DSLAM, located outside the exchange OR at least 5km from the exchange, measured on the first line being installed.
-
Why would 'interleaving' include an increase in overheads ?
Taking the question at face value: Interleaving alone cannot increase overheads. However, interleaving alone is pointless. The only point of having interleaving is for it to enhance the prospects of FEC working ... so it always comes with FEC, which does come with overheads. But a lot of people are too lazy to mention the FEC side of things, and have, in any case, been taught to look at "interleaving depth" as the tell-tale of a "bad" line.
I'm not 100% sure that you meant the question in the way I answered though, so I'll add more shortly...
-
@Wwwombat - You and I are on the same page, it seems. "Too lazy to mention the FEC side of things" is exactly how I assumed it must be. The irony is that more interleaving is the sign of a happier connection in the face of a line that is subject to noise spikes, so more interleave depth means more reliability and better throughput performance (though of course increased latency) because of fewer wasteful retransmissions. That's the way I see it anyway.
-
The BCM chipset modems dont appear to do a very good job at projecting the attainable though if the line already has INP applied. :(
I think I know why this is - its possibly something to do with broadcoms interpretation of the 'SNR gap'. I believe they may be using the lines current SNR gap rather than recalculating one without INP.
I agree that the Broadcom's seem to be getting something wrong in the area of SNRGAP.
One of the links in @J0hn's post shows SNRGAP to depend on a 10-7 bit error rate (BER) with no coding gain.
As @ejs mentioned recently, turning on FEC has two side effects: one (undesirable) impact is that it adds overhead, but the second (desired) impact is that it decreases the BER. Turning on FEC is a coding gain.
Once FEC is turned on, then adding interleaving can improve things - making a further coding gain.
So, when analysing how many bits can be carried on a tone, the calculation considers how many dB of SNR are needed per bit to achieve that 10-7 BER. If FEC is turned on, then this ratio is affected: more bits can be carried per dB to achieve the same BER. Even more so if interleaving is added to FEC.
The miscalculation of maximum attainable seems to be something to do with this ratio when coding gain has been added.
(So, @Weaver, I'm not sure if your question was really related to how interleaving affects "attainable" rather than "overheads". If so, then this is the reason).
-
@Wwwombat - You and I are on the same page, it seems. "Too lazy to mention the FEC side of things" is exactly how I assumed it must be. The irony is that more interleaving is the sign of a happier connection in the face of a line that is subject to noise spikes, so more interleave depth means more reliability and better throughput performance (though of course increased latency) because of fewer wasteful retransmissions. That's the way I see it anyway.
so more interleave depth means more reliability and better throughput performance (though of course increased latency) because of fewer wasteful retransmissions.
Exactly.
In old-style DLM interventions (heavier FEC/interleaving), then that retransmission was, of course, at TCP level. Layer 4.
In new-style G.INP interventions (very light FEC/interleaving), then FEC and interleaving combine to play the same role - to reduce the retransmissions. Except these ones are at the VDSL2 level - Layer 1.
-
One of the links in @J0hn's post shows SNRGAP to depend on a 10-7 bit error rate (BER) with no coding gain.
So, when analysing how many bits can be carried on a tone, the calculation considers how many dB of SNR are needed per bit to achieve that 10-7 BER. If FEC is turned on, then this ratio is affected: more bits can be carried per dB to achieve the same BER.
That's what I was trying to explain in my other post but obviously not doing a very good job of explaining the whole situation. I was going to try and get some further evidence but didn't have time as my guest arrived right after I made that post, then with the funeral and having to sort out lots of other things totally forgot about it.
My post was here (http://forum.kitz.co.uk/index.php/topic,17498.msg344587.html#msg344587).
What I meant is that Im guessing that when the BCM devices calculate the SNRgap they are using the current SNRgap which includes the current INP figure rather than calculating a separate SNRGAP with INP=0.
I thought I'd found a doc somewhere that appeared to state in amendment 6 clarification that INP=0 should be used. The doc I found that day Im sure specifically said something like 'it had been observed that different vendors had been using different methods'.
-
I do not believe the difference between max attainable net data rate, and actual net data rate, with interleaving+FEC, should be considered a miscalculation, or that the modem is not properly accounting for something. It's the modem answering a hypothetical question of "If the interleaving+FEC parameters could be adjusted for maximum bandwidth, what would the bandwidth be?"
The difference is due to the basic ATTNDR method, which leaves various things unspecified.
ATTNDR then gets calculated based on adjusting the FEC ratio for the maximum coding gain with the minimum overhead, it has to stay within the maximum interleaving delay, but does not have to meet the minimum INP requirement.
The actual net data rate will have to have the FEC and interleaving parameters set to provide at least the minimum INP level specified in the line profile.
so more interleave depth means more reliability and better throughput performance (though of course increased latency)
It's not really the interleaving depth that is the important parameter, it's the delay, and the INP. Think of tickmike's (http://forum.kitz.co.uk/index.php/topic,19512.0.html) recent post, with an interleaving depth of 416, much larger than normal for ADSL2, but with a fairly typical delay of 7.47ms (probably the max delay specified in the line profile was 8ms).
I suspect that the FEC and very small interleaving levels typically used with retransmission (G.INP) are for optimizing the bandwidth from the coding gain, and not really for providing additional noise protection.
-
Thanks one and all for the input thus far, with an extra :congrats: to the Wombat for that in-depth break down. I won't pretend it's all sunk in ..... but most of it has !!! :) :)