Low bit loading rates

Looking at my line performance through DSL stats, I am slightly puzzled by how the modem and line are performing in the lower tones.

DSL stats screen-shot

From tone 250 upwards everything is fine and as expected, however from 40 to 250 seems to be under-performing based on SNR being low and thus low bit loading rates at 8 rather than up at 14.

I would expect the SNR to ramp up, as it does, from 40 and the notches including those at 167, 211 and 226 are explained by MW transmitters. There are no major noise sources in the property.

What I would like is to see a few more graphs of other lines that are giving speeds of 70-80Mbps to see if what I am seeing is common or is just affecting my line.

I can't post my own at the moment because I'm at work, but I think my line is pretty similar to yours.

I think what you're seeing is a power (PSD) mask, which is applied at the cabinet to cut back power on frequencies that are shared with ADSL. This is to stop the high power VDSL signals from the cabinet at those frequencies from interfering with the weaker ADSL signals from the exchange. The further the cabinet is away from the exchange, the weaker the ADSL signals are and hence the more the power in those frequencies is cut back. I believe there are a handful of PSD masks, and they are applied to a cabinet based on its distance from the exchange.

I defer to the experts on this stuff though - please correct me if I'm wrong.

I was already wondering about that as the cabinet is around 2.7km from the exchange (2.1 direct line) however I seem to remember it previously being significant higher - I might be mistaken though.

One reason I initially discounted it was that ADSL2+ runs up to 2.2MHz and the transition is around 1.1 MHz. However, given the distance from exchange to cabinet, it is likely that the top end frequencies will have "disappeared" by that point so a mask with a change at 1.1Mhz could be correct.

That said, it would still be interesting to see what other are obtaining - and their exchange to cabinet distance.

Edited by MHC (Thu 14-May-15 14:39:39)

Cabinet-to-exchange: 1263m as crow flies

http://s17.postimg.org/e0mnottqn/dsl_tones_0_600.png

Not as harsh in your case ... although it does push out further to around tone 475 which is about 2.1MHz

Yeah, I think that makes sense - nearer the exchange there will be higher ADSL2+ frequencies still in use.

Edited by ip75 (Thu 14-May-15 15:37:33)

Yes - the PSD masks for cabinets closer to the exchange cause less power restriction, but over a wider frequency band. Those further away need to restrict power much more, but only over a shorter band.

Page 30 of the ANFP

Here's my line... I'm about 100m away from the cab (so you see the effect of upstream PBO too), while the cabinet is 1.1km from the exchange (crow flies), and between 1.3 and 1.5km line distance.

DSL stats bitloading

Thanks ...

I really must have been having a bad day this morning not to really think about it!

A pity I could not get the mask choice tweaked _ I might then hit a full 80Mbps!

Mine is here: https://db.tt/Uv7jnmFh

I'm about 250m from the cabinet, and the cabinet is about 3.5km from the exchange.

Much the same as mine ...

What does yours do from tones 32 to 39?

This is the bitloading:

32 9
33 4
34 5
35 5
36 5
37 5
38 6
39 6

I get:

32 12

33 0
to
39 0

40 4

Which seems a little odd although the SNR drops from 18 dB on tone 40 to 0dB on 39 ... A little more head scratching. It could be in the DSP or just a tolerance on the filters at modem front end. May have to try a different HG612 and see how that performs.

At tone 32, aren't you in the border between upstream and downstream?

IIRC, the two manufacturers, ECI and Huawei, behave differently at the upstream/downstream crossovers.

Yes, but I would not have expected 7 empty tones. One or two maybe.

ip75 has all tones in use in one direction or another ... and similarly with yours.

I currently have Huawei modem and cabinet.

The Band plan allocates 7-32 for upstream and 33-859 downstream

Edited by MHC (Fri 15-May-15 08:57:19)

In reply to a post by MHC:

I was already wondering about that as the cabinet is around 2.7km from the exchange (2.1 direct line) however I seem to remember it previously being significant higher - I might be mistaken though.

One reason I initially discounted it was that ADSL2+ runs up to 2.2MHz and the transition is around 1.1 MHz. However, given the distance from exchange to cabinet, it is likely that the top end frequencies will have "disappeared" by that point so a mask with a change at 1.1Mhz could be correct.

That said, it would still be interesting to see what other are obtaining - and their exchange to cabinet distance.

Note that ADSL1 and ADSL2 only run up to 1.1 MHz, not 2.2 MHz, and that the speed boost from ADSL2+'s extra 256 tones is only on short lines (close to the exchange). Iit seems likely that you're restricted on the lower tones to ensure that long line ADSL users don't see a speed drop due to crosstalk.

