Print

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

[Bald_Eagle1]

Finally, see the attached snapshot examples ('normal' stats from before the power cut, at the resync just after the power cut & after the connection resynced again after hanging on with very low SNRM for a few days.

The temporary improvement in QLN is very noticeable (still not quite as good as it was pre-crosstalk days though).

[tbailey2]

As an experiment to see if it's useful, a couple of days ago I changed the larger of the MyDSLWebStats All User Stats displays to show, by highlighting the two values (downstream only currently), anyone who has an FEC count > 0 and with Interleaving set to 1 that might indicate G.INP is running on the line. 

There is one user at the moment with consistent FEC counts in the 600-2000 area and no Interleaving. As of today, at least four others  now pop up occasionally [several attached] (including yourself).

Both cab types are affected.

[Ixel]

Just for reference, I have attached the FULL__Monty montage for that period to show all the various error counts etc.

We can see that my connection is on fastpath these days, but some DS FECs can be seen, indicating that PhyR is now active on my connection.



Edit:

Note the expected increase in some error counts & 'interesting' decrease/lack of some during that period.
It appears that all DS RS was OFF during the period.

Is 'bearer 1' showing up on your stats output, not just bearer 0? If so then it's extremely likely that G.INP is active (not to be confused with PhyR, a technology unique to Broadcom DSLAM and modem chipsets paired together).

[Bald_Eagle1]

Is 'bearer 1' showing up on your stats output, not just bearer 0? If so then it's extremely likely that G.INP is active (not to be confused with PhyR, a technology unique to Broadcom DSLAM and modem chipsets paired together).

No. It's still showing Bearer 0 at the moment.

I have seen mention of Bearer 1 being in use on some connections, so I'm keeping an eye open for when/if it appears.

From what I can gather, G.INP is only applied if a connection actually needs it.
Maybe mine doesn't need it at the moment?




I have seen lowish FEC counts ever since my connection was switched to fastpath (quite a long time ago).
So I assumed that was proof that my HG612's Broadcom chipset is now making use of the PhyR technology.

[Ixel]

I see. Unfortunately as I understand G.INP, bearer 1 must be active as retransmission is used via bearer 1 (which will have some INP and delay in comparison to bearer 0 which should be fastpath still). In addition to bearer 1 showing up, on the same stats output you'll see G.INP framing parameters output as well as the number of ReTx's corrected, uncorrected and what not. I'm eagerly waiting for G.INP to show up on mine as I believe it would work much better than the traditional interleaving.

[Chrysalis]

Just for reference, I have attached the FULL__Monty montage for that period to show all the various error counts etc.

We can see that my connection is on fastpath these days, but some DS FECs can be seen, indicating that PhyR is now active on my connection.



Edit:

Note the expected increase in some error counts & 'interesting' decrease/lack of some during that period.
It appears that all DS RS was OFF during the period.

Is 'bearer 1' showing up on your stats output, not just bearer 0? If so then it's extremely likely that G.INP is active (not to be confused with PhyR, a technology unique to Broadcom DSLAM and modem chipsets paired together).

now I am confused, I asked if phyr and g.inp are the same and the answer was yes, but you saying they not?

[Ixel]

Just for reference, I have attached the FULL__Monty montage for that period to show all the various error counts etc.

We can see that my connection is on fastpath these days, but some DS FECs can be seen, indicating that PhyR is now active on my connection.



Edit:

Note the expected increase in some error counts & 'interesting' decrease/lack of some during that period.
It appears that all DS RS was OFF during the period.

Is 'bearer 1' showing up on your stats output, not just bearer 0? If so then it's extremely likely that G.INP is active (not to be confused with PhyR, a technology unique to Broadcom DSLAM and modem chipsets paired together).

now I am confused, I asked if phyr and g.inp are the same and the answer was yes, but you saying they not?

I'm trying to find the information again that I once find sometime ago regarding the differences between PhyR and G.INP, but G.INP is just the standardised variant of Broadcom's PhyR (where PhyR only works when both the DSLAM chipset and modem chipset are Broadcom and PhyR capable). In such event that PhyR isn't available then G.INP is the fallback. I'll edit this post again if I can find the information stating the comparison.

[Chrysalis]

just gets worse and worse for us ECI dslammers.

[Ixel]

Well, shouldn't matter because BT are using the G.INP ITU standard. I can't find the information which I found sometime (year or more possibly) ago again, I should've bookmarked it. However looking at current information through Google I can't find a significant difference in the two technologies, only that G.INP is an ITU standard based on PhyR and that PhyR is a trademark by Broadcom and designed to work in tandem with paired equipment using a Broadcom chipset with PhyR capability. I'll keep looking.

[tbailey2]

just gets worse and worse for us ECI dslammers.

One of the ones that shows up on MyDSLWebStats is on ECI though (not BE1)  ...

[Bald_Eagle1]

Just to add..............

I think the connection stats I have seen with Bearer 1 in use were from either a Billion or a ZyXel modem i.e. not a HG612 as I use.

I am connected to a Huawei DSLAM though.

[kitz]

Thats my understanding too - Its the same thing.   
The technology was originally invented by Broadcom which they trademarked as PhyR and at first it was only available on Broadcom equipment.   

In 2010 the ITU approved and standardised it as G.INP (G998.4) so it could be used on all equipment.

It may also be known as ReTransmission (or ReTX by BT).     

[Ixel]

It looks like the old name was PhyR, a technology originally by Broadcom sometime before G.INP was standardised based on PhyR - now currently called G.INP. I still can't find the information I had once found so perhaps that information in itself was incorrect (and later on removed from existence).

Anyway, to conclude I believe G.INP is fundamentally the same technology as PhyR - just that PhyR is the old name trademarked by Broadcom and so the correct and current name is G.INP.

[WWWombat]

Strictly, I think the proper name since standardisation is G.998.4, while G.INP was the provisional name during the standardisation process (similar to G.vector and G.993.5). While Broadcom came up with the PhyR idea, and had their own product based on it, I'd guess that standardisation has changed the implementation somewhat.

Also note that it is technically feasible for FEC to be turned on without interleaving - resulting in D=1, but for RScorr and RSuncorr to accumulate - with nothing to do with G.INP. If the RScorr and RSuncorr are accumulating due to the FEC process alone, you'd expect to see D=1 and R>0. It isn't going to be as effective as when interleaving is also activated, but it still works. I've seen it happen plenty of times on the upstream, but (IIRC) only once downstream (and if I am wrong, then it is zero times).

It'd be interesting to see what the values are for "INP" (and INPrein, if it is shown), "delay" and "R" when the "FEC errors without interleaving" scenario is happening downstream.

[guest]

From what I can gather, G.INP is only applied if a connection actually needs it.

Ummm using RS first would basically negate the potential bandwidth gains to the end-user but BT don't seem too keen on vectoring which maybe is down to overall backbone network capacity problems so they may not care at this stage.

From what I know of the vectoring rollouts in other EU countries the gains are significant in terms of sync speeds - very significant in comparable infrastructure countries like Ireland. BT would probably have to offer a 120Mbps down/20Mbps up service which may be why they're behind every country in the EU bar Greece (IIRC) in terms of vectoring deployment/trials.

Sky's core network hit 2.1Tbps at 11am on xmas day (110% increase on previous year IIRC) so what was BT's core network like given they have the bulk of the VDSL2 customers?

There are very few technical reasons why BT shouldn't be a LOT further along the vectoring path. Probably a lot of beancounter reasons though - like all the cabs they'll have to retrofit?

Interestingly the good Rev's speedtester (sod.ms/fast) is now reporting a consistent burst rate of 79-80Mbps whereas a few weeks back (before a remote resync on the Sky SR102) it was around 75Mbps. I use sod.ms/fast because its unlikely to feature in the traffic prioritisation lists of the larger ISPs - the test is very basic but there's more than enough bandwidth on the server end so you can see fluctuations.

Oh and I've just noticed that my connection latency (ping) has dropped to 7ms from 9ms so I guess the last SR102 f/w upgrade & then the forced resync suggest g.INP is active. The Sky router means I can't see if that's the case but frankly it works well enough (I don't use wireless) that I cba to change it even out of curiosity.