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.