Attainable Bandwidth vs Crosstalk

Hi all,

Over time, I've been reporting how my "attainable bandwidth" has been decreasing. As this has happened, my SNRM figure has been dropping. And I have believed this to be caused by increasing crosstalk as usage increases.

My history is, roughly, as follows:

Date      Attain Actual SNRM
01/2012   90     40
02/2012   91     40
02/2012   85     80     7.3dB   * 80/20 package turned on
03/2012   84     80     7.1dB
06/2012   83     80     6.9dB
07/2012   82     80     6.6dB
09/2012   82     80     6.5dB   * Voice fault occurs around here
11/2012   81     80     6.3dB
12/2012   78     80     5.4dB
01/2013   76     80     4.6dB
05/2013   72     80     3.0dB

It has stayed synchronised since the beginning of December, perfectly stable, running at 80Mbps, even as the SNRM has dropped to 3dB.

Last week, I finally bit the bullet, and decided to re-sync my line, even though I expected my sync speed to drop to below 72Mbps.

Imagine my surprise, then, when it resync'ed at 80Mbps with an attainable value of 83Mbps. Over the week since, this attainable figure has dropped some, but is still higher than it was earlier this year.

Date      Attain Actual SNRM
05/2013   83     80     6.7dB
05/2013   79     80     5.6dB

I finally managed to turn some of my graphs into animations to highlight the line conditions. It looks like there has been hardly any change whatsoever.

Bitloading Animation
Hlog Animation
QLN animation
SNR animation

So - is a dropping "max attainable" speed really a reflection on the crosstalk on the line? What else would cause it to drop over time?

Confused...

In reply to a post by WWWombat:

So - is a dropping "max attainable" speed really a reflection on the crosstalk on the line? What else would cause it to drop over time?

Confused...

It's probably very similar to ADSLx DLM in what happens with bit-swapping.

(Broad brush description). If a frequency/bin gets to empty due to bit-swapping away from it, (possibly near empty), due to repeated instances of noise on the line, that frequency gets removed from the available and isn't used again. As and when several frequencies suffer this fate the "Attainable" is bound to decrease, and usually the actual as well.

A re-sync starts from scratch, with all the frequencies that qualify at that time being taken into consideration for attainable and actual use. What happened previously is forgotten.

I cant explain what you seeing but I can assure you the attainable reported my my HG does also reflect actual sync speeds aside from the fact it tends to overestimate a bit by 1-2mbit, so if eg it drops and I resync then the next sync will be lower.

edit, just read Robertos reply and that has logic to it, so is possible your line is disabling tones due to bursts of noise or something.

Edited by Chrysalis (Wed 29-May-13 16:30:20)

Ah. That might be something... I'll see if I can establish anything from the accumulated stats.

That is my experience too, and what I was expecting - something just under the max.

I'll have to check onRoberto's idea.

In reply to a post by RobertoS:

As and when several frequencies suffer this fate the "Attainable" is bound to decrease, and usually the actual as well.

Sure? For the actual to drop you either need SRA to be in place or a full resync, nothing to do with bit swapping?

Pity I didn't read that 25 minutes earlier. I can't edit it now. Of course, you are right. Slip of the brain!

I stand by my thoughts about the change in the attainable though .

Edited by RobertoS (Wed 29-May-13 22:35:20)

I just used the graphing scripts to strip the "bit loading" data for downstream only, and checked your idea out for the 6 month period that the modem stayed in sync (Nov 2012 to May 2013).

It originally had 22 tones where zero bits were allocated, and this became 36 tones at the end of the 6 month period.

Unfortunately, there was a single tone that started with zero bits, that was then allocated some bits part-way through.

The 15 "newly-zero" tones all dropped from around 4 or 5 bits to zero. Interestingly, most of the tones with zero bits, and all of the "new" ones, were located in tones 212-314, firmly in the region where the PSD mask was most strictly reducing my power for ADSL2+ crosstalk purposes.

15 tones aren't enough to explain the scale of the change I saw (a drop of 9Mbps in attainable, followed by instantaneous increase of 11Mbps).

If you look at the bit-loading animation, the period I checked is covered by frames 9-14. You can see some of the zero's being put into place. However, you also see a big increase in the number of bits in the rest of D1 (tones 350-850) that far outweighs the impact of just 15 tones.

So, I don't think the problem is the number of tones becoming zero.

But I did see something else, which is best left to a separate reply.

In reply to a post by Ignitionnet:

For the actual to drop you either need SRA to be in place or a full resync, nothing to do with bit swapping?

I just did some analysis on the bit-loading data (as part of investigating RobertoS' idea.

Before that analysis, I would have agreed with you 100% on this - in theory and (I'd have said) in practice. Bit-swapping really does only move bits around.

If bit-swapping does indeed work like this, then you'd expect the sum total of bits to never change. If you total all the downstream bits (zero, or between 2 and 15 on each tone), and the number should be unchanged on every single sample.

However, my analysis of the bit-loading data for the 6 month period that sync was maintained showed some interesting changes to the number of bits (and, when multiplying by 4000, the equivalent data transfer rate including the framing overheads)

Date      Attain Actual SNRM    #Bits   Data Rate
11/2012   81     80     6.3dB   20882   83.5Mbps
11/2012   81     80     6.3dB   20883   83.5Mbps
12/2012   78     80     5.4dB   21100   84.4Mbps
01/2013   76     80     4.6dB   21336   85.3Mbps
05/2013   72     80     3.0dB   21686   86.7Mbps
05/2013   72     80     3.0dB   21718   86.9Mbps

So, even though the published sync speed never changed (it was always 79,999Kbps), the bit loading suggests that it was transferring more data down.

I'm pretty sure that the VDSL2 framing overheads are not variable, and there was no change in the FEC/interleaving settings through this time (which would have required a re-sync anyway). What the data was used for is a mystery.

Kinda baffling.

ignition snrm does move around without SRA. Bitswapping can turn tones off without SRA.

The modem estimates attainable based on snrm.

So if bitswapping reduces tones available for use then existing tones will reduce snrm to maintain sync.

Edited by Chrysalis (Thu 30-May-13 14:12:52)