Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[NewtronStar]

That simply confirms what I've been saying on here for the past month or so will happen.  IE that G.INP on the upstream will be enabled if (1) DLM detects the line is unstable and needs it and (2) the equipment is G.INP compatible. 
Its why Ive been saying G.INP Mk2 is a much fairer solution and why BT are happy with the fix they put in place.

Quick update to this..........

It seems that reinstatement of US G.INP isn't a permanent measure (Huawei cabinet):-

http://community.plus.net/forum/index.php?topic=136287.msg1252342#msg1252342

Well BE1 i have not witnessed any lines UpStream moving off fastpath to G.INP since the Mk2 rollout began there are odd cases but it's not mainstream.

[kitz]

That simply confirms what I've been saying on here for the past month or so will happen.  IE that G.INP on the upstream will be enabled if (1) DLM detects the line is unstable and needs it and (2) the equipment is G.INP compatible. 
Its why Ive been saying G.INP Mk2 is a much fairer solution and why BT are happy with the fix they put in place.

Quick update to this..........

It seems that reinstatement of US G.INP isn't a permanent measure (Huawei cabinet):-

http://community.plus.net/forum/index.php?topic=136287.msg1252342#msg1252342

Cheers for that BE, although I really dont see what the big mystery is about it over there.   As I keep saying
 
Its still there if DLM deems the line needs it and if the hardware is compatible

Its just one of the available config options available..   so the fact its gone again then DLM must have considered the line stable.
   
Just like with interleaving,  first time you may only get it for a couple of days, but if the line goes unstable again it will switch it back off.   
Same as with the other options such as interleaving, if the line flaps again it will go back on again, only next time for longer, until it gets to the point when its practically permanently on. 





*(attempts to refrain banging head on desk because Im beginning to feel like a stuck record)

[NewtronStar]

Its still there if DLM deems the line needs it and if the hardware is compatible

The Guys and Girls would like to see this happen in realtime over here on someones line to be sure this is the case !

[kitz]

Ive seen it on lines since about the 12th from elsewhere, but if you do want to see it 'here'  then here's a couple for you

From MDWS a couple that have what appears to be Mk2 g.inp upstream   (Not a leftover from Mk1):-

chouse had it, then it went off and then its back again.   An indication that its not Mk1 because otherwise it would have been permanently on.  Mk1 went on and stayed on, if it came off for anything such as line reset then it could only be Mk2 thats put it back on. 


Also Alec R who has a problematic line had it turned on a few days ago..  his cab went live in June, so one of the latter batch which will have gone straight to G.INP Mk2.  With his line being a bit erratic DLM has obviously decided he needs it.

54 on the downstream and 42 on the upstream

You can see on the attached MDWS screen grab that not only is G.INP turned on for the upstream, but its busy doing doing retransmitting of data for both up and downstream.   

Compare to someone like jelv who also has Mk2 g.inp turned on for downstream only, but look at his retransmits - practically zilch.  Jelv has a good short line and doesnt really need g.inp at all.

[NewtronStar]

If you are going to use AlecR as an example i have looked back 60 days and his US errored seconds were non-existent when interleaved and still non-existent after G.INP was enabled i would not call that a problematic line to issue G.INP on the Upstream ok maybe 2 blips in 60 days

[kitz]

But interleaving and Error Correction was switched off when G.INP was applied.   
So in other words the DLM knows that his line needs something.   It wouldnt have applied Interleaving if the line was hunky dory and it was the interleaving and error correction that was keeping the Err/Secs down.

Its not clear at the present time on the new system whether G.INP is a step down from interleaving and ErrCorrection, but I would imagine since we know that DLM can apply a mix of G.INP, FEC Error Correction & Interleaving, and we know that G.INP is the lesser evil, so its a non-brainer to deduce that DLM will apply G.INP first and if still not stable then apply FEC/Interleaving.

There must be something/ some counter in Alec's stats that prevented the DLM from completely removing FEC&Interleaving, but instead has applied the middle ground of G.INP.   If Alec's line was completely OK then DLM would have removed upstream G.INP.
We can see from his data that he is making use of retransmitted data on both up and down.

[NewtronStar]

There must be something/ some counter in Alec's stats that prevented the DLM from completely removing FEC&Interleaving, but instead has applied the middle ground of G.INP.   If Alec's line was completely OK then DLM would have removed upstream G.INP.
We can see from his data that he is making use of retransmitted data on both up and down.

Yeah when looking at my G.INP DS re-transmit tx/min it looks worse than AlecR's yet his US is having to retransmit more often 

[burakkucat]

Ah, yes, I see.

So that is further confirmation that AlecR's circuit is not in the best health for the US direction.

[GigabitEthernet]

Did I hear my name!

The benefit of G.INP for me has to been so significantly reduce my ping times. I'm down to 8ms pings from 30ms pings previously (to the BBC).

FECs are still pretty high on the downstream but on the downstream they are pretty low and I'm getting absolutely no CRCs or ES on the downstream, nor the upstream.

[burakkucat]

In the light of what you have reported, we can conclude that "G.Inp just works". 

[NewtronStar]

In the light of what you have reported, we can conclude that "G.Inp just works". 

Of course it's works for him B*CAT the Mk2 is running on both downstream and upstream
it would be my preference to have the upstream G.INP'd on my line as all i see is more US errored seconds on MDWS than DS errored seconds.

kind of knew once the US G.INP was removed the users focus would go straight to the errored seconds on upstream but the MDWS DLM calculator (traffic lights) helps with those anxieties to keep things in perspective 

[Terranova667]

I know it's only been 11 days into August but are there any signs yet of the ECI G.INP roll out ?  that said i don't even know if the roll out for Huawei has been completed yet . 

[Dray]

http://forum.kitz.co.uk/index.php/topic,15921.msg296413.html#msg296413

[NewtronStar]

Yeap I guess the Plusnet Forum users also need to be updated 

[kitz]

Yep...  g.inp has nothing to do with vectoring and crosstalk either. 

• Crosstalk is noise leakage from an adjacent line. It's a constant & crosstalk is there all the time. (Unless the other party turns off their modem).
• Vectoring is a noise cancellation technique and therefore improves SNR.  Improved SNRm means a higher sync speed.
• Retransmission is a method of error correction.  It's an 'on the fly' based solution that works to recover data packets lost through certain types of noise bursts. - Note noise bursts NOT crosstalk!
  

Retransmission does not work for all types of noise.. It is NOT noise cancellation and therefore has absolutely no effect on SNRm to be able to give an increase in sync speed.  Retransmission works well for REIN type noise... ie short bursts...  and its all about data recovery of lost packets caused by noise bursts.

Traditionally lines suffering from say REIN type noise would have Interleaving & Error Correction applied using RS encoding which carries an additional overhead. 

Where G.INP can give some sync speed back is if you suffer from REIN type noise and previously had RS Error Correction applied.   By using G.INP rather than RS encoding then you can take away the redundant overheads.   Note: G.INP can only give back what RS encoding may have taken away. It most certainly does not magically give back any sync speed lost through cross-talk.   

Vectoring and g.inp work well together.    Vectoring reducing ingressed line noise and Retransmission working to recover any data packets which may have been lost from environmental type noise.