Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Author Topic: Migration to BT: my story  (Read 1934 times)

GigabitEthernet

  • Kitizen
  • ****
  • Posts: 2097
Migration to BT: my story
« on: June 29, 2017, 10:41:07 AM »

I have today "migrated" (it's actually a new line) to BT Infinity.

I'm pleased to see I have maxed out the downstream on my line (I am on BT Infinity 1) and the upstream is just over 9Mbps.

I don't know if it makes sense to have an additional MDWS profile - I have tried to register but it says I already have an account which makes sense - but at the moment I am uploading under GbEth. The new line started to be used at around 10:29 on the 29th June 2017.

We can conclusively put to bed the "falling off a cliff" hlog being abnormal as the same thing can be seen on this line.

I expect G.INP will be enabled soon as I'm already getting quite a lot of ES but that is what I expected.

The only slight annoyance is on TalkTalk my pings were 8ms whereas on BT they are 16. Not a huge increase but something to note for those considering shifting (I am in the south of the UK).
Logged

GigabitEthernet

  • Kitizen
  • ****
  • Posts: 2097
Re: Migration to BT: my story
« Reply #1 on: June 29, 2017, 02:40:30 PM »

I have both lines running now (as of about 14:40 on the 29th June) and there seem to be no signs of crosstalk initially. No change to the downstream SNRM on the BT line.

I do have vectoring on my cabinet.
Logged

GigabitEthernet

  • Kitizen
  • ****
  • Posts: 2097
Re: Migration to BT: my story
« Reply #2 on: June 29, 2017, 07:35:47 PM »

Just a question: how long will it take DLM to react?
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 32540
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Migration to BT: my story
« Reply #3 on: June 29, 2017, 08:14:33 PM »

The answer can be found in Section 2.2.1, Dynamic Line Management, of BT's SIN498 --

Quote
Dynamic Line Management (DLM) is employed in GEA-FTTC. DLM constantly
manages lines to maintain a target link quality (speed and stability). It does this for as
long as the product exists.

At provision, the line is put on “wide open” VDSL2 line profiles allowing the
upstream and downstream line speeds to run at the upper limit of the product option
selected.

On the first day of operation, DLM will intervene if severe instability is detected.
Otherwise, DLM will wait until the day after provision before deciding if it must
intervene, provided that the line has been trained up for at least 15 minutes during the
preceding day.

If DLM intervenes it will set a profile with a maximum rate and a minimum rate,
where the minimum rate is set at approximately half of the maximum rate. The
purpose of the minimum rate is to ensure that the line does not train at a rate which is
significantly below the level the line should be able to achieve. If this happened, then
the line is likely to remain at a very low rate until a re-train is forced by the user by
powering off the modem.

Note : It is the DLM system that sets the line profile, and this should not be interfered
with by CPs/users setting rates, SNR margins etc. at the modem.

Note : The upstream throughput is also constrained on the DSLAM to the upstream
rate requested in the order, i.e. 2 Mbit/s, 10 Mbit/s or 20 Mbit/s, so even if the VDSL2
upstream line speed is higher, the upstream throughput is constrained to the level
ordered for the product.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

GigabitEthernet

  • Kitizen
  • ****
  • Posts: 2097
Re: Migration to BT: my story
« Reply #4 on: June 30, 2017, 05:14:49 PM »

I have been doing some more tests between the two lines.

On the upstream there is no evidence of crosstalk. On the downstream it seems as though a 0.2dB drop in SNRM is present on both lines. I will do further testing to confirm this.
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 32540
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Migration to BT: my story
« Reply #5 on: June 30, 2017, 05:27:41 PM »

Thank you.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

j0hn

  • Kitizen
  • ****
  • Posts: 3397
Re: Migration to BT: my story
« Reply #6 on: June 30, 2017, 08:40:09 PM »

Being on a cabinet with vectoring I would expect the impact to be considerably less than for those running 2 lines on a cabinet without vectoring.

Are you monitoring both lines on MDWS?
Logged
BT FTTP 160/30 - BQM - speed test

GigabitEthernet

  • Kitizen
  • ****
  • Posts: 2097
Re: Migration to BT: my story
« Reply #7 on: June 30, 2017, 09:52:48 PM »

I was earlier but not at present. I'll try and sort something out tomorrow.
Logged

GigabitEthernet

  • Kitizen
  • ****
  • Posts: 2097
Re: Migration to BT: my story
« Reply #8 on: July 01, 2017, 10:55:47 AM »

I am curious that DLM has not taken action as of yet.
Logged

GigabitEthernet

  • Kitizen
  • ****
  • Posts: 2097
Re: Migration to BT: my story
« Reply #9 on: July 01, 2017, 01:47:20 PM »

DLM has now made changes. Interleaving up to 975 on the downstream. I hope G.INP might be enabled shortly.

I guess this puts to bed the debate (?) that DLM only makes changes early in the morning.
Logged

WWWombat

  • Kitizen
  • ****
  • Posts: 1674
Re: Migration to BT: my story
« Reply #10 on: July 01, 2017, 07:53:28 PM »

DLM doesn't change the interleaving depth directly. It changes the INP and delay values ... and the modem chooses (during sync) an appropriate interleaving level to suit those requirements. It can alter independently (at the next sync) if there are other environmental changes, such as a slight change in sync speed.

In the absence of any change to INP and delay, the interleaving level probably changes at the same time as the interleaving block size, the RS block size, and the number of parity bytes carried in the RS block.
Logged