The only time you can get anywhere near the max attainable speed is when the connection is on fastpath, even then you will usually get within a couple of Mbps

When I had fibre (only 4 weeks to go 'til I'm on fibre again) my line's max attainable was around 74Mpbs but only synced at around 72Mbps. When interleaving kicked in the max attainable usually went up to about 84Mbps and sync dropped to around 66Mbps.

Can you message me your username so I can check over your account?

Aye
I moved off a new housing estate where the cab was 400m from my house - underground lines, and was syncing at 80/20 with an attainable rate around 100mb...


Just disappointing to know ill never get faster on FTTC lol

I can't see it making any difference tbh.

yeah thats expected as the FEC correction is probably turned on.

It does seem interleaving is common on FTTC DLM which worries me as I want fast path.

Personally I would prefer 9db fast path to 6db interleaving.

I don't think the OR DLM works by varying the noise margin directly. It uses speed banding instead so far as I can tell.

In reply to a post by RobertoS:

I don't think the OR DLM works by varying the noise margin directly. It uses speed banding instead so far as I can tell.

Yes, it alters the max/min sync speed instead of the noise margin. All I've seen OR's DLM alter is the max/min sync speed, the INP, the delay and the interleaving depth.

Interestingly, on the topic of DLM, I think I may have confused mine during the capping experiments I did a while back. I won't post what happened yet though as I have no proof to back it up yet, but if interested in the story and how I think I may have done this then feel free to PM me .

In reply to a post by eddie1150:

Aye
I moved off a new housing estate where the cab was 400m from my house - underground lines, and was syncing at 80/20 with an attainable rate around 100mb...


Just disappointing to know ill never get faster on FTTC lol

I'm 450 meters, underground lines and synced at 42 with attainable of 55, interleaving depth is 700

A while back there was some unexplained noise on my line that lasted a couple of days but it was enough to stick the interleaving up to 2106 and that's where it stayed for about 2 weeks then it dropped back to fastpath over 3 or 4 days.

This is very technical, but at the end there is an answer as to whether you are getting a lot of errors. Pay attention to the conclusion, even if you don't understand the technology/maths.

In reply to a post by RobertoS:

Interleaving is this line:- "D: 861 1".

I think D definitely shows something related to the interleaving depth - certainly whether or not interleaving has been turned on.

From TR-176 (ADSL Configuration), I believe DLM sets the "amount" of interleaving by setting these values:

INP: 3.00 0.00
delay: 8.00 0.00

INP indicates how many "symbols" need to be protected from a noise impulse, and the delay (in milliseconds) sets how far spread out (in time) the original packets can be (random noise and repetitive REIN respond to different relative setups)

The modems work out the best way to set up interleaving based on the settings defined by DLM - one output figure is the D parameter above.

Another pair of useful parameters are the size of the small data blocks protected by FEC (aka Forward Error Correction), and the size of the parity data that does the protection. This information is held in these parameters:

B: 63 237
I: 80 127
N: 80 254

For downstream, my understanding is that B gives the amount of user data within an RS block (an RS block is the lump that is protected by FEC, and spread out by interleaving), and N gives the total size of the block. That means (N-B) is the parity (protection) data, which is an overhead.

Here, an RS block is 80 bytes long, carry 63 bytes of user data, and 17 bytes of overhead parity data.

The line is carrying 63/80 user data, or 79%, The parity overhead is 17/80, or 21%.

So... if the line's attainable rate is 64Mbps, you can see it really can only carry 79% of that as user data - or about 51Mbps. The rest of the "attainable rate" *is* still being used to carry useful information - but it is used as part of the FEC process, rather than directly for end-user-data.

So, onto the FEC process...

OHF: 43359321 1467639
OHFErr: 183 60

RSCorr: 1510434 1617
RSUnCorr: 4669 0

Total time = 21 hours 46 min 13 sec
FEC: 1511112 1617
CRC: 183 60
ES: 52 57
SES: 0 0
UAS: 18 18
LOS: 0 0
LOF: 0 0

This shows that the modem detected 1.5 million errors in the downstream data (ie in the RS blocks), caused by noise interference.

However, the FEC process used the overhead (N-B) parity data to automatically correct the errors in the B user-data... so these don't count as actual errors. They've been fixed, so there is no need for anywhere out on the internet to re-transmit the data to you.

Roughly then, RSCorr and FEC correspond with these "fixed RS blocks". They show, very firmly that interleaving is needed, and is saving a lot of re-transmission of data.

But there were occasions where the errors were bad enough that the FEC process couldn't fix the RS block. An error in an RS block causes a corresponding error in the higher "superframe" level, which is detected using the simpler CRC mechanism. Here the errors are detected but cannot be fixed - and the data has to be thrown away. As a superframe contains many RS blocks, there has to be at least 1 RS block faulty, but there can be many.

RSUncorr shows how many RS blocks were so bad that they couldn't be fixed.
OHFErr shows how many superframes had errors
CRC should count the same thing, though the HEC counter plays a part too (I know how it works with ATM in ADSL, but not in our FTTC).

In this case, there were only 183 errors that were bad enough to affect data transmission. These 183 faulty superframes must have contained the 4669 uncorrectable RS blocks.

Finally, the ES and SES parameters give an idea of where all those CRC errors happen. Each ES (errored second) is a second-long period where one or more errors occurred. In this case, it means those 183 errors occurred in 52 different second-long periods.

A SES value shows a second-long period that had a "severe" level of errors (I don't know the threshold though). Anything here would show there were periods with very bad noise interference.. There were none here

Is that a lot of errors?

It is a high level of FEC-corrected errors, indicating that interleaving, at some level, is needed.

It is a low level of CRC errors, indicating that interleaving is set high enough.

The CRC level is probably within limits (ie not too high or too low), so DLM won't adjust your profile up or down. If the CRC rate changes, DLM could respond in either direction.

I can't comment on what DLM is looking for on FTTC. I have seen something for ADSL2+ that suggests an error rate of >1 fault per minute will cause DLM to intervene, while an error rate of less than 1 fault every 10 minutes will cause DLM to backtrack.

183 errors over 1300 minutes is 1 error every 7 minutes - which would be on-target for ADSL2+. Perhaps FTTC has a similar target...