Print

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

[simoncraddock]

This kind of takes me back to a question I posed to Asus in October which they didn't answer.

Could the high attainable rate be the cause of the unusually high FEC count when interleaved?

I guess this topic has drifted way off course, so I'll leave it at that.

[Ixel]

Not sure where you're seeing your statistics, but on mine they seem to be accurate with exception to FEC obviously (e.g. I don't have more ES+SES than I do CRC errors on mine).

The attainable rate is mis-calculated somehow, my theory is that it might be calculating the attainable rate of what it would be at around 0 dB SNRM. I don't think it's causing the abnormal FEC count .

[kitz]

Kitz yeah but have you seen any other modems over estimate by such a large number? to have that estimate on a 6db margin is completely whacked.

Nope.    In theory the maximum bit loading on a line that is perfect is somewhere just a little over 3Mbps per 1dB of SNRm or 3.8 Mbps if there were no PSD masks.. and Ive no idea how much effect PCB will have.

Also remember the router reports an average figure for the SNRm so there may be some tail end tones which couldnt load any more bits into the bin even if there was a 1dB rise.  (It needs 3dB over base line to load one bit).   

So basically take attainable with a pinch of salt when interleaved.

Unfortunately yes.  The modems dont seem to adjust correctly to RS overheads.

Could the high attainable rate be the cause of the unusually high FEC count when interleaved?

Not the FECs - unlikely.

The attainable rate is mis-calculated somehow, my theory is that it might be calculating the attainable rate of what it would be at around 0 dB SNRM.

More likely no proper adjustment for error correction overheads and its somehow adding the RS Correction redundancy on to the throughput figure.   In cases like this then you'd expect the max attainable to increase each time a greater depth of Interleaving & Err/Corr is applied by the DLM.
Another area is that it may not be adjusting properly to PCB or PSDmasks and performing the calculation without due consideration that those particular tones wont attain any higher sync speed regardless if there is more SNRm.   Bearing in mind that PSD masks can easily knock 2 or 3 bits per bin out.. that could amount to quite a bit of sync speed.

[hacktrix2006]

I wonder if this change will also be put on for ADSL lines as well? I can not wait for Fiber to become live in my area.

[Ixel]

As far as I know Sky already have physical retransmission (and something called Nitro) on their own ADSL services (not any service through BT's equipment that is).

EDIT: A member at OcUK said the G.INP rollout would be happening as of Wednesday, not sure on his source of information but I'll be eagerly watching my local cabinet for changes from that day onwards. If anyone here can confirm the above then please do .

[Black Sheep]

It rolls out as of today (12th Jan 2015). 

[Ixel]

It rolls out as of today (12th Jan 2015). 

Thanks for the confirmation Black Sheep! Much appreciated.

One final question if I may ask, do you know whether it's something that will take time to rollout (e.g. days, weeks), or is it likely to be a change done overnight? I presume it will take a little bit of time to rollout unless BT have done preliminary work weeks before hand and just need to 'flip a switch' to make use of it.

[Chrysalis]

It rolls out as of today (12th Jan 2015). 

isnt this already used on interleaved connections, INP is the 2nd field on the right in ronski's tools and it has always been a non 0 value when interleaved.

Or is that a different implementation of INP.

[Ixel]

It rolls out as of today (12th Jan 2015). 

isnt this already used on interleaved connections, INP is the 2nd field on the right in ronski's tools and it has always been a non 0 value when interleaved.

Or is that a different implementation of INP.

G.INP / PhyR / Physical Retransmission is different to the traditional INP we're used to seeing.

The big difference is that it only is used to tackle errors when they occur rather than be constantly running on the connection like it is at the moment. This as such should mean higher sync rates because of no constant overhead, and finally low latency because of no constant delay as it's only used when an error needs to be tackled rather than all of the connection's uptime .

I believe the INPRein statistic reported on the HG612 might change, as that's part of G.INP.

[Chrysalis]

So the improvement will only be seen by interleaved lines because fast path has no error correction overhead?

[Ixel]

So the improvement will only be seen by interleaved lines because fast path has no error correction overhead?

It will benefit both fastpath and interleaved if BT enable it by default rather than possibly allowing DLM to turn it off and on, as it should correct some or a lot of ES as I understand (due to its dynamic nature of tackling errors).

If G.INP is enabled all of the time then I presume interleaved will eventually only be used in situations where G.INP isn't quite able to handle poorly performing lines (if any such event will happen).

[Black Sheep]

It rolls out as of today (12th Jan 2015). 

isnt this already used on interleaved connections, INP is the 2nd field on the right in ronski's tools and it has always been a non 0 value when interleaved.

Or is that a different implementation of INP.

G.INP / PhyR / Physical Retransmission is different to the traditional INP we're used to seeing.

The big difference is that it only is used to tackle errors when they occur rather than be constantly running on the connection like it is at the moment. This as such should mean higher sync rates because of no constant overhead, and finally low latency because of no constant delay as it's only used when an error needs to be tackled rather than all of the connection's uptime .

I believe the INPRein statistic reported on the HG612 might change, as that's part of G.INP.

A great explanation as to how G.INP (as I perceive it) will work. Alas, as it's not really engineering related, we have hardly had any info surrounding the roll-out, or the timescales involved. I wish I had more info to share, but genuinely don't. 

[Ronski]

No idea if it's related but my connection was down from 16:02 and came back up at 17:23. No stats were logged, but the modem was responding with the following.

12/01/2015 16:02:03.159 - ERROR!!! - Status = Idle
12/01/2015 16:02:03.159 - ERROR!!! - Couldn't determine Modem in use, exiting

Before and after speeds are virtually the same

[Chrysalis]

So the improvement will only be seen by interleaved lines because fast path has no error correction overhead?

It will benefit both fastpath and interleaved if BT enable it by default rather than possibly allowing DLM to turn it off and on, as it should correct some or a lot of ES as I understand (due to its dynamic nature of tackling errors).

If G.INP is enabled all of the time then I presume interleaved will eventually only be used in situations where G.INP isn't quite able to handle poorly performing lines (if any such event will happen).

My concern with g.inp is it potentially will cause jitter due to delys been on and off depending on errors.  But I guess its vastly superior to permanent higher latency caused by interleaving.

[adslmax]

Strange - My Billion VDSL2 sync showing no retrain or disconnected yet by BT roll out? I don't think it haven't rolled out yet!