I am very surprised to see you with all three reds lit up on MDWS DLM error status indicator
Thank you, licquorice. You're a star.
Yeah, may text Glenn next week see what he thinks.
Thanks, NS. Nice burst of Downstream SES then, how many SES does it take for the sync to drop? 50?
Well, it looks like my line is going to get a bit of a wake up call tonight!
I've been told by mlmclaren that G.INP will increase my line rate! :D
18/04/2016 - Full Line stats immediately after product upgrade.
Note: Cap still in place. G.INP removed and Interleaving and Forward Error Correction applied. Overheads from FEC redundancy reduce line rate.
xDSL
Mode VDSL2
Traffic Type PTM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 6.6 6.3
Attenuation (dB) 25.8 0.0
Output Power (dBm) 12.0 5.8
Attainable Rate (Kbps) 45458 8015
Rate (Kbps) 34999 8015
B (# of bytes in Mux Data Frame) 47 239
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 64 42
R (# of redundancy bytes in the RS codeword) 14 0
S (# of data symbols over which the RS code word spans) 0.0436 0.9514
L (# of bits transmitted in each data symbol) 11368 2018
D (interleaver depth) 743 1
I (interleaver block size in bytes) 62 120
N (RS codeword size) 62 240
Delay (msec) 8 0
02/02/16 - Line stats with new router
Downstream Upstream
Line attenuation (dB): 25.8 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 35000 8493
SNR margin (dB): 9.7 6.7
Power (dBm): 12.0 5.8
Interleave depth: 8 2
INP: 54.00 53.00
G.INP: Enabled
Attainable Rate (Kbps) 44479 8897
RSCorr/RS (%): 0.0001 0.0010
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 0
Like I've said interleaved ADSL lines have increased line rates, whereas fastpath ADSL lines have lower line rates...
I've been told by mlmclaren that G.INP will increase my line rate! :DDid he say how G.INP will increase your line rate?
. . . but I still think as other like mlmclaren have pointed out that when G.INP activates, my line rate will go up by 4 - 5 Mbps...
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.
I think we need to give ejs a massive clap for that information.
Ive already tried linking to INP (http://www.kitz.co.uk/adsl/interleaving.htm) & G.INP (http://G.INP) on more than one occasion, so was just taking it down to a basic level of understanding.
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.
I certainly get a higher ADSL2 line rate with interleaving on than with interleaving off.
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.
The two reasons why most people complain about standard INP with Interleaving and FEC is
1) Increased Latency.
2) Reduction of sync speeds.
@NS
ejs, is very knowledgeable - far more than me when it comes to modem/routers/firmware etc.
"RS FEC capabilities are, therefore, double-booked. In practice, an additional 2–3 dB margin is requiredI think what the Broadcom whitepaper is saying, is that if you switch on interleaving to fix errors, and then what interleaving does is also add coding gain, you'll be back where you started needing to fix errors. It's saying interleaving isn't much good at fixing errors, so you'll also need to increase the target noise margin.
to recover the expected BER and INP figures, at the cost of huge capacity loss"
As retransmission is also complementary to RS encoding, the RS overhead can now be selected solely
to optimize the coding gain. Thus, RS encoding becomes a benefit rather than an overhead.
I have asked mlmclaren to post in this read with his reasons...
Yes, of course I did, jid. I am only making an observation!
Maybe from now on, I'll read everything up myself and not rely on others...
I am not saying anyone is perfect, but to say that I've had such a wide range of advice from people with one person saying G.INP will be applied, one person says interleaving will be applied and another says nothing will be applied to the line, then what am I supposed to think, hey?
Ok, thanks mlmclaren. At least someone on here cares and actually is willing to help, not forgetting digitalnemesis.
Ok, thanks mlmclaren. At least someone on here cares and actually is willing to help, not forgetting digitalnemesis.
Get an engineer booked mate.
Not if you go through the right channels, however if noise is present then there should be no argument involved.
If it's offshore support he'll get fobbed off with "sir your line is within speed estimates". :lol:
People are arguing on the BT Care Community Forums that because my phone is cordless they think it's just the noise with the phone but I don't want it to get the point where the noise gets worse and I then phone up, I am awaiting a text from Glenn to see what he thinks.
I've been following along (silently) and I must stand alongside you on this one. I've seen the admins and moderators make substantial allowances for William's ASC. I know quite a lot about this condition and the difficulty that people with it can face, and by giving them the leeway you have would mean the world to many of my friends in the same situation.
It seems unfair to talk about William when he isnt around to speak for himself, but in view of the fact that he is quite open about his illness and even had it in his signature that he has Asperger's Syndrome. I only mention it now for the sake of correctness.
It is for that reason, we gave him some additional lea-way and why we tried so hard to help. But there comes a point where it becomes unfair to others when behaviour gets unacceptable.
Anyhow that isnt the reason I re-opened the thread, its because I had something further to add re the G.INP discussion. Ive just not got around to making that post yet.
PS.. Its not new news, just a discussion on the general technology behind Error Correction.
There is one thing now that I am uncertain about and that is what DLM will do next.
In theory it should apply g.inp, but because its on open profile.. Im not sure. :(
His upstream noise margin is all over the place. Is that right for FTTC?
When I was downloading stuff before my SNR would drop by around .5dB... that was before my line ended up impacted by issues, I'll download something from Steam and see how mine copes, then propbably repeat by doing an upload...
@Kitz I am quite happy to watch my DS SNRm drop each evening by 1dB it's been doing this since day one when I starting to monitoring my line stats it is a bit annoying but that is part of this lines characteristic.
I always assumed slight SNR fluctuations were to be expected - since the sun's electromagnetic interference impacts all our lines, unless someone has a completely underground line from PCP to house.
It only appears to be present during the hours of daylight. What could be the cause? At present I don't know. :-\
I know this. Same engineer also tried to tell me that CRCs didn't matter and that it was FEC's that were important. Because my line didnt have any FEC's then it was perfectly fine. Think about it for a moment. The line at that particular time wasn't interleaved, of course it wouldnt have any FEC.
I should add this was not a Openreach Engineer gone through the ranks, but one of those BT took on at the time when they needed staff quickly and were recruiting ex military. He was ex-navy and then proceeded to argue the case about FEC with me.
Seriously he chose the wrong person to try that one on, but can you imagine if that had been anyone else... such as William... or joe bloggs.
The reality seems that Openreach don't want us to see or understand DSL.... maybe it will the next big Watchdog investigation where somebody goes in undercover and catches them dishing out the lessons on talking .....
This can be said for every large operator, though. All of them want to simply present a black box you plug into and the Interwebs come out. For 99% of the population this works just fine, too. The big boys have to cater to the lowest common denominator :)
I have small HR issue on my line but it's not service effecting and no way am I going to get 5 or 6 engineers out to trace a possible small fault which they won't find, and HR faults need to really bad and service effecting before an OR Engineer can find the fault.
It also concerns me that some BT boffins are aware of how easy it is to get hooked on line stats and that some will go into acute state of worry for what is normal parameters. Ringing any bells? Is it any wonder why certain ISPs lock their routers so that such info unnecessarily panics their users
For the majority of lines, we have noticed a small (1-2Mbit/s) increase in line speeds, as a result of retransmission enabling the DLM to increase the headline rates. … Note that in some instances the available memory in the modem can limit the maximum headline rate, by a few Mbit/s, however this is quite rare
Generally has positive impact on experience and headline rates
– 6 fold improvement in error performance
– Majority lines seen small increase in speed 1-2Mbps
and that leads me to my next question which is "what specifies a clean line to an impacted line?" is my line now classed as impacted? or does the system of "an engineer tested line is clean and self install is impacted?"
When customers order Self Install they should understand that there is a higher risk of the line being impacted with wiring issues and End Users getting lower line and throughput rates. We recommend that CPs use Range B Broadband Availability Checker (BBAC) values when providing estimated speeds to their customers.
BTW's FTTC Handbook says this:QuoteWhen customers order Self Install they should understand that there is a higher risk of the line being impacted with wiring issues and End Users getting lower line and throughput rates. We recommend that CPs use Range B Broadband Availability Checker (BBAC) values when providing estimated speeds to their customers.
Customers might not be informed about the reason why range B is being used, but the estimates provided by the ISP at point of sale (they all do this, right) should indeed come from range B.
I was always of the opinion that under 1dB was a good line, and that up to 3dB could be expected. From this, I thought the reasoning for a 6dB target was to allow the swing to go no lower than 3dB ... because the 3dB margin was where the errors really started to bite.
On the technology of "impulse noise protection":
My weakest point on understanding the aspects of DSL is indeed "coding gain" - especially when you include the hidden parts, such as trellis coding, and then start combining them as inner/outer pairs.
I noted @ejs made a comment about whether a G.INP-enabled modem could make predictions about the improvements in coding gain, and attempt to make an allowance for extra speed. That is an interesting avenue to explore, alongside the relative efficiency of different methods.
I think what the Broadcom whitepaper is saying, is that if you switch on interleaving to fix errors, and then what interleaving does is also add coding gain,
abcd efgh ijkl mnop
aeim bfjn cgko dhlp
abcde fghij klmno pqrst uvwxy
afkpu bglqv chmrw dinsx ejoty
I know my ADSL2 line works better with interleaving on, and I get a little more downstream bandwidth,
rather than using interleaving to optimise the line towards more bandwidth rather than lower latency, interleaving only gets used to try to correct errors, but it's not really powerful enough at that.
abcd e--- ijkl mnop
aeim b--- cgko dhlp
a-cd e-gh i-kl m-op
I tend to think that we are seeing the "allowance for extra speed" come out in a different way; and that BT are recognising this added efficiency through this different way: By allowing the target margin to drop below 6dB. By allowing the target margin to drop below 6dB, they are inviting more (raw) bit errors into the stream, under the belief that the new system can cope with, and fix, more errors.
@ejsI'm sorry but I don't think that's correct. If you adjusted the Bit Error Rate, you would get a lower speed, with Interleaving+FEC or without. It's talking about the BER because it's saying interleaving+FEC can't achieve a BER suitable for IPTV, not without increasing the target SNRM which would reduce the bandwidth further. And then it talks about how PhyR can achieve a much better BER at a 0dB margin than the interleaver+FEC can at 3dB.
I think when it says doubled booked its talking about the overheads required for FEC... and also when using INP that can further reduce the line rate.
INP is about applying sufficient protection against noise to ensure that 'x' DMT symbols can be recovered in the event of noise burst.
AIUI when it starts going on about the BER, I think its trying to say, that when you adjust the Bit Error Rate to increase error protection, then this 'takes away' SNRm. I think coding gain is what makes the differential between the true SNR and the SNR margin.
ie this is what makes the SNRm increase/decrease at each stage of INP.I think considering increasing INP levels as "taking away from the actual SNRM" is an unhelpful way of looking at it. There may have been a "sync speed" (net data rate) reduction comparable to changing the target SNRM, but I think the entire net data rate reduction comes from the amount of bandwidth used to carry the FEC data. Providing higher INP levels would require a greater portion of the line's bandwidth to be allocated for carrying the FEC data. Perhaps it would be useful to calculate the "gross" line rate, adding the bandwidth used for FEC data to the net data rate, to see if that shows that the total bandwidth is all still there.
eg.
INP = 3 may take an additional 3bB of SNRm from the actual SNR value
INP = 4 may take an additional 6dB of SNRm from the actual SNR value
[I made up those SNRm figures - they could vary depending on various factors such as line rate and Im not about to start playing with complicated formulae]
So when its saying 'double booked' I'm assuming they mean FEC overheads and any adjustments to the BER which will adjust the SNRm further. I could be wrong, that's the way I read it.The Broadcom whitepaper usually said over-booked rather than double-booked. It was happy enough to book the RS coding gain for use with PhyR.
That was me being lazy and saying interleaving to mean "interleaving+FEC" or even "FEC (Interleaving + RS Coding)".QuoteI think what the Broadcom whitepaper is saying, is that if you switch on interleaving to fix errors, and then what interleaving does is also add coding gain,
Ditto. Thinking of "switching on interleaving" as in setting the DLM to have interleaving+FEC as "opt in".QuoteI know my ADSL2 line works better with interleaving on, and I get a little more downstream bandwidth,
Yes, and again, interleaving to mean interleaving+FEC.Quoterather than using interleaving to optimise the line towards more bandwidth rather than lower latency, interleaving only gets used to try to correct errors, but it's not really powerful enough at that.
DSL technologies, including ADSL1/2/2+ and VDSL2, define a Forward Error Correction (FEC) scheme
based on a combination of RS coding and convolutional interleaving to provide extra coding gain in first
instance and, by extension, protection against impulsive noise (SHINE or REIN).
But the DSL theory is that FEC will always reduce line rate because of overheads.That doesn't take into account the effect of this coding gain. If the benefit of the coding gain is greater than the overheads, the net data rate can be higher.
As retransmission is also complementary to RS encoding, the RS overhead can now be selected solely
to optimize the coding gain. Thus, RS encoding becomes a benefit rather than an overhead.
Coding Gain
The advantage of using Reed-Solomon codes is that the probability of an error remaining in the decoded data is (usually) much lower than the probability of an error if Reed-Solomon is not used. This is often described as coding gain.
Example: A digital communication system is designed to operate at a Bit Error Ratio (BER) of 10-9, i.e. no more than 1 in 109 bits are received in error. This can be achieved by boosting the power of the transmitter or by adding Reed-Solomon (or another type of Forward Error Correction). Reed-Solomon allows the system to achieve this target BER with a lower transmitter output power. The power "saving" given by Reed-Solomon (in decibels) is the coding gain.
With the typical error patterns observed in DSL modems, a BER of 10–7 at 30 Mbps translates into one error every 13 seconds!It may have something to do with those "typical error patterns observed in DSL modems" rather than a simplistic one bit error every 107 = 10,000,000 bits.