Print

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

[William Grimsley]

Alright, fine. Sorry.

NS, yes I do understand.

I can see why you think that I may loose speed, Tony. Maybe interleaving works differently on FTTC, but I always thought like previously mentioned that G.INP was like interleaving (error correction), but obviously not. Ok, maybe mlmclaren can chip in with his reasons...

I have asked mlmclaren to post in this read with his reasons...

Admin note Interleaving does not work any differently on FTTC.
G.INP is an advanced form of error correction that only corrects when an error has occured.  Unlike FEC which carries redundancy 100% of the time

[kitz]

>> What I'm trying to say is on ADSL the line rate is normally higher when the line is in an intereleaved state rather than a fastpath state.

I think I understand what you mean now.   Yes the maximum line rate does get inflated when the line is interleaved, but unfortunately its a false figure :/

 
This is something we have been aware of for years that some modem/routers do when the line has INP applied.   
INP/FEC has overheads which are carried 'outside' of the actual sync.  The figure is just that, an estimate by the modem, but these FEC overheads skew the estimate and a lot of modems increase the max attainable rate, but its a false figure that must never be relied on.

Go look at Chrys's line stats on MDWS - he doesnt have G.INP or INP/FEC nor is he banded. 

His current sync rate is:   72089
His max attainable rate is: 72948
His SNR Margin is 6.3dB

Its the 0.3bB which will give him that little bit of extra speed if he was to perform a resync at this moment in time.
His modem is correctly calculating the max attainable.

Now lets look at Callumpy's line - he has INP=3

His current sync rate is:   72079
His max attainable rate is: 84156
His SNR Margin is 6.3dB

Practically the same stats as Chrys.  So why the additional 11Mbps max line rate? 
Its a false figure that has been inflated because of FEC overheads.  INP/FEC has eaten into his SNRm   

There will be some additional speed in there that G.INP could give back... I'd estimate around 7 Mbps for Callumpy's line.


G.INP is a replacement for INP.  They are both methods of error protection.  G.INP is just more efficient.
If the line doesnt already have INP then it cant give any more.

-----

There is one other thing that wombat and I have been looking at which we haven't yet got the to bottom of and thats the effect of the framing parameters.    These are to do with the size of the data transmitted in a frame (packet) and those R & N values etc that you may see us discussing from time to time.

Framing parameters is why some lines will sync at say 80000, yet another may sync at 79987.   Framing parameters are slightly different with g.inp so you may get also get a wee bit more speed on top say 0.5-1Mbps, but it wont give you 46Mb when youre currently syncing at 40098 with 6.3dB...  You may get another ~1Mbps or so depending on time of day you sync.

[William Grimsley]

Framing parameters is why some lines will sync at say 80000, yet another may sync at 79987.   Framing parameters are slightly different with g.inp so you may get also get a wee bit more speed on top say 0.5-1Mbps, but it wont give you 46Mb when youre currently syncing at 40098 with 6.3dB...  You may get another ~1Mbps or so depending on time of day you sync.

That's interesting, as I was syncing at 1 Mbps higher yesterday!

Thanks for the rest of your post, I didn't want to quote it all and reply to it but understand it all.

Admin note:  You missed the point I was proving whereby and Interleaved Line skews the maximum attainable rate.
The 1Mbps of higher sync was down to having better SNR at that moment in time.

[ejs]

I certainly get a higher ADSL2 line rate with interleaving on than with interleaving off. Yes, the actual line rate, not the max attainable rate.

Essentially, I think the modem takes the error correction ability of the interleaving and FEC into account when determining what speed it can establish a stable connection at.

In more technical terms, I think that "taking into account" is sometimes known as the coding gain. The modem has to determine the best speed it can get, subject to the line and environment itself, and various parameters, one of which is the bit error ratio. The bit error ratio is defined as being after the bits have been through the interleaving/FEC processing. So when the modem knows its has a certain level of error correction, it can take that into account when determining what speed it can connect at and meet the bit error ratio requirement.

The FEC data occupies a portion of the line's bandwidth, this is not included in the line rate reported by the modem. So the interleaving/FEC process does not necessarily have to result in an overall reduction in the net data rate, it depends on if the bandwidth used by the FEC data is greater than what extra bandwidth is obtained from the coding gain.

I'm not so sure if the modem can take the error correction ability of G.INP into account when determining what speed it connects at, but if that's allowed, then yes, G.INP could result in a higher speed. G.INP also adds some more parameters that affect the line initialisation process.

