It is a difference in the way some ISPs do things. Sky in the past have set a target connection speed rather than a target SNR. Even when the line gets better the speed does not. It does generally have the side effect that the SNR goes up and therefore reduces disconnections but the impacts of setting the target connection speed are different to the impacts of setting the target SNR.

Because when the bit loading for the individual frequency bins is done, if a low connection speed is all that is needed then only the good bins will be used, rather than trying to push the line to the envelope that the target noise margin specifies.

Banding is about trying to stop lines that flap around a lot, it can increase the length of time for a resync if there is a long large noise burst but user should in theory have a more usable speed after that.

Sometimes banding over plays the card.

Engineer was booked for 8am to 1pm today but no show.

BT level 1 support called about 30 mins ago to ask how the engineer visit went and was the fault fixed. Told him no show and not fixed. He said to expect a call from level 2. Twenty minutes ago level 2 support called to tell me renumbering was the solution. I explain about the failed attempts at renumbering and he gives up on the renumbering and books an "exchange" engineer for this Saturday between 8am and 1pm and said the engineer will call my mobile if a home visit is required.

The level 2 support agent also told me the lady who has the land line number my broadband is activated on isn't happy about all the calls about my broadband fault. He contacted order management about it and they suggested the renumbering would also fix the broadband fault.

It could be a hot spell results in the fault becoming worse each day but it improves where it's less frequent when it rains?

That suggests a bad joint somewhere, the OR lad should be able to locate with a TDR or similar.

-------------

In cooler weather, with the segments of line cooling, the joint wires are pulled tighter together, giving a better connection. Also any corrosion product at the joint will also conduct better if it rains, wetting the joint.

Warmer weather expands/lengthens the wires, so less tension to keep the joint together, hence intermittent connection/breaks.


TDR = Time Domain Reflectometer.

OR/BT may have another name for them.

No guarantee; but it seems more likely on an overhead stretch; rather than underground.

Unfortunately I am suffering (again) from the HR fault on my line. It's a nightmare trying to get Openreach to fix it. Very noisy line, which occasionally improves after a phone call is made. Infinity 2 getting borked.

The problem is because it is intermittent - it is too risky to ask for a callout because of the threatened £100+ fee. So I have to rely on the online checker actually picking the problem up as that avoids the fee threat.

