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:

Pages: 1 ... 21 22 [23] 24 25 ... 62

Author Topic: G.INP - BT rollout 2015.  (Read 267071 times)

underzone

  • Reg Member
  • ***
  • Posts: 272
Re: G.INP - BT rollout 2015.
« Reply #330 on: May 23, 2015, 07:24:00 PM »

Not good news for ECI EU's  :no:
Logged
BT Infinity 2, Huawei 288, Zyxel VMG8924-B10A (bridged with 1508 MTU), pfsense x64

NewtronStar

  • Kitizen
  • ****
  • Posts: 4817
Re: G.INP - BT rollout 2015.
« Reply #331 on: May 23, 2015, 07:51:00 PM »


    • The changes will be more of a DLM type configuration ie if the modem does not support G.INP then it will be moved over to the (new) non-ReTx default profile which can use both Interleaving and Error Correction if need be.  The DSLAM is able to detect if the CPE is G.INP compatible or not


    Thankyou Kitz for this update and the above info says to me if you want full G.INP enabled on your line your will need to purchase a G.INP capable modem and also be on the Huawei cabinet at least the DSLAM is able to detect it this time and make a better choice for the end-users current hardware.

    I guess OR needed to find a workable compromise for all FTTC modems and then start to set their sights on the ECI cabinet to get G.INP working  :-\
    Logged

    kitz

    • Administrator
    • Senior Kitizen
    • *
    • Posts: 31977
    • Trinity: Most guys do.
      • http://www.kitz.co.uk
    Re: G.INP - BT rollout 2015.
    « Reply #332 on: May 23, 2015, 08:01:25 PM »

    I guess OR needed to find a workable compromise for all FTTC modems and then start to set their sights on the ECI cabinet to get G.INP working  :-\

    I must stress that I dont know what is going on with the ECI cabs other than it appears to have come to a halt. 

    I must also stress that it is the statement by Openreach themselves about the mention of upstream on the DSLAM which has caused confusion about its capability.  I am trying to get clarification,  so we cant jump to conclusions just yet, but their specific inclusion of DSLAM and knowing that its the local device that deals with the upstream data casts some doubt that needs clearing up.
    Logged
    Please do not PM me with queries for broadband help as I may not be able to respond.
    -----
    How to get your router line stats :: ADSL Exchange Checker

    Mr_Custard

    • Just arrived
    • *
    • Posts: 1
    Re: G.INP - BT rollout 2015.
    « Reply #333 on: May 23, 2015, 08:12:12 PM »

    Certainly after the cockup they made of g.inp they wont be keen on vectoring now.

    How they can make such a hash of g.inp I dont know, its years old tech.

    I hope they do go ahead with vectoring. I'm on the vectoring trial and the improvement to my line is significant, it would be shameful not to go ahead.

    I'm away on business, but will give some stats when I'm back in the UK, if anyone is interested.
    Logged

    Chrysalis

    • Content Team
    • Addicted Kitizen
    • *
    • Posts: 5704
    Re: G.INP - BT rollout 2015.
    « Reply #334 on: May 23, 2015, 08:13:08 PM »

    yes please, before and after stats.
    Logged
    Sky Fiber Pro - Billion 8800NL bridge & PFSense BOX running PFSense 2.4 - ECI Cab - LINE STATISTICS CLICK HERE

    kitz

    • Administrator
    • Senior Kitizen
    • *
    • Posts: 31977
    • Trinity: Most guys do.
      • http://www.kitz.co.uk
    Re: G.INP - BT rollout 2015.
    « Reply #335 on: May 23, 2015, 08:23:31 PM »

    Hi Mr_Custard and welcome :)

    Yes please.   I take it that you must be on a Huawei cab.
    Logged
    Please do not PM me with queries for broadband help as I may not be able to respond.
    -----
    How to get your router line stats :: ADSL Exchange Checker

    currytop

    • Reg Member
    • ***
    • Posts: 114
    Re: G.INP - BT rollout 2015.
    « Reply #336 on: May 23, 2015, 09:25:21 PM »

    As a follow up, I've attached my newly acquired HG612 3B to my Huawei line instead of the ECI and saw a small increase in attainable sync speed but no G.INP. Then around 2pm today the modem reconnected with G.INP enabled. Yea the high latency has gone, so things are cooking now! ;D

    Steve
    Logged

    Bald_Eagle1

    • Helpful
    • Kitizen
    • *
    • Posts: 2720
    Re: G.INP - BT rollout 2015.
    « Reply #337 on: May 24, 2015, 10:24:09 AM »

    Thanks for that clarification, Kitz.

    Just one question though.......

    You mention this:-

    "Interleaving causes DELAY - ie increase in latency/ping times. Interleaving does NOT cause loss of sync speed."


    For every non-G.INP VDSL2 connection that I have seen stats for since 2011, a switch from fastpath to Interleaved has ALWAYS coincided with an increase in attainable rate & definitely a decrease in sync speed.

    When fastpath and/or reduced Interleaving depth have been restored, attainable rate has reduced again & sync speed has increased.

    Do you have an explanation for this?

    Based on what you say, my suspicion (but that's all it is) is that sync speed has been reduced by DLM to provide more stability, alongside Interleaving/delay etc.


    From the limited detailed stats I have seen from G.INP active connections to date, it appears that a reduction in Bearer 0 Interleaving depth etc. has actually resulted in slightly LOWER sync speeds.


    Logged

    GigabitEthernet

    • Kitizen
    • ****
    • Posts: 1918
    Re: G.INP - BT rollout 2015.
    « Reply #338 on: May 24, 2015, 10:25:54 AM »

    Interleaving here has lost me 6Mb of sync so yes it definitely does decrease sync speed.
    Logged

    roseway

    • Administrator
    • Senior Kitizen
    • *
    • Posts: 39418
    • Penguins CAN fly
      • DSLstats
    Re: G.INP - BT rollout 2015.
    « Reply #339 on: May 24, 2015, 10:31:26 AM »

    I'm speaking from the depths of ignorance here, but I think what Kitz was saying is that it's not the interleaving as such which decreases the sync speed, but the error correction which is usually applied at the same time (but doesn't have to be).
    Logged
      Eric

    ejs

    • Kitizen
    • ****
    • Posts: 1940
    Re: G.INP - BT rollout 2015.
    « Reply #340 on: May 24, 2015, 11:44:26 AM »

    I think there can be FEC without interleaving.

    But interleaving without FEC seems rather pointless!
    Logged

    kitz

    • Administrator
    • Senior Kitizen
    • *
    • Posts: 31977
    • Trinity: Most guys do.
      • http://www.kitz.co.uk
    Re: G.INP - BT rollout 2015.
    « Reply #341 on: May 24, 2015, 12:38:49 PM »

    but I think what Kitz was saying is that it's not the interleaving as such which decreases the sync speed, but the error correction which is usually applied at the same time (but doesn't have to be).

    Correct, yes thanks Eric.

    The interleaving process on its own is just the chopping up and rearranging of the data stream.  - more information on Interleaving.
    BT have been saying since as far back as 2006 that Interleaving doesnt cause any loss in sync speed linky, but what is often overlooked and causes confusion is that historically BT always turned on Error Correction at the same time which does cause the overheads and therefore a reduction in sync speed.

    Error Correction (or FEC) requires the transmission of redundant data, because that redundant data has to also be transmitted with the data stream, then this reduces the amount of 'real data' that can be sent.  Each line can only carry 'x' number of bits, so if the line has Reed Soloman encoding applied then the sync speed reduces by a certain percentage to allow for the transmission of those overheads.

    I think there can be FEC without interleaving.

    But interleaving without FEC seems rather pointless!

    Correct on both points. 
    Error correction is how (redundant) data is recovered, by adding interleaving to the process it spreads out the data and increases the likelyhood of error correction for longer noise bursts.   Error Correction doesnt need to be interleaved, but there's no point using Interleaving without Error Correction.   Why bother chopping up the data if there's no error correction in place to make use of the re-assembled data.
    Logged
    Please do not PM me with queries for broadband help as I may not be able to respond.
    -----
    How to get your router line stats :: ADSL Exchange Checker

    kitz

    • Administrator
    • Senior Kitizen
    • *
    • Posts: 31977
    • Trinity: Most guys do.
      • http://www.kitz.co.uk
    Re: G.INP - BT rollout 2015.
    « Reply #342 on: May 24, 2015, 12:56:10 PM »

    Interleaving here has lost me 6Mb of sync so yes it definitely does decrease sync speed.

    Its not the Interleaving per se which has cost you the lost sync, it's the Error Correction.   If you look at your stats you have INP = 3. 
     
    INP = Impulse Noise Protection
    INP uses Reed Solomon encoding to transmit redundant data and is usually used in tandem with Interleaving.   The INP parameter specifies the amount of error correction to be applied.

    We often use the term interleaving very loosely, when in fact we should be using Error Correction or INP.   Its perhaps a habit that has formed in the adsl community because in days of old when both were always switched on at the same time, it was easier to identify Interleaving from the FEC to explain any increase in latency. 
    But if you think about it, FEC stands for Forward Error Correction...  and thats Error Correction not Interleaving in itself. 

    Now that things have changed with FTTC and they can and are being used independently we will have to be more careful about which term we use... because they are not the same thing.   

    I suspected that this would cause confusion and its why I specifically added the bit at the bottom in an attempt to clarify further that they are two separate things.
    Logged
    Please do not PM me with queries for broadband help as I may not be able to respond.
    -----
    How to get your router line stats :: ADSL Exchange Checker

    Bald_Eagle1

    • Helpful
    • Kitizen
    • *
    • Posts: 2720
    Re: G.INP - BT rollout 2015.
    « Reply #343 on: May 24, 2015, 01:27:11 PM »

    Error Correction doesnt need to be interleaved, but there's no point using Interleaving without Error Correction.   Why bother chopping up the data if there's no error correction in place to make use of the re-assembled data.


    Indeed.

    You may recall that for quite a few months (pre-G.INP), my connection had Interleaving depths of 1 (i.e. OFF), with zero INP, yet I did see fairly low levels of both US & DS FEC/RSCorr.


    I am one of the few that has seen a slight loss in sync speed since G.INP was activated (from 22399 Kbps to currently 21912 Kbps).

    It did remain at 22399 Kbps for around 40 days with a couple of resyncs during that period, so I suspect something else has been at play (maybe due to increased crosstalk and/or the slight increase in line attenuation that I see as the weather warms up every year?)

    If you zoom in to the Interleaving & sync speed graphs at around Noon, 4th May in the attached montage, you will see the effects of me intentionally disabling G.INP by briefly reverting to Asbokid's SP10 firmware as an experiment.
    Logged

    kitz

    • Administrator
    • Senior Kitizen
    • *
    • Posts: 31977
    • Trinity: Most guys do.
      • http://www.kitz.co.uk
    Re: G.INP - BT rollout 2015.
    « Reply #344 on: May 24, 2015, 01:27:39 PM »

    "Interleaving causes DELAY - ie increase in latency/ping times. Interleaving does NOT cause loss of sync speed."

    I will change that to add 'alone'.   I had tried to clarify the difference between the two, but perhaps the addition of the word 'alone' in there it will make it clearer?


    For every non-G.INP VDSL2 connection that I have seen stats for since 2011, a switch from fastpath to Interleaved has ALWAYS coincided with an increase in attainable rate & definitely a decrease in sync speed.

    When fastpath and/or reduced Interleaving depth have been restored, attainable rate has reduced again & sync speed has increased.

    Do you have an explanation for this?

    Based on what you say, my suspicion (but that's all it is) is that sync speed has been reduced by DLM to provide more stability, alongside Interleaving/delay etc.


    From the limited detailed stats I have seen from G.INP active connections to date, it appears that a reduction in Bearer 0 Interleaving depth etc. has actually resulted in slightly LOWER sync speeds.

    For pre G.INP, it will be INP that decreases the sync speed.   

    There are a couple of things I dont understand

    [1] Why max attainable rate always seems to go skewy when Interleaving and Error Correction is turned on.

    [2] Why /how FEC alone affects sync.  We've known for several months that BT had been dabbling with FEC without INP or Interleaving on the upstream but I could never fully understand what was happening there and if you recall in the early days I had started beginning to wonder about PhyR.   

    I still see occasional FEC on my own lines upstream yet there is no INP or Interleaving.  Yet for FEC to occur then there must be some very low level redundancy somewhere.   Perhaps because so many lines can reach their upstream target easier and because Interleaving isnt applied we havent been looking closely enough as to why this could be and if its possible that BT by default is applying Error Correction and weve never noticed the loss in attainable upstream sync... and we never seem to pay much attention to upstream like we do for downstream.

    Ermmm actually further to the above - Ive just looked more closely at my stats.

    Quote
                            VDSL2 framing
                            Bearer 0
    MSGc:           18              150
    B:              239             236
    M:              1               1
    T:              23              5
    R:              0               16
     

    There you go - the R value proves that BT is using a low level of upstream Error Correction by default on their DSLAMs, that isnt anything to do with the usual DLM settings.  One mystery [#2] solved.   
    Logged
    Please do not PM me with queries for broadband help as I may not be able to respond.
    -----
    How to get your router line stats :: ADSL Exchange Checker
    Pages: 1 ... 21 22 [23] 24 25 ... 62