Print

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

[ktz392837]

I am on an ECI cabinet but if pigs fly and we get G.INP does it help with reduced sync speeds due to crosstalk? I have been hit quite hard by crosstalk but my line has not gone to interleaved yet.  Thanks

[kitz]

Don't expect miracles, its a long way short as anything like a cure for crosstalk. The most you could expect is a couple of Mb.
Some of this increase may occur due to a slight increase in power that seems to happen on many lines at the same time g.inp is enabled.

Where it mostly helps is on those lines which have say lost sync speed due to crosstalk and then have interleaving and error correction applied, because the overheads are so much less with g.inp, so the benefit for them is reduced latency and less overheads, & higher sync.   
 

[WWWombat]

My line ran, pre-G.INP, at 60 ES's per day. That is a trivial level, a couple of orders of magnitude below DLM's interest-level. There was no FEC or interleaving running.

When G.INP intervened, my sync speeds stayed at 80/20, but my attainable speed increased by around 7Mbps. There is little to explain why, other than to believe that some overhead has been removed, or some low-level convolutional line coding has altered.

I don't think G.INP should have effect on lines like yours (noise level hit by crosstalk, but not the error rate). But something does appear to be happening, though. Whatever it is, it defies normal explanations.

[Bald_Eagle1]

I am on an ECI cabinet but if pigs fly and we get G.INP does it help with reduced sync speeds due to crosstalk? I have been hit quite hard by crosstalk but my line has not gone to interleaved yet.  Thanks

I'm around 1100m from the cabinet & my DS sync speed has reduced from around 30 Mbps to 22.4 Mbps due to increased crosstalk since FTTC was installed in 2011.

My connection's speeds have been capped/banded at 22.4 Mbps / 5 Mbps for many months, with the last few months being on fastpath (actually 22399 Kbps / 4999 Kbps).


Although on fastpath (Interleaving depth 1 for both DS & US), I did see lowish levels of DS & US FEC (RSCorr), with zero INP, INPRein & delay.
I believe that was due to Broadcom's own phyReXmt retransmission technology, not G.INP.


The sequence of events whenever another crosstalk disturber was added have ALWAYS been as follows:-

SRNM would show a sudden, but smallish (up to 2 dB) reduction.
Various error counts would increase (particularly ES & CRC).
This position would be sustained for a few days until the connection resynced at a lower speed, with SNRM being reinstated to the usual 6 dB.


We do experience occasional power cuts where I live (properties closer to the cabinet are not affected).
Before my connection speeds were banded, my connection would sync with SNRM still at 6 dB, but with sync speeds around 5 Mbps higher when power was restored.

After a few minutes or so, SNRM would reduce, often to below 1 dB, but the higher sync speed would be maintained.
This would last for a couple of days until the connection would resync at the usual lower speeds, with SNRM back to 6dB again.

My conclusion is that as my VDSL2 HG612 modem syncs up quicker than typical ADSL modem/routers, I would experience a few minutes of low crosstalk until the ADSL modems in my area had synced up again.

I presume that as other VDSL2 & ADSL modems closer to the cabinet had remained in sync throughout due to not experiencing the power cut, some crosstalk would be present when my connection synced & thus my speeds weren't temporarily restored to the 30 Mbps.

Now that my connection's sync speeds are banded, I do see temporarily increased attainable rates following a power cut, but no increased sync speeds.


I have been reliably informed that the FTTC cabinet is now full, so I am unlikely to see much in the way of further crosstalk increases from VDSL2 connections, but I could possibly see increases whenever more ADSL connections are installed.




See the attached montage for how my connection stats changed when G.INP was activated 23/03/15.

Important error counts such as ES, CRC, RSUnCorr & possibly HEC have all but disappeared since G.INP was activated, but as SNRM is still around 6 dB, there has been no increase in attainable rates or sync speeds.

e.g. DS ES was running at around 1000 per day pre-G.INP. It is now usually 1 or 2 per day.