Also, you're only looking at part of the VDSL2 spectrum BT can use. BT use band plan 998ADE17, which has tone numbers up to 4095, not up to 512. Tone allocation is:

* 0 is voice.
* 1 to 6 are the guard band after voice.
* 7 to 32 are upstream 0.
* 33 to 869 are downstream 1.
* 870 to 1205 are upstream 1.
* 1206 to 1971 are downstream 2.
* 1972 to 2782 are upstream 2.
* 2873 to 4095 are downstream 3.

If you're on a short line to the cab, the DSLAM will aim to get more bits into DS3 and US2 than into lower bins - those bins attenuate faster over distance, so that frees up capacity in US0, US1, DS1 and DS2 for longer FTTC lines.

In reply to a post by farnz:

If you're on a short line to the cab, the DSLAM will aim to get more bits into DS3 and US2 than into lower bins - those bins attenuate faster over distance, so that frees up capacity in US0, US1, DS1 and DS2 for longer FTTC lines.

I realise I forgot to justify this; Profile 17a, as used by BT, is limited to an aggregate throughput of 100M in both directions. Thus, once you can sync at 80M down, 20M up, there's no point adding more bits to the line loading - you might as well have the extra SNR instead, and keep lower frequency bins empty for bitswapping if line conditions change.

If it wasn't for the 100M aggregate throughput limit, you could find your line syncing at around 169M down, 70M up, but being both unstable (that's 15 bits per bin in every available bin) and interfering with other users in the same cable bundle.

In reply to a post by farnz:

Note that ADSL1 and ADSL2 only run up to 1.1 MHz, not 2.2 MHz, and that the speed boost from ADSL2+'s extra 256 tones is only on short lines (close to the exchange). Iit seems likely that you're restricted on the lower tones to ensure that long line ADSL users don't see a speed drop due to crosstalk.

All of that is included in the reference to the ANFP earlier.

In reply to a post by farnz:

Also, you're only looking at part of the VDSL2 spectrum BT can use. BT use band plan 998ADE17, which has tone numbers up to 4095, not up to 512. Tone allocation is:

* 0 is voice.
* 1 to 6 are the guard band after voice.
* 7 to 32 are upstream 0.
* 33 to 869 are downstream 1.
* 870 to 1205 are upstream 1.
* 1206 to 1971 are downstream 2.
* 1972 to 2782 are upstream 2.
* 2873 to 4095 are downstream 3.

Nearly. The ECI and Huawei cabinets use slightly different band plans, with boundaries in slightly different places - and not quite at the tone numbers you suggest.

Back in 2012, these were the boundaries in use:

Huawei
    Discovery Phase (Initial) Band Plan
    US: (0,95) (868,1207) (1972,2783) 
    DS: (32,859) (1216,1963) (2792,3939) 

ECI
    Discovery Phase (Initial) Band Plan
    US: (0,95) (880,1195) (1984,2771) 
    DS: (32,859) (1216,1959) (2792,4083)

Newer firmware, in late 2013, resulted in changes, seen here:

Huawei
Discovery Phase (Initial) Band Plan
    US: (7,32) (871,1205) (1972,2782) 
    DS: (33,859) (1216,1961) (2793,3970)

ECI
    Discovery Phase (Initial) Band Plan
    US: (6,31) (882,1193) (1984,2770) 
    DS: (33,857) (1218,1959) (2795,4083)

In reply to a post by farnz:

If you're on a short line to the cab, the DSLAM will aim to get more bits into DS3 and US2 than into lower bins - those bins attenuate faster over distance, so that frees up capacity in US0, US1, DS1 and DS2 for longer FTTC lines.

Nearly. It doesn't free up capacity, as such. Rather it reduces power in the upstream direction, helping to reduce crosstalk on other lines. That reduced crosstalk helps longer lines perform better.

In reply to a post by farnz:

I realise I forgot to justify this; Profile 17a, as used by BT, is limited to an aggregate throughput of 100M in both directions.

Nope. There is no such aggregate limit to profile 17a. Lines could go faster today, if BT chose to allow it. It might only happen for perhaps 20-30% of lines, but it could happen.

When vectoring is enabled, line profiles of 100/30 or even more would be readily possible while keeping to profile 17a. That might apply to 40-50% of lines, and would still not hit an aggregate limit - though it would probably hit the 100Mbps speed limit of the WAN connection of the modems.

Evidence? Go look at what Eircom are achieving in Ireland, having turned on vectoring a year ago; they're now running a maximum profile of 100/20. They published a graph showing speed vs distance for their lines about 6 months ago:
http://forums.thinkbroadband.com/fibre/4370483-vecto...