Anyway the last time an engineer actually visited of course the fault was not on. He was a 'bog standard telephone' engineer and did not have a TDR so could not fix the fault. All he could do was replace the old two core cable down the front of the building on the off chance it was the cause of the problem (it wasn't).

Since we moved in the overhead cable, the wall cable and the master socket have all been changed out - the only bit this side of the pole is the short stretch between the junction box by the door and the master socket.

The fault is on again at the moment and was picked up by the test system last week - detected as a 'fault in the BT Network'. Great I thought - it would get fixed at last.

So two days later I get a call from the engineer; strangely he starts off by asking how my problem manifested itself. After I explained he launched into an explanation of how he had just fixed it - it was a 'battery' fault apparently and he had found voltage on my line when disconnected. Lifting up a cover he found my line 'touching another' and moving it fixed the problem: Hooray!

Except when I got home the problem was still there, unchanged. There is no BT cover in the location he described.

The line had indeed been disconnected for 45 minutes on my router log but it hadn't been fixed. I now suspect the initial question was in order to construct the remainder of the conversation and a reason to close the call The engineer did not reply to a text I sent to his mobile number.....

So I refused to accept the fix and now BT have set the call to a 'problem in my house' which requires the callout and the threat of a fee. So of course they will come next week when the fault isn't on and they won't have a TDR.

In the meantime my line, which had just recovered from banding to increase back to 60Mbps synch has degraded to 44Mbps synch following a particularly bad spate of disconnects in short order within 1 hour. This problem always gets worse when there is a hot spell, particularly a big variation between day and night temperatures.

Frankly this is doing my head in, and I can't afford this time off work waiting for engineers to call, only for them to not be properly equipped to investigate.

Edited by deleted (Fri 04-Jul-14 23:44:45)

Believe me, I know how frustrating dealing with BT can be as I have had my share earlier this year. If the next engineer they send out doesn't come properly equipped I suggest an email detailing your fault and what has and hasn't been done to the CEO. Of course the CEO doesn't deal with it directly but it does go to a team who can deal with it and who can make sure that a properly equipped engineer is sent out.

In reply to a post by BatBoy:

I can't see how reducing the connection speed would reduce disconnections, but I can see how raising the SNR margin would.

Reducing connection speed also reduces errors which also reduces disconnections due to too many errors.

The side effect is to raise actual SNRM.

Some gamers do it by manually increasing target SNRM, in order to achieve fastpath but slower connections.
However, although sync speeds are then lower, they are not actually fixed/banded as such.




Banded connections can & do still have slightly variable SNRM values, but MAXIMUM sync speeds are 'fixed' until banding is removed.

e.g. 19999 Kbps, 24999 Kbps, 39999 Kbps etc. etc.



I have very recently (this week) been remotely monitoring a poorly performing connection.
The Hlog graph depicted the typical 'V' shape as the effect of a bridged tap, not dealt with during a 'rushed' installation.

Sync speed was around 15 Mbps with attainable fluctuating around 18 Mbps & SNRM fluctuating around 6 dB.



As soon as someone else fixed the bridged tap (basically by disconnecting the redundant star wiring), sync speed shot up to 19999 Kbps (banded), with SNRM fluctuating around 9.6 dB & attainable rates now fluctuating around 26.3 Kbps.

The connection has since resynced at exactly 19999 Kbps again, with SNRM down to 9.1dB & attainable rate down to 24.692 Mbps as it was at a 'noisy' time.



I have just rechecked that remote connection & these are the stats - still in sync since this morning's 04:41 resync:-

Text

1 23 45 67 89 1011 1213 1415 1617 1819 2021 2223 2425

xdslcmd info --pbParams xdslcmd: ADSL driver and PHY statusStatus: Showtime Retrain Reason: 1Last initialization procedure status:   0 Max:    Upstream rate = 6013 Kbps, Downstream rate = 25012 KbpsBearer: 0, Upstream rate = 6771 Kbps, Downstream rate = 19999 Kbps  Discovery Phase (Initial) Band Plan US: (7,32) (871,1205) (1972,2782) DS: (33,859) (1216,1961) (2793,3970) Medley Phase (Final) Band PlanUS: (7,32) (871,1200) DS: (33,859) (1216,1961)           VDSL Port Details               Upstream                Downstream Attainable Net Data Rate:            6013 kbps              25012 kbpsActual Aggregate Tx Power:             5.8 dBm               10.7 dBm ====================================================================================  VDSL Band Status       U0      U1      U2      U3      U4      D1      D2      D3   Line Attenuation(dB):  8.8     48.6     N/A     N/A     N/A    21.0    60.8    90.3   Signal Attenuation(dB):  8.8     48.0     N/A     N/A     N/A    29.6    60.4     N/A           SNR Margin(dB):  4.4     4.5      N/A     N/A     N/A    9.3     9.3      N/A            TX Power(dBm): -5.3     5.4      N/A     N/A     N/A    8.5     6.7      N/A  .

Before the bridged tap was removed, attenuation etc. were too high to actually allow the connection to reach the 'banded' speed cap of 19999 Kbps, so the banding effect wasn't apparent by viewing sync speeds alone.

It is now clearly visible as shown in the pbParams data above.



The effect (not the cause) of banding is to raise SNRM to a variable level where there is still some flexibility to allow for day time/night time and/or 'other' interference fluctuations.


My own connection was 'banded' at differing levels (in stages downward) many times before an internmittent HR fault was eventually fixed.

DLM resets did release the banding most times, but it would quite rapidly return via DLM's actions.


My connection & yours are speed capped (which could be argued is a type of banding).

Mine's capped at 39999 Kbps / 9999 Kbps.

However, within that capping limit, my connection's profile has been auto-'banded' by DLM to something like 11200 to 22400 DS & 3600 to 7200 US.
I can't recall the exact 'banded' profile, but I do have an official record of it somewhere.

As my connection is unable to sync above the 'banded' profile levels, I don't actually see its effect.

Currently, these are my connection's stats:-

Text

1 23 45 67 89 1011 1213 1415 1617 1819 2021 2223 2425

xdslcmd info --pbParams xdslcmd: ADSL driver and PHY statusStatus: Showtime Retrain Reason: 1Last initialization procedure status:   0 Max:    Upstream rate = 3759 Kbps, Downstream rate = 21500 KbpsBearer: 0, Upstream rate = 3866 Kbps, Downstream rate = 21698 Kbps  Discovery Phase (Initial) Band Plan US: (7,32) (871,1205) (1972,2782) DS: (33,859) (1216,1961) (2793,3970) Medley Phase (Final) Band PlanUS: (7,32) (871,1190) DS: (33,859) (1216,1852)           VDSL Port Details               Upstream                Downstream Attainable Net Data Rate:            3759 kbps              21500 kbpsActual Aggregate Tx Power:             7.0 dBm               12.4 dBm ====================================================================================  VDSL Band Status       U0      U1      U2      U3      U4      D1      D2      D3   Line Attenuation(dB):  8.3     55.7     N/A     N/A     N/A    22.1    68.4     N/A   Signal Attenuation(dB):  8.3     55.1     N/A     N/A     N/A    31.4    68.4     N/A           SNR Margin(dB):  6.0     5.9      N/A     N/A     N/A    6.1     6.1      N/A            TX Power(dBm):  0.8     5.8      N/A     N/A     N/A    11.3    6.1      N/A  .

FWIW, my observations/comments are always based upon having studied emprical data from may connections since I first had FTTC installed in 2011, not assumption and/or supposition.

Edited by deleted (Sat 05-Jul-14 12:30:54)

But the amount of errors needed to force a disconnection are unlikely to be such a problem, maybe needing a weekly reboot to recover speed, whereas SNR margin dropping below the threshold required by the router to maintain a connection are going to be far more common, say once or twice a day, which is why the primary focus of DLM is to go for a bigger and bigger margin.

Your connection isn't affected by the banding at all. It's limited by SNR margin.

Edited by deleted (Sat 05-Jul-14 13:00:25)

In reply to a post by BatBoy:

which is why the primary focus of DLM is to go for a bigger and bigger margin.

I agree 100% & the way it does it for VDSL2 connections is......... (drum roll..................................)
capping/'banding' sync speeds (in my uninformed opinion)

Your connection isn't affected by the banding at all. It's limited by SNR margin.

Your are quite correct regarding MY connection, but it is also banded as confirmed above & the factual evidence also provided above demonstrates the effect of banding on a connection that COULD sync at higher speed if it wasn't for the banding.


As far as I am aware (& I have tested this), unlike ADSL connections, there is no direct way for a user to adjust target SNRM on VDSL2 connections.

However, there is a way a user can limit sync speeds that will actually increase SNRM, but to a still variable level.