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 ... 45 46 [47] 48 49 ... 62

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

Dray

  • Kitizen
  • ****
  • Posts: 2361
Re: G.INP - BT rollout 2015.
« Reply #690 on: August 01, 2015, 10:26:48 AM »

It looks like it makes a big difference - from 37 to 43 Mbps
Logged

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: G.INP - BT rollout 2015.
« Reply #691 on: August 01, 2015, 02:01:47 PM »

G.INP has now been re-enabled on my line but only on the downstream.

Indeed this time from the looks of it your line has been moved onto the Mk2 and this will remove G.INP on the upstream and still think your were put onto the Mk1 on the 21 July by accident.
Logged

GigabitEthernet

  • Kitizen
  • ****
  • Posts: 2243
Re: G.INP - BT rollout 2015.
« Reply #692 on: August 01, 2015, 02:34:49 PM »

It's a right pain as now I'm getting upstream errors (granted they are small).

G.INP was working perfectly on the downstream and upstream so I still don't understand why it was removed :no:
Logged

jid

  • Content Team
  • Kitizen
  • *
  • Posts: 1945
Re: G.INP - BT rollout 2015.
« Reply #693 on: August 01, 2015, 03:23:08 PM »

It's a right pain as now I'm getting upstream errors (granted they are small).

G.INP was working perfectly on the downstream and upstream so I still don't understand why it was removed :no:

Same here. Seems it'll be a waiting game to see if DLM thinks your line is suited for G.INP on both up and down.
Logged
Kind Regards
Jamie

BT FTTP - 75meg | Sky Q |  Bridgend Weather

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33879
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: G.INP - BT rollout 2015.
« Reply #694 on: August 01, 2015, 03:39:44 PM »

Quote
It looks like it makes a big difference - from 37 to 43 Mbps

Thats only because it's removed INP, Error Correction and Interleaving.   This hasnt gone from a clean profile. 
I said in the other thread the line was almost behaving like what we'd see when a non-g.inp modem was on the line and I wondered if the DLM would detect in the next day or so that there was actually a g.inp compatible modem on the other end and apply G.INP.  It looks like it has.


Quote
It's a right pain as now I'm getting upstream errors

Why is it a pain?  You had 340 E/S yesterday which is perfectly acceptable.  They crept up very slowly over the course of the day.   
Don't get hung up on them because they occur on most VDSL lines... youre pushing the limit of copper to the highest frequencies.  Even good short lines get Errored Seconds.    E/Secs simply mean that over the course of a second, you got something like a CRC which you wont notice, its done faster than the blink of an eye, fraction of a millisecond. It wont have affected your line performance.
 
If the DLM thinks you are getting too many, then it will apply some form of action - and if need be putting G.INP back on again.  It only puts in on if it thinks the line needs it. 
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

GigabitEthernet

  • Kitizen
  • ****
  • Posts: 2243
Re: G.INP - BT rollout 2015.
« Reply #695 on: August 01, 2015, 04:05:43 PM »

I'd rather have no errors than some errors and with G.INP on before, I was getting absolutely none.
Logged

Dray

  • Kitizen
  • ****
  • Posts: 2361
Re: G.INP - BT rollout 2015.
« Reply #696 on: August 01, 2015, 04:23:19 PM »

Your downstream looks to be the highest it's ever been but your upstream looks to be off by 1.5 Mbps
Logged

roseway

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 43467
  • Penguins CAN fly
    • DSLstats
Re: G.INP - BT rollout 2015.
« Reply #697 on: August 01, 2015, 04:42:59 PM »

Quote
I'd rather have no errors than some errors

So would most people, but it's not something to be bothered about.
Logged
  Eric

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33879
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: G.INP - BT rollout 2015.
« Reply #698 on: August 01, 2015, 04:55:07 PM »

Quote
I'd rather have no errors than some errors

... but but but...  you'd be getting retransmit going on.    :-\

Just because its 'hidden' over a different channel doesn't make the line perfect.   Its not going to stop any SNRm fluctuations or make noise less.   Its just a different way of retransmitting any data lost because of noise.   G.INP still has its own overheads.... and less bandwidth during the time of retransmit.

Personally, I'd rather have not have G.INP on a line that was throwing very few errors! 

G.INP comes into its own when it replaces Interleaving and Error Correction.  If the line has sufficient errors to benefit from Interleaving and RS error correction then g.inp is a very good thing...  but even then there are cases where traditional RS & Interleaving are better than G.INP.   It all depends on the type of burst noise you get.   

When it comes to G.INP, I think some people are getting too hooked up on Errored seconds without looking at whats going on behind the scenes and the bigger picture.  It will simply be shifting the error count elsewhere... and just because it may allow you to sync at a higher rate, it doesn't mean that at times of ReTx your'e getting that full bandwidth.   With g.inp you're unlikely to see Err Secs, but for gawds sake dont start panicking if you look at the figures now for things like LEFTRS because.. oops that line has a few errors and thats now the count of any defects. 
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

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: G.INP - BT rollout 2015.
« Reply #699 on: August 01, 2015, 08:30:43 PM »

If you want zero errored seconds on G.INP your going to have compromise your Sync rate by lowering it by using the capping command or by finding the SNRM sweet spot for your line it's a bit like give and take it's mazing how losing 500 to 2000kbps sync can lower the errored seconds on both US and DS ;)
Logged

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2721
Re: G.INP - BT rollout 2015.
« Reply #700 on: August 02, 2015, 09:20:42 AM »