The band plans I quoted are direct from G.993.2 - they're the VDSL2 band plans, ignoring what BT's DSLAMs have implemented.

In reply to a post by WWWombat:

In reply to a post by farnz:

I realise I forgot to justify this; Profile 17a, as used by BT, is limited to an aggregate throughput of 100M in both directions.

Nope. There is no such aggregate limit to profile 17a. Lines could go faster today, if BT chose to allow it. It might only happen for perhaps 20-30% of lines, but it could happen.

Go and read G.993.2; I've got the 12/2011 version to hand. Table 6-1 in the copy I've got shows the profile parameters and the bandplan parameters. For Profile 17a, the MBDC (the aggregate data rate a Profile 17a compliant device must support) is 100 Mbit/s.

Eircom's testing has been done using bandplan 998ADE17 with Profile 30a devices; it uses the same frequency spectrum as BT do in the UK, but Profile 30a devices must support 200 Mbit/s MBDC.

In reply to a post by farnz:

Go and read G.993.2; I've got the 12/2011 version to hand. Table 6-1 in the copy I've got shows the profile parameters and the bandplan parameters. For Profile 17a, the MBDC (the aggregate data rate a Profile 17a compliant device must support) is 100 Mbit/s.

Gone and re-read.

My copy of the document (same version) tells me that MBDC stands for "Minimum Bi-directional Net Data Rate Capability". So it really refers to a minimum capability of hardware. Not a maximum capability, and certainly not a maximum possibility.

Later on, the spec has this to say:

The bidirectional net data rate capability is the maximum value of the bidirectional net data rate that the VTU can support.

The required minimum bidirectional net data rate capability (MBDC) is the minimum value of the bidirectional net data rate that a VTU compliant with a profile shall be capable of supporting.

I understand the first part of that paragraph to mean: A VTU has a maximum BNDR that it can cope with, as a consequence of the power of the hardware it is designed with. This is the highest capability of the device.

I understand the second part of the paragraph to mean that, for a VTU to be considered as compatible with any particular profile, its maximum BNDR must be above the MBDC value. In this case, for profile 17a, a VTU must be able to shift 100Mbps at minimum to qualify. No specification of what the maximum BNDR can be.

So that doesn't mean that profile 17a itself - the band plan in use - is limited to carrying an aggregate of 100Mbps. Just that devices might be the limiting factor.

In reply to a post by farnz:

Eircom's testing has been done using bandplan 998ADE17 with Profile 30a devices; it uses the same frequency spectrum as BT do in the UK, but Profile 30a devices must support 200 Mbit/s MBDC.

So you agree that when the network runs as profile 17a, it doesn't present a 100Mbps aggregate limitation - that only happens when you have a weedy, minimum-spec CPE modem.

Presumably, you also agree that CPE devices can be more powerful than the minimum needed to qualify as being "profile 17a" capable. And that they don't need to be actually running profile 30a to make use of the that extra power. And that such a beefy modem can run in "profile 17a" mode, alongside a beefed-up network, and work at an aggregate speed of above 100Mbps.

Combine a beefy, above-minimum-capability DSLAM running profile 17a, with a beefy, above-minimum-capability modem running a matching profile 17a, and you get aggregate speeds above 100Mbps. Ergo profile 17a, per se, does not present an aggregate speed limitation.

That certainly seems to be the case for Eircom.

Whatever hardware they used during testing of vectoring, they continued to leave subscribers on the same F1000 modem - there was no new modem dispatched when profiles were upgraded.

The Eircom F1000 modem, aka the Zyxel VMG8324-B10A, seems to synchronize happily at an aggregate of over 122mbps (102.4/20.5). Yet Zyxel's own specs for the VMG8324 don't mention capability for profile 30a.
http://www.zyxel.com/uk/en/products_services/vmg8324...

Zyxel themselves think that profile 17a has maximums of 100 down combined with 50 up.
http://www.zyxel.com/solutions/solution_detail_20101...

Or should we tell them they needn't bother?

In reply to a post by farnz:

Eircom's testing has been done using bandplan 998ADE17 with Profile 30a devices; it uses the same frequency spectrum as BT do in the UK, but Profile 30a devices must support 200 Mbit/s MBDC.

I should emphasise that we know that the only difference such a CPE device can make is that it brings additional power. Neither end is actually working in the profile 30a mode, shown by plenty of screenshots over on boards.ie where the modem reports both profile 17a and the 100/20 speeds.

IIRC, profile 30a doesn't support US0 either ... yet we see US0 as part of those same screenshots.

I also have a recollection of vendors reporting that profile 30a - where there are 3,500ish tones spaced at 8.6kHz - isn't vectoring-compatible with profile 17a in the same bundle.