|
|
OK so having been on 80/20 and getting full speeds at my old house, ive moved property and ended up getting a 2nd OR modem, the new one been ECI, the original been one of the first huwaei ones.
Ive unlocked my huwaei (i did wait 10 days)
and its syncing as per the image :
http://img826.imageshack.us/img826/510/broadbandspee...
Now my questions:
It says attainable speed 64300, so how come im synching at 54369??
My 2nd question, which modem am i best off with? The ECI one or the huwaei one?
Obviously i cant check the ECI sync speed so how would i know?
Edit - Plusnet website says:
Current line speed:
59.4 Mb
So does that mean ive been syncing faster with the ECI modem?
Thanks.
Eddie
|
|
|
Further to that, ive just done a BTW test on my line and it says:
Our test also indicates that your line should be able to have an ADSL2+ broadband service that provides a fixed line speed up to 1Mbps. However due to the length of your line the 1Mbps service may require an engineer visit who will, where possible, supply the broadband service.
Ive never seen that before, what would an enigineer visit achieve?
Im only 0.9miles away from my exchange,
and despite having a cabinet at the end of my 10m long phone line, my actual cabinet is 0.4miles away 
|
|
|
If you get the IP Profile from a BT Speed test, it is apparently 96.79% of the sync. So you want IP Profile x 1.033 for a closeish calculation of the sync.
My broadband basic info/help site - www.robertos.me.uk | Domains,website and mail hosting - Tsohost.
Connection - Plusnet Extra Fibre (FTTC). Sync ~ 53.5/15.2Mbps @ 600m. - BQM
"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allergy information: This post was manufactured in an environment where nuts are present. It may include traces of understatement, litotes and humour.
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
Read the rest of that report! The criteria for a fixed 2Mbps ADSL2+ service are completely different from a variable ADSL2+ connection. That line has always been there.
Are you sure the cab 10m away isn't VM? (Your sentence about it doesn't make sense, unless it is an SCP not a PCP).
My broadband basic info/help site - www.robertos.me.uk | Domains,website and mail hosting - Tsohost.
Connection - Plusnet Extra Fibre (FTTC). Sync ~ 53.5/15.2Mbps @ 600m. - BQM
"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allergy information: This post was manufactured in an environment where nuts are present. It may include traces of understatement, litotes and humour.
|
|
|
Note the word MAY. A common phrase for a line that is expected to only get 1 Meg from a fixed speed service, been there for years
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
|
Yeah did read the rest, just never seen that line before... never had such al ong line though!
No its definitely BT.
And im 99% sure its a fibre cab.
My line goes from my house, to a pole, which has a cabinet next to it.
according to the engineer, its just a carrier pole, and the line proceeds .4 miles down the road to another cab - how silly is that!!
Is anyone able to confirm and tell me what cab im connected to?
With regards to IP profiles
it says 52.63 Mbps on BT checker - so why does plusnet say 59? and why am i syched at more?
Also upload says - ip profile is 20mb. im getting 12?
|
|
|
The line is connected to a cabinet that is with a couple of hundred metres, if it was a fibre cab 4 miles away you would have no sync at all
http://www.coolwebhome.co.uk/fibre/checker.php
If its a failure old FTTC phase that site may give you the cabinet number
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
Pics of cabinets.
FTTC cabinets are normally within 50 cable metres of their PCP. I believe the maximum is approximately 80 metres.
The Plusnet "Line speed" tends to be dodgy on FTTC. Turning the router off for a few minutes might correct it. You are limited to the lower of the two figures.
I've just checked mine - PN says 50.8, BT says 51.8. I shall have a go at router restart tomorrow, and if that fails I may do a modem restart, but I don't want to do that unless I have a very favourable noise margin in both directions.
Sync should always be more than IP Profile - yours is.
Attainable on FTTC is a meaningless number in my view. Perhaps what it might reach in an ideal noise-free world. Mine goes all over the place.
If you look at the stats in a command line window, using xdslcmd info --pbParams you will see how the figures break down into the different frequency bands. My upstream sync is currently above the attainable  . Attainables vary 24/7 even with your sync stable.
My broadband basic info/help site - www.robertos.me.uk | Domains,website and mail hosting - Tsohost.
Connection - Plusnet Extra Fibre (FTTC). Sync ~ 53.5/15.2Mbps @ 600m. - BQM
"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allergy information: This post was manufactured in an environment where nuts are present. It may include traces of understatement, litotes and humour.
|
|
|
It says attainable speed 64300, so how come im synching at 54369??
I think you are likely to be interleaved, and the interleaving is stealing the missing 10Mbps.
If you had unlocked the modem on (or before) the 1st day, you'd have probably seen a sync speed closer to the full speed - as well as more errors - before DLM intervened.
If you want to see the detailed data, telnet into the modem, and post back the information from the "xdslcmd info --show" or "xdslcmd info --stats".
|
|
|
Also if your cabinet is ECI I've found, as some others have, that using the ECI modem performs better in regards to reducing or turning off interleaving compared to using a non-ECI modem (e.g. Huawei, Fritz!Box). Apparently some incompatibility causes small and regular errors to appear on the line which eventually can result in DLM increasing interleaving depth, delay and INP.
References:
- http://beusergroup.co.uk/technotes/index.php?title=D...
- http://talktalkmembers.net/forums/showthread.php?t=8...
|
|
|
|
Thanks.
How do i find out if its ECI?
|
|
|
|
Will look tonight when i get home.
thankyou
|
|
|
Telnet onto your HG612 and do "xdslcmd info --pbParams" without the quotes...
Example:
| Text | 1
23
45
67
89
1011
1213
| # xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY statusStatus: Showtime
Retrain Reason: 0Max: Upstream rate = 29167 Kbps, Downstream rate = 91884 Kbps
Path: 0, Upstream rate = 20000 Kbps, Downstream rate = 59999 Kbps
Discovery Phase (Initial) Band PlanUS: (0,95) (880,1195) (1984,2771)
DS: (32,859) (1216,1959) (2792,4083)Medley Phase (Final) Band Plan
US: (0,95) (880,1195) (1984,2771)DS: (32,859) (1216,1959) (2792,4083) |
Look at the discovery phase for the DS, most importantly the final tone being 4083, "DS: (32,859) (1216,1959) (2792,4083)". If it's not 4083 then it's not ECI, I think Huawei is 3959 or close to that, I can't recall the exact number though I might be right on guessing 3959.
|
|
|
You forgot to say that after opening the Telnet session the first command is "sh" followed by the command string you gave.
Yes 3959 on the Huawei
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
|
Yeah, sorry I'm distracted. Also the login is admin for both username and password, even if you've changed it on the web interface.
|
|
|
I think Huawei is 3959 or close to that, I can't recall the exact number though I might be right on guessing 3959 As in:-
ATP>sh
BusyBox v1.9.1 (2010-10-15 17:59:06 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 14908 Kbps, Downstream rate = 62804 Kbps
Path: 0, Upstream rate = 15217 Kbps, Downstream rate = 53516 Kbps
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 14908 kbps 62804 kbps
Actual Aggregate Tx Power: 6.6 dBm 13.8 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 5.3 29.3 43.9 N/A 14.3 35.9 54.9
Signal Attenuation(dB): 5.3 28.4 42.6 N/A 14.3 35.9 54.9
SNR Margin(dB): 6.1 5.8 5.8 N/A 6.3 6.2 6.4
TX Power(dBm): -3.7 -13.3 6.3 N/A 11.2 7.9 5.6Edit - reformatted the quote.
My broadband basic info/help site - www.robertos.me.uk | Domains,website and mail hosting - Tsohost.
Connection - Plusnet Extra Fibre (FTTC). Sync ~ 53.5/15.2Mbps @ 600m. - BQM
"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allergy information: This post was manufactured in an environment where nuts are present. It may include traces of understatement, litotes and humour.
Edited by RobertoS (Wed 21-Nov-12 14:32:31)
|
|
|
|
Thanks for info guys.
will try tonight.
|
|
|
Attainable Net Data Rate: 14908 kbps 62804 kbps
Actual Aggregate Tx Power: 6.6 dBm 13.8 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 5.3 29.3 43.9 N/A 14.3 35.9 54.9
Signal Attenuation(dB): 5.3 28.4 42.6 N/A 14.3 35.9 54.9
SNR Margin(dB): 6.1 5.8 5.8 N/A 6.3 6.2 6.4
TX Power(dBm): -3.7 -13.3 6.3 N/A 11.2 7.9 5.6
Your Attainable Upstream is a little low. My Downstream is similar to yours but Upstream is way higher.
Attainable Net Data Rate: 23846 kbps 63152 kbps
Actual Aggregate Tx Power: 5.7 dBm 13.8 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 4.2 21.3 31.4 N/A 11.2 26.3 40.4
Signal Attenuation(dB): 4.2 20.9 30.5 N/A 11.2 26.3 40.4
SNR Margin(dB): 29.8 29.6 29.7 N/A 12.8 13.1 13.1
TX Power(dBm): -4.5 -27.1 5.2 N/A 11.1 8.2 6.4
I have plenty of spare margin on mine too. Just a pity that downstream is only 63Mbps
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
Like I said, it floats around. A while ago it went up to over 16,000 for a while, a lot earlier it went down into the 13,900s. I suspect LLU ADSL2+ crosstalk on my pole.
Not also my current sync is above it  .
Downstream has been hit by the recent interleaving. I was on Fast Path for 18 months or so. Waiting to see what happens, but the newly arrived regular latency spikes (that some others also see) on my BQM aren't encouraging.
My broadband basic info/help site - www.robertos.me.uk | Domains,website and mail hosting - Tsohost.
Connection - Plusnet Extra Fibre (FTTC). Sync ~ 53.5/15.2Mbps @ 600m. - BQM
"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allergy information: This post was manufactured in an environment where nuts are present. It may include traces of understatement, litotes and humour.
|
|
|
|
Hi eddie1150,
Let me know how you get on, if there's no improvement then send me your username so I can check your account for you.
|
|
|
Cheers Chris
Do you have the option to turn interleaving off?
Or even better, get my line moved to the cabinet next to my house  ha
|
|
|
I have plenty of spare margin on mine too. Just a pity that downstream is only 63Mbps
Judging by attenuation, your line is way better (or shorter, at least). In fact, those attenuation figures are almost identical to ours - where we have an 80/20 line (though today is the first time ever that the "attainable" has dropped below 81Mbps):
| Text | 1
23
45
67
89
1011
1213
1415
1617
1819
| Max: Upstream rate = 25950 Kbps, Downstream rate = 79644 Kbps
Path: 0, Upstream rate = 20000 Kbps, Downstream rate = 79999 Kbps
Discovery Phase (Initial) Band PlanUS: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)DS: (32,859) (1216,1963) (2792,3959)
VDSL Port Details Upstream DownstreamAttainable Net Data Rate: 25950 kbps 79644 kbps
Actual Aggregate Tx Power: 6.8 dBm 13.1 dBm============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3 Line Attenuation(dB): 4.3 21.8 32.6 N/A 11.4 27.5 41.9
Signal Attenuation(dB): 4.3 20.8 31.6 N/A 11.4 27.5 41.9 SNR Margin(dB): 15.3 15.2 15.2 N/A 5.8 5.8 5.8
TX Power(dBm): -4.2 -21.5 6.4 N/A 9.7 7.8 6.9# |
Given that the normal case is for the SNR Margin to be 6dB, as Bob's is, yours is looking very high, given that you aren't bouncing off the speed ceiling.
Perhaps you've been banded? Or perhaps Openreach have started setting profiles with higher target SNRM values?
If it were the latter, it'd be the first time I've seen it on FTTC. Do you have anything that has been monitoring the 3 SNRM values over the course of a day, or longer?
|
|
|
I should get the tools installed to monitor it and see how it performs over the day. At present I cannot as I am using two PCs which I have agreed not to install anything on - my PCs have a McAfee AV problem which I am waiting for them to resolve and as such those are not going on line at all.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
Do you have the option to turn interleaving off?
No - ISP's don't have that facility.
It only seems to be possible to get a line set back to the "initial" state (without interleaving), and that happens only when requested by an Openreach engineer visiting to fix a fault - and it doesn't always happen then - sometimes they forget, and sometimes their central department refuse to do the reset.
The line will then act like a new install - so if there have been no changes to the quality of the line, DLM is almost certainly going to intervene again within the first 48 hours.
|
|
|
|
As WWWombat says, we do not have the facility to be able to turn on/off interleaving, this will be done automatically. Only an engineer can reset the line when needed.
Let me know how you go.
|
|
|
Right.
Ive done as suggested
# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 12153 Kbps, Downstream rate = 63900 Kbps
Path: 0, Upstream rate = 12436 Kbps, Downstream rate = 54369 Kbps
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 12153 kbps 63900 kbps
Actual Aggregate Tx Power: 6.4 dBm 12.6 dBm
# xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 12168 Kbps, Downstream rate = 63700 Kbps
Path: 0, Upstream rate = 12436 Kbps, Downstream rate = 54369 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.1 5.9
Attn(dB): 0.0 0.0
Pwr(dBm): 12.6 6.4
VDSL2 framing
Path 0
B: 63 237
M: 1 1
T: 64 50
R: 16 16
S: 0.0375 0.6084
L: 17086 3340
D: 861 1
I: 80 127
N: 80 254
Counters
Path 0
OHF: 43359321 1467639
OHFErr: 183 60
RS: 4030021992 3414415
RSCorr: 1510434 1617
RSUnCorr: 4669 0
Path 0
HEC: 1098 0
OCD: 0 0
LCD: 0 0
Total Cells: 3883154311 0
Data Cells: 7639112 0
Drop Cells: 0
Bit Errors: 0 0
ES: 52 57
SES: 0 0
UAS: 18 18
AS: 78265
Path 0
INP: 3.00 0.00
PER: 1.79 7.60
delay: 8.00 0.00
OR: 93.43 33.66
Bitswap: 26847 3000
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
Latest 15 minutes time = 1 min 13 sec
FEC: 409 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 23370 2
CRC: 2 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day 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
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Since Link time = 21 hours 45 min 55 sec
FEC: 1511112 1617
CRC: 183 60
ES: 52 57
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Im guessing:
Trellis: U:ON /D:ON = interleaving?
and the amount of errors means i have interleaving on?
Is that a lot of errors?
|
|
|
Trellis - I'm not sure what that does, but it's always on on any broadband stats I've seen, including ADSL/ADSL2/ADSL2+.
Interleaving is this line:- "D: 861 1". "1" is Fast Path, anything else is interleaving depth. So you are interleaved down, fast path up. Hard to interpret the 861. On ADSLx that number is the number of ATM cells a TCP/IP packet is split across. On VDSL2 we have superframes and I run out of tech knowledge.
Error figures on the HG612 seem to be very odd for everyone.
My broadband basic info/help site - www.robertos.me.uk | Domains,website and mail hosting - Tsohost.
Connection - Plusnet Extra Fibre (FTTC). Sync ~ 53.5/15.2Mbps @ 600m. - BQM
"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allergy information: This post was manufactured in an environment where nuts are present. It may include traces of understatement, litotes and humour.
|
|
|
|
|
|
|
Brilliant
so how can i improve it?
Its showing my attainable speed as something i should be able to get to.
|
|
|
Its showing my attainable speed as something i should be able to get to. Unfortunately, it isn't.
My broadband basic info/help site - www.robertos.me.uk | Domains,website and mail hosting - Tsohost.
Connection - Plusnet Extra Fibre (FTTC). Sync ~ 53.5/15.2Mbps @ 600m. - BQM
"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allergy information: This post was manufactured in an environment where nuts are present. It may include traces of understatement, litotes and humour.
|
|
|
|
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.
My broadband basic info/help site - www.robertos.me.uk | Domains,website and mail hosting - Tsohost.
Connection - Plusnet Extra Fibre (FTTC). Sync ~ 53.5/15.2Mbps @ 600m. - BQM
"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allergy information: This post was manufactured in an environment where nuts are present. It may include traces of understatement, litotes and humour.
|
|
|
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 .
|
|
|
|
|
|
|
|
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.
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...
|
|
|
so how can i improve it?
Just like ADSL - with correct filters, decently made joints, no ring wire etc. Take care with routing telecom cables near mains cables. Beg the neighbour to stop transmitting their radio-ham or CB sets.
Your only way to measure the effect you are having is to watch the FEC and CRC error rates.
If you reduce your CRC rate, then DLM will notice (it might take 2, 3 or 4 weeks to change though).
|
|
|
... Wow, that's some post.
I wonder if Bald_Eagle1 can incorporate this into his HG612 stats
|
|
|
perhaps you could add it to your blog, before it gets lost amongst all the other posts, although I have saved a link to it.
|
|
|
Wow, that's some post.
I wonder if Bald_Eagle1 can incorporate this into his HG612 stats
How do you mean?
|
|
|
I think he's taking the mickey out of the poster.
I'm hoping it wasn't really supposed to be a reply to me, just a lazy last-post reply.
I've also been out and not had time to look for some stuff that shows how wrong he is about error stats on FTTC, which could well be what BatBoy is on about. I can't be bothered tonight.
My broadband basic info/help site - www.robertos.me.uk | Domains,website and mail hosting - Tsohost.
Connection - Plusnet Extra Fibre (FTTC). Sync ~ 53.5/15.2Mbps @ 600m. - BQM
"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allergy information: This post was manufactured in an environment where nuts are present. It may include traces of understatement, litotes and humour.
|
|
|
|
Thanks guys.
Not much i can do then!
THe line from the drop wire to the bt box was changed when BT came, so guess there isnt much that can be done, unless his joint wasnt up to much?
But not really mcuh way i can change that eh!?
|
|
|
Wow, that's some post.
I wonder if Bald_Eagle1 can incorporate this into his HG612 stats
How do you mean?
I mean can the graphs show whats stated in the post in order to aid troubleshooting?
|
|
|
I mean can the graphs show whats stated in the post in order to aid troubleshooting?
In a new version that I am still working on, I don't graph any ongoing data from the GUI any longer as the errors are reported incorrectly.
Instead, I just graph data from xdslcmd info --stats
The harvesting is also now done via a compiled .EXE program that is more efficient, reliable & quicker.
Quite a bit of what WWWombat has mentioned is graphed, particularly OHFErr (CRC), RSCorr (FEC), HEC error counts along with Error Seconds, attenuation per band, power levels etc............
Here's an example from my own connection:-
Ongoing Stats from 25th November
You will see that some graphs are duplicated. That's just to demonstrate that certain error types have two names. e.g RSCorr & FEC errors are the same thing & increase at the same rate.
One of them retains cumulative values following a resync & the other doesn't.
That doesn't really matter for graphing though, as the graphs just show the difference from one minute to the next.
I hope to release this new version some time after Christmas (once I have sussed out how to easily implement the use of a configuraion/ini file for easy setting up of bespoke folder/drive locations & so on).
I might also add a few more graphs for some of the other stats too - when I get round to it.
EDIT:
I believe ADSL connections use the term SuperFrame (reported as SF via Broadcom routers such as Netgear DG834GT & the HG612 itself when used in ADSL mode) whereas VDSL2 uses the term OverHeadFrame (OHF)
Edited by deleted (Sun 25-Nov-12 21:53:38)
|
|
|
I finally found a copy of the VDSL2 specification, so I understand the parameters better now - and also realised I made a small mistake, so don't graph it directly
However, I think there *might* be something worth graphing that is a little better than the "D" (interleaving depth) parameter.
|
|
|
EDIT:
I believe ADSL connections use the term SuperFrame (reported as SF via Broadcom routers such as Netgear DG834GT & the HG612 itself when used in ADSL mode) whereas VDSL2 uses the term OverHeadFrame (OHF)
Yes, I think this is correct.
In the VDSL2 spec, the data transferred is split into two components - the user-data and the OH (OverHead data). The CRC code is captured and sent as part of the OH data... and as far as I can work out, there is one CRC per OH frame.
In ADSL, there is one CRC code per SF.
I think the two frames are constructed in rather different ways, but the fact seems to be that one "error" count in ADSL implies the CRC went wrong for one superframe. In VDSL2, the one error would mean a CRC mismatch in one OH frame.
|
|
|
I think he's taking the mickey out of the poster.
I'm hoping it wasn't really supposed to be a reply to me, just a lazy last-post reply.
Am I the poster you talk about there?
The content of my reply really went to cover a lot of people's posts on here, so it wasn't *directly* a reply to you. However, your post talked about specific parameters and some difficulties, so I definitely chose it as the best individual post to use the "reply" button on. Unfortunately, there is no ability to post a generic reply to many posts...
I've also been out and not had time to look for some stuff that shows how wrong he is about error stats on FTTC, which could well be what BatBoy is on about. I can't be bothered tonight.
If that is something on the Error Stats in my post, them I'm all ears. I'm feeling my way at understanding how they work in VDSL2, comparing it against how I know other protocols work, and guessing where need be.
|
|
|
Re error stats, my most definitive post would be if I could find a set of my xdslcmd stats from when I unlocked my modem and before I got put on interleaved. I'm almost certain FECs are shown. If I'm right, it isn't just the HG612 GUI that is dodgy.
I'm just not in the mood to find them, I'm afraid. A lot on my mind.
My broadband basic info/help site - www.robertos.me.uk | Domains,website and mail hosting - Tsohost.
Connection - Plusnet Extra Fibre (FTTC). Sync ~ 53.5/15.2Mbps @ 600m. - BQM
"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allergy information: This post was manufactured in an environment where nuts are present. It may include traces of understatement, litotes and humour.
Edited by RobertoS (Sun 25-Nov-12 22:34:25)
|
|
|
This is the part that is wrong:
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.
It is better written as:
Another couple of useful parameters give the size of the data blocks protected by "Forward Error Correction" (aka FEC), and the size of the parity data that gets added for the protection. This information is held in these parameters:
R: 16 16
N: 80 254
For downstream, my understanding is that there is a missing parameter K that 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. Parameter R specifies how much of the RS block is dedicated to the parity (protection) data, which is an overhead. Therefore N=K+R.
These additional "parity" bytes, through a miracle of maths, allows the modem to fix a small number of errors in the user data - thereby saving the transmitter from having to re-transmit. The downside is that the parity data represents a permanent overhead.
Here, an RS block is 80 bytes long, carry 64 bytes of user data, and 16 bytes of overhead parity data.
The line is carrying 64/80 user data, or 80%, The parity overhead is 16/80, or 20%.
So... if the line's attainable rate is 64Mbps, you can see it really can only carry 80% 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.
Two further parameters specify the way that interleaving works:
D: 861 1
I: 80 127
"I" defines the size of blocks that get interleaved, while "D" specifies how far apart the output bytes will be. In this case, byte 0 (first on the input stream) will be transmitted first, byte 1 will be transmitted 861st, while byte 80 (first in the second block) will be transmitted second.
When both interleaving and FEC are combined, the effect is that a burst of noise hits a number of consecutive bytes within the "interleaved" stream. However, when they are de-interleaved, the broken bytes end up within different RS blocks.
Statistically, not many bytes within each RS block get destroyed by the noise, and the problem is sufficiently small that it can be corrected using the parity bytes.
If it turns out that FEC can't correct the errors, DLM might intervene again to turn interleaving up higher - in which case more parity bytes are likely to be needed with fewer user data bytes.
My Conclusion:
Graphing "I" and/or "D" will give an indication of the extra latency being added by interleaving (the delay is actually given by "I" multiplied by "D").
Graphing "R" and "N" (or percentages based on these numbers) will show how much capacity is being "stolen" by the parity overhead of FEC.
|
|
|
FEC's show in some fashion because the line is never truly fastpath even at a depth of 1 with no INP or delay?
I had a small amount of FEC's occasionally on the FB7390 when there was no INP or delay (no interleaving). The same goes for the HG612 (currently present on the upstream). The ECI on the other hand... the statistics for errors don't make any sense so I'm ignoring those.
Here's my HG612 statistics at present time of posting.
| Text | 1
23
45
67
89
1011
1213
1415
1617
1819
2021
2223
2425
2627
2829
3031
3233
3435
3637
3839
4041
4243
4445
4647
4849
5051
5253
5455
5657
5859
6061
6263
6465
6667
6869
7071
7273
7475
7677
7879
8081
8283
8485
8687
8889
9091
9293
9495
9697
9899
100101
102103
| Max: Upstream rate = 28562 Kbps, Downstream rate = 93388 Kbps
Path: 0, Upstream rate = 20000 Kbps, Downstream rate = 59999 Kbps
Link Power State: L0Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17aTPS-TC: PTM Mode
Trellis: U:ON /D:ONLine Status: No Defect
Training Status: Showtime Down Up
SNR (dB): 15.1 12.1Attn(dB): 0.0 0.0
Pwr(dBm): 12.5 6.8 VDSL2 framing
Path 0B: 239 236
M: 1 1T: 64 5
R: 0 16S: 0.1273 0.3771
L: 15081 5410D: 1 1
I: 240 255N: 240 255
Counters Path 0
OHF: 45263048 1416347OHFErr: 674 2
RS: 0 2544210RSCorr: 0 81
RSUnCorr: 0 0
Path 0HEC: 5355 0
OCD: 0 0LCD: 0 0
Total Cells: 2084370172 0Data Cells: 387254187 0
Drop Cells: 0Bit Errors: 0 0
ES: 516 2
SES: 5 0UAS: 190 190
AS: 92561
Path 0INP: 0.00 0.00
PER: 2.03 6.12delay: 0.00 0.00
OR: 90.32 203.67
Bitswap: 1618 3
Total time = 1 days 1 hours 49 min 41 secFEC: 0 0
CRC: 3152 0ES: 516 2
SES: 5 0UAS: 190 190
LOS: 5 0LOF: 5 0
Latest 15 minutes time = 4 min 41 secFEC: 0 0
CRC: 5 0ES: 3 0
SES: 0 0UAS: 0 0
LOS: 0 0LOF: 0 0
Previous 15 minutes time = 15 min 0 secFEC: 0 0
CRC: 3 0ES: 2 0
SES: 0 0UAS: 0 0
LOS: 0 0LOF: 0 0
Latest 1 day time = 1 hours 49 min 41 secFEC: 0 0
CRC: 57 0ES: 43 0
SES: 0 0UAS: 0 0
LOS: 0 0LOF: 0 0
Previous 1 day time = 24 hours 0 secFEC: 0 0
CRC: 3095 0ES: 473 2
SES: 5 0UAS: 190 190
LOS: 5 0LOF: 5 0
Since Link time = 1 days 1 hours 42 min 41 secFEC: 0 81
CRC: 674 2ES: 509 2
SES: 0 0UAS: 0 0
LOS: 0 0LOF: 0 0 |
Edited by Ixel (Mon 26-Nov-12 11:02:00)
|
|
|
|
That's interesting...
The "D" parameter - interleaving depth - is 1, suggesting that there is no interleaving going on.
However, the "R" parameter is 16, suggesting that there are parity bytes being sent, and that the FEC process is working. 16 bytes out of 255 is about 6% of the upstream capacity being used for protection.
Interesting... as, in ADSL days, FEC would only be present when interleaving was turned on. It appears that, in VDSL2, FEC can be present alone.
I suspect that the channel is still fastpath - as it is interleaving that adds delays, not FEC.
That's upstream. Downstream is different...
There, there is no interleaving, and no FEC. It's kinda strange that the actual downstream rate is set to 60Mbps. Ah - except it is *so* close that it probably means DLM has "banded" you into that speed. Strange, then, that it has set a speed band, but not turned FEC on.
|
|
|
|
Yes, that is what I find very odd. But I've tried various things to see if I could upset DLM, e.g. several re-syncs in a short time (short time being less than an hour), but to no avail can I make it do anything worse or better, unless the resync threshold is much greater than that of course. So that's why I wonder if I've somehow frozen DLM (confused the algorithm), wierd I know but I can't assume much else. This goes back to when I was playing around with the FB 7390 and inducing caps of my own, all the way down to 32,000Kbps at one point (for a couple of days), and that was the last cap I did. In the past the cap usually goes within a couple of days, but I've never been as low as 32,000Kbps which is close to the fault rate threshold I believe.
One other idea I had was, given I was (if I'm right) close to the FRT for a couple of days, comparing to my normal sync that DLM must have a history of, perhaps it determined it should disable all interleaving in order to try and prevent me going below the FRT (even though I was controlling the cap, it could've perceived that low speed as a fault).
Hmm, the mysteries of DLM.
|
Pages in this thread: 
Print Thread
deleted