So, in summary, some users will see improved speeds when G.INP is activated (subject to having sufficient SNRM & probably previously interleaved) & others, such as myself will see vastly reduced error counts, but no improvement in SNRM & therefore no improvement in sync speeds.

[Chrysalis]

the whole ECI situation is a complete mess.

There are users like me and kitz happy on fast path and it looks like doomsday is approaching to artificially limit our performance because someone in openreach has decided the interleaving is acceptable.

As far as my souce is aware my cabinet is due to be switched in the 2nd week of june. So 6 weeks of fast path performance left.

[Chrysalis]

My line ran, pre-G.INP, at 60 ES's per day. That is a trivial level, a couple of orders of magnitude below DLM's interest-level. There was no FEC or interleaving running.

When G.INP intervened, my sync speeds stayed at 80/20, but my attainable speed increased by around 7Mbps. There is little to explain why, other than to believe that some overhead has been removed, or some low-level convolutional line coding has altered.

I don't think G.INP should have effect on lines like yours (noise level hit by crosstalk, but not the error rate). But something does appear to be happening, though. Whatever it is, it defies normal explanations.

A possible reason is they boosted the transmit power because they believed g.inp can handle the increased errors from crosstalk.

I am pretty sure when new lines get enabled the dslams are configured to reduce power output to existing lines as a means of crosstalk management.

[kitz]

A possible reason is they boosted the transmit power because they believed g.inp can handle the increased errors from crosstalk.

Ive seen this occur on several lines (but not all) too.  The increase in power could certainly account for some of the speed boosts.  Some users have also seen different PSD shaping - some are weird (such as NewtronStars irrc).

I am pretty sure when new lines get enabled the dslams are configured to reduce power output to existing lines as a means of crosstalk management.

Im not sure on this one. I cant recall ever seeing reduction of power after taking a crosstalk hit.  afaik it previously depended on the PSD mask based on 1) Distance from cab to exchange & 2) Distance between EU and cab.

[WWWombat]

A possible reason is they boosted the transmit power because they believed g.inp can handle the increased errors from crosstalk.

Ive seen this occur on several lines (but not all) too.  The increase in power could certainly account for some of the speed boosts.  Some users have also seen different PSD shaping - some are weird (such as NewtronStars irrc).

On my line, D1 increased in power by 0.1dB at the activation of G.INP, D2 increased by 0.3dB, but D3 decreased by 0.3dB; bitloading puts almost the same number of bits in each section (slightly less in D2, slightly more in D3). The combination changed from 13.0dB to 13.1dB - a difference that was regularly seen on my old line from reading to reading.

The PSD shape stayed the same.

On balance, I don't think power explains the differences - we'd need to see something more like 2dB, not 0.1dB.

I am pretty sure when new lines get enabled the dslams are configured to reduce power output to existing lines as a means of crosstalk management.

Im not sure on this one. I cant recall ever seeing reduction of power after taking a crosstalk hit.  afaik it previously depended on the PSD mask based on 1) Distance from cab to exchange & 2) Distance between EU and cab.

I doubt this too, and beyond more than just the experience of my line.

In the downstream direction, the aim has to be to transmit with equal power on every line; otherwise you deliberately infect the lower power lines with crosstalk. If activation of G.INP allows for lower power, then it has to be done on every line - including the ones that have fallen back to interleaving.

The problem is that every line will then still be troubled by the same amount of crosstalk relatively (slightly less noise, but slightly less signal too), so the amount of data won't change. But the reduced signal strength will now reduce speeds - especially to distant lines - and reduce range too. Is that desirable?

Things are a little different upstream, where UPBO may indeed reduce powers a little more. But here, my (short) line's power was the same - in fact, it was slightly higher power in U0 and U1, but slightly lower in U2, which (I think) is the opposite way around from what I'd expect if there were an intention for my line to interfere less.