G.INP comes into its own when it replaces Interleaving and Error Correction.  If the line has sufficient errors to benefit from Interleaving and RS error correction then g.inp is a very good thing...  but even then there are cases where traditional RS & Interleaving are better than G.INP.   It all depends on the type of burst noise you get.   
 


G.INP doesn't always completely replace traditional RS error correction etc.
With my Broadcom chipped HG612 modem on a Huawei DSLAM, DS Interleaving depth of 8, my own connection uses both methods for DS (G.INP Mk2).

Even when pre-G.INP, my connection was on fastpath for DS & US, I saw a low level of FEC/RSCorr error correction.
I believe this was due to Broadcom's proprietary retransmission ability, which seems to have continued since G.INP was activated.

As the attached graphs show, I am seeing an average of around 15,000 RSCorr per day these days.
Pre-G.INP it was typically averaging around 5,000.
Note: The slight seasonal increase in line attenuation that my connection experiences, plus addition of the low interleaving depth possibly account for the RSCorr increase, but with lower overhead.

The big change for my connection though, was the reduction in CRC counts & errored seconds (from around 900 to 1000 ES per day to just one or two).

Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33879
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: G.INP - BT rollout 2015.
« Reply #701 on: August 02, 2015, 01:26:27 PM »

It all depends upon the type of noise experienced by your line, but I would fully expect G.INP to mostly remove CRC & E/Secs. 

With the old way when data was lost through noise burst (if FEC wasn't enabled or the burst was too long for FEC) then a CRC would be triggered.  CRC is the indicator of a corrupt packet and an instruction is issued to re-request the data at a higher layer.    A single CRC should also trigger an Err/Sec, although multiple CRCs in the same second time frame will only record 1 Err/Sec.

With retransmission if data is lost then detection and retransmission is done between the modem and dslam, if an error is detected then it attempts to retransmit from the buffer.   I dont fully understand all the ReTX counters and need to do proper research when I get time, but my understanding is that its ETR/LEFTR where most of this goes on.  LEFTRS would kind of be the equivalent to Errored Seconds, but its not and the two cant be directly compared because its not a count measurement of time when theres been a data error, but a ratio measurement of when LEFTR was below the ETR.

Unlike CRC, Retransmission doesnt keep trying and trying to send data (limited buffer size) and there are times when the noise burst may be too long for ReTX to be able to recover data,  so it is still possible to see the traditional types of errors requiring higher level action.

However because you'd expect ReTransmission to catch most of the data defects, then its obvious that its now counters like LEFTRS are going to be the ones recording data errors first.   I suspect (and again something I need to look further into before saying for certain) that with G.INP, the DLM may also be monitoring something like LEFTRS to determine line performance and if need be adjust DLM parameters.

What I was trying to say with my previous post to Alec is that just because a line isnt now showing any CRCs or Err/Secs it doesnt mean that the line is error free.  We also need to be looking at the Retransmission counters.... and I suspect that DLM will also be monitoring them too. 


ETR = Effective throughput Rate
LEFTR = Low Error Free Throughput Rate/Ratio
LEFTRS= Low Error Free Throughput Seconds




Quote
Even when pre-G.INP, my connection was on fastpath for DS & US, I saw a low level of FEC/RSCorr error correction.

Yes you are correct, DLM can and does indeed apply a low level of FEC protection without swinging into full Interleave and INP.
Im not G.INPed yet but you can clearly see from my R value that my line is using RS encoding on the upstream, but Im not Interleaved.

R:              0               16


Over the past decade we've got used to reading stats in a particular way and many forums (including here) got a bit loose with the term Interleaving when really we should have also been talking about Error Correction.  I've already mentioned several times in this thread that since the advent of G.INP its now more important than ever that we make the distinction between Interleaving, Error Correction and Error Protection because they are 3 separate things that can be applied independently.  In the past we lumped them all together because DLM used to switch them on at the same time.... whereas now the FTTC/NGA DLM doesnt.   
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

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: G.INP - BT rollout 2015.
« Reply #702 on: August 02, 2015, 08:06:57 PM »

What is the unit of data that is considered lost/corrupted or successfully sent Kitz? A fixed-sized block? Small?

What is it that is retransmitted? The data or like harq?
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33879
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: G.INP - BT rollout 2015.
« Reply #703 on: August 02, 2015, 11:42:29 PM »

What is the unit of data that is considered lost/corrupted or successfully sent Kitz? A fixed-sized block? Small?
What is it that is retransmitted? The data or like harq?

Not sure sorry - not gone into it in that kind of depth.   I believe its more like TCP/IP (ARQ) than FEC (HARQ) in how it detects the error,  except the big difference is its done at the physical layer.

Quote
RTx is designed to protect the performance and stability of DSL systems in the presence of impulse noise. It encapsulates payloads into frames that are called data transmission unit (DTU), which are stored in a buffer after transmission. INP is achieved by retransmitting – upon request of the receiver – just those received DTUs that were received with errors.

link
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

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: G.INP - BT rollout 2015.
« Reply #704 on: August 02, 2015, 11:46:55 PM »

@kitz - thanks very much for that.

I need to do some reading up on this.
Logged
Pages: 1 ... 45 46 [47] 48 49 ... 62