@tbailey2
Aren't the retransmitted DTUs sent over the same bearer that they were originally sent over the first time? So extra bandwidth is only needed for the acknowledgements that control the retransmissions, the RRC adds 24 bits every data frame, which the G.998.4 PDF says works out at 96kbit/s.

@kitz
Err, G.INP does not replace INP. INP is a calculated value that shows the level of error protection provided by either FEC and interleaving, or the retransmission procedure of G.INP. G.INP provides higher levels of INP. I wouldn't say INP is a method of error protection either. If say the DLM decides to set the INP level to 3, then the DSLAM has to set the interleaving depth and FEC ratio to provide that level of INP.

[William Grimsley]

To start, I think we need to give ejs a massive clap for that information, some of that went straight over my head but I think I've got the jist of it.

ejs, are you basically saying that even if FEC wasn't applied to the line in it's current state, G.INP COULD increase the line rate? Or, have I still got this wrong?

[kitz]

@ejs

I was trying to simplify it for William. 

Ive already tried linking to INP & G.INP on more than one occasion, so was just taking it down to a basic level of understanding.

[William Grimsley]

Just had my first Downstream CRC spike of the evening, I'm very surprised the line didn't loose sync! Everyone started breaking up on TeamSpeak!

[NewtronStar]

I think we need to give ejs a massive clap for that information.

I would if he/she could predict your sync rate before G.INP is activated on your circuit 

[William Grimsley]

Ive already tried linking to INP & G.INP on more than one occasion, so was just taking it down to a basic level of understanding.

I do read the web pages, kitz. But, you can never rely on information that's for general use for one specific circuit.

Admin Note:  Any info on the main site is technical facts and how the technology works.   These facts should in theory apply to ALL lines.

[ejs]

I'm not so sure if the modem can take the error correction ability of G.INP into account when determining what speed it connects at, but if that's allowed, then yes, G.INP could result in a higher speed. G.INP also adds some more parameters that affect the line initialisation process.

Now that I've eventually posted that and thought about it a little more, no, G.INP probably can't really be used to increase the line speed in the same was as interleaving and FEC add coding gain. The difference is that the interleaving and FEC is going to be there whether there's anything for it to correct or not, so you might as well use it. With G.INP however, using more retransmissions would use more bandwidth, so you wouldn't want to overdo it and aim for a higher speed anticipating to do a lot of retransmitting to fix the errors, because all that retransmitting would use too much bandwidth.

[kitz]

I certainly get a higher ADSL2 line rate with interleaving on than with interleaving off.

Interleaving/FEC usually reduces the line rate, because of the redundancy overheads.
Thats why G.INP was invented - to quote Broadcom (Inventor of PhyR/Retranmission) -

"Traditional methods of error correction steal your bandwidth."

The RS + Interleaver scheme suffers from a high overhead burden because for every errored byte, two
additional overhead bytes must be transmitted to allow for a successful FEC correction. For example,
assuming that an overhead of 10% correctable is tolerable, correcting a burst of 1 ms of impulsive noise
(INP = 4 DMT symbols) requires an interleaver depth (or delay) of minimum 10 ms:

The two reasons why most people complain about standard INP with Interleaving and FEC is
1) Increased Latency.
2) Reduction of sync speeds.

---
ETA
Forgot to add link.

[ejs]

kitz, that same Broadcom whitepaper also complains about the coding gain, saying that it's been "double-booked", which it describes as "organized cheating".

[kitz]

With G.INP however, using more retransmissions would use more bandwidth, so you wouldn't want to overdo it and aim for a higher speed anticipating to do a lot of retransmitting to fix the errors, because all that retransmitting would use too much bandwidth.

Retransmission is 'hidden' from view.  It only penalises [throughput] speed when in use.
This is why for certain types of noise, such as constant REIN, then traditional Interleave & FEC is more beneficial.
G.INP/Retransmission/PhyR works best on burst type noise such as SHINE.

Reference ASSIA

[NewtronStar]

The two reasons why most people complain about standard INP with Interleaving and FEC is
1) Increased Latency.
2) Reduction of sync speeds.

G.INP has decreased latency from 45ms to 30ms distance to London server 371 miles but I don't know the true route.

[kitz]

@ ejs

Yes it does

"RS FEC capabilities are, therefore, double-booked. In practice, an additional 2–3 dB margin is required
to recover the expected BER and INP figures, at the cost of huge capacity loss"

This is why you get the reduction in capacity, because it 'eats' into at the SNR margin.
That 2-3dB less margin results in even less available sync speed available to the EU.