G.INP

[#1]

I was looking at rollouts around the country recently...
I looked at the rollout of FTTC in both Birmingham and Crawley and noticed that up until a certain time (maybe late 2012 - early 2013) BT's own rollout was using Huawei manufactured cabs but then the started installing the ECI cabs which are apparently (openreach engineer) a lot cheaper than the Huawei's were...
and now more recent installs by BT have gone back to the Huawei brand but not sure whether this is because of the 96 connection cabs or if its because of the 288 connection cabs...
All BDUK installs seem to have always used Huawei's cabinets in both these locations.
But please don't take my word for it... it was just an opinions based on some brief research.

[#2]

It's because ECI cabinets don't support vectoring nor G.INP.

[#3]

I'm "nearly" sure Vectoring is supported?
Do you have anything that backs up your statement?

[#4]

Quote from: AlecR

It's because ECI cabinets don't support vectoring nor G.INP.

That's incorrect ECI cabs can do Vectoring although some may require an upgrade to make it happen,  and they can do G.INP but only on the Downstream. 

[#5]

DLM has resync my line this morning around 8am.
BEFORE:
Interleaved 16/8
INP 46.00/47:00
Sync 79999/20000
NOW:
Interleaved 16/1
INP 48.00/00.00
Sync 79999/19999

[#6]

Yep, thats your G.INP being removed from upstream 
You now on Fast Path.

[#7]

I think the interleaved on downstream is still too high 16? Should be lower around 8?

[#8]

I'm not 100% sure but about 90%...
My connection was fast path on both downstream and upstream (1) until G.INP was enabled and then I norice m interleaving figures changed to 8 on downstream and something else on upstream...
However my ping was unaffected... I think its something to do with G.INP and it doesn't actually affect latency like before...
However if I'm wrong and it is too high then then DLM will bring it back down in time I'm sure... this mornings re-sync would have only been to remove the G.INP from DSLAM.

[#9]

I used to be on fast path on both downstream / upstream for long time (for 13 months) before G.INP was put on my line at 16/8 and now G.INP removed on the upstream but not downstream.

[#10]

what are you pings to bbc.co.uk ?
and regional location?

[#11]

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
C:\Windows\System32>ping bbc.co.uk
Pinging bbc.co.uk [212.58.244.20] with 32 bytes of data:
Reply from 212.58.244.20: bytes=32 time=10ms TTL=55
Reply from 212.58.244.20: bytes=32 time=10ms TTL=55
Reply from 212.58.244.20: bytes=32 time=10ms TTL=55
Reply from 212.58.244.20: bytes=32 time=10ms TTL=55
Ping statistics for 212.58.244.20:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 10ms, Maximum = 10ms, Average = 10ms
C:\Windows\System32>

[#12]

All looks good to me... I see the same results

Quote

Microsoft Windows [Version 6.3.9600] (c) 2013 Microsoft Corporation. All rights reserved. Pinging bbc.co.uk [212.58.244.20] with 32 bytes of data: Reply from 212.58.244.20: bytes=32 time=12ms TTL=55 Reply from 212.58.244.20: bytes=32 time=13ms TTL=55 Reply from 212.58.244.20: bytes=32 time=13ms TTL=55 Reply from 212.58.244.20: bytes=32 time=12ms TTL=55 Ping statistics for 212.58.244.20:     Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:     Minimum = 12ms, Maximum = 13ms, Average = 12ms >

bare in mind I'm close to edge of my WiFi coverage currently..

[#13]

I was hoping for the downstream to be on fast path soon. Both G.INP turned off.

[#14]

you wont get fast path on downstream max, the g.inp is been kept on, but g.inp works well so you shoudnt be seeing a performance impact from it.

[#15]

Having you downstream on fast path will more than likely produce many errors and end up with interleaving being applied... along with a speed loss.