Kitz Forum
Broadband Related => Broadband Hardware => Topic started by: Ragnarok on December 30, 2015, 02:15:34 PM
-
the Huawei/bcm vs ECI/Lantiq debate has often raged on on this forum.
I am on an ECI cab I'm banded at 67mbps on downstream ( 2 BT engineers refused to reset my line after an flooded underground duct was flushed and cable replaced ), I have both an unlocked both ECI /r ( not Open WRT, just the stock firmware telnet) and Huawei ( with the latest howling wolf firmware) bt openreach modems .
What is definitely true is the ECI modem reports less errors and my line recovers from interleaving if I leave this on there. The ECI also produces about 0.5ms less lag( not really very important). Both Modems sync at virtually the same speeds, and report the same SNR when I switch between them.
Ever since getting BTTV, I've noticed that the ECI modem seems glitch the streams quite a bit. The Huawei is virtually flawless.
could it be that the ECI is actually letting more bad packets through.
I'm toying with the Idea of putting Openwrt on my ECI/r and seeing if the new modem driver used on there is any better, and being able to see an ES count.
My typical line stats from the Huawei look like this, the EH/h is usually anywhere between 20-30 which i think would set my DLM status to amber, with the HG612 there is almost no chance the banding will be lifted.
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 25708 Kbps, Downstream rate = 73028 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 66969 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 7.9 9.5
Attn(dB): 17.1 0.0
Pwr(dBm): 13.6 6.6
VDSL2 framing
Bearer 0
MSGc: 18 150
B: 239 236
M: 1 1
T: 23 5
R: 0 16
S: 0.1141 0.3771
L: 16832 5410
D: 1 1
I: 240 255
N: 240 255
Counters
Bearer 0
OHF: 79366016 944351
OHFErr: 2583 3
RS: 0 803517
RSCorr: 0 6017
RSUnCorr: 0 0
Bearer 0
HEC: 15541 0
OCD: 470 0
LCD: 470 0
Total Cells: 3000254943 0
Data Cells: 1996553851 0
Drop Cells: 0
Bit Errors: 0 0
ES: 1014 3
SES: 3 0
UAS: 26 26
AS: 156779
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 1.97 6.15
OR: 97.19 202.87
AgR: 67066.02 20203.27
Bitswap: 117229/117229 20/20
Total time = 1 days 19 hours 33 min 25 sec
FEC: 0 6017
CRC: 2583 3
ES: 1014 3
SES: 3 0
UAS: 26 26
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 3 min 25 sec
FEC: 0 0
CRC: 4 0
ES: 4 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 13 0
ES: 11 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 19 hours 33 min 25 sec
FEC: 0 5987
CRC: 588 3
ES: 398 3
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 30
CRC: 1995 0
ES: 616 0
SES: 3 0
UAS: 26 26
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 1 days 19 hours 32 min 59 sec
FEC: 0 6017
CRC: 2583 3
ES: 1014 3
SES: 3 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
-
It might be worthwhile considering leaving your current ECI B-FOCuS /r "as is" and just purchase another device, from an eBay vendor, for updating with the OpenWRT firmware image? :-\
-
Aren't there dsl_cpe_pipe commands to get the ES count? pmlsc15mg / pmlsc1dg / pmlscsg / pmlsctg for 15 minutes / 1 day / showtime / total?
-
I don't understand the comment about letting more bad packets through. IP packets are checksummed to prevent corrupt packets from being delivered. Or have I misunderstood?
-
I think Some modem firmware/software algorithms are we bit better than others when catching a fragmented packet and then correct it in time before it becomes an uncorrected error :-\
-
@newtronstar ;D
-
Weaver we're not talking TCP, where talking UDP.
It's moot anyway at the moment. My line just developed a nasty noise on the phone this afternoon and the DSL speeds have plummeted. Gonna have to investigate and get that fixed first.
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 13462 Kbps, Downstream rate = 37224 Kbps
Bearer: 0, Upstream rate = 13918 Kbps, Downstream rate = 39333 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 5.6 6.0
Attn(dB): 25.7 0.0
Pwr(dBm): 13.7 6.9
VDSL2 framing
Bearer 0
MSGc: 18 18
B: 237 238
M: 1 1
T: 64 21
R: 16 16
S: 0.1926 0.5465
L: 10552 3733
D: 1 1
I: 254 255
N: 254 255
Counters
Bearer 0
OHF: 8167381 986116
OHFErr: 683 258
RS: 522691746 217876
RSCorr: 213117 2415
RSUnCorr: 6085 0
Bearer 0
HEC: 5432 0
OCD: 234 0
LCD: 234 0
Total Cells: 1910734134 0
Data Cells: 15676596 0
Drop Cells: 0
Bit Errors: 0 0
ES: 1629 204
SES: 17 0
UAS: 66 52
AS: 25264
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 3.09 8.64
OR: 62.07 22.22
AgR: 39395.34 13940.63
Bitswap: 15501/15546 2515/2618
Total time = 1 days 7 hours 48 min 26 sec
FEC: 213117 8436
CRC: 11117 261
ES: 1629 204
SES: 17 0
UAS: 66 52
LOS: 1 0
LOF: 9 0
LOM: 0 0
Latest 15 minutes time = 3 min 26 sec
FEC: 378 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 9484 43
CRC: 12 6
ES: 9 6
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 7 hours 48 min 26 sec
FEC: 213117 2415
CRC: 7675 258
ES: 432 201
SES: 14 0
UAS: 40 26
LOS: 1 0
LOF: 9 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 5991
CRC: 1447 3
ES: 581 3
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 7 hours 1 min 3 sec
FEC: 213117 2415
CRC: 683 258
ES: 410 201
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
-
Sorry to here your having line noise and with that in mind your thread has become a FTTC line issue rather than a Hardware issue so the ECI and HG612 HW goes out the window for the moment not literally of course, you may need the help of an OR engineer by the sounds of it.
RSUnCorr: 6085
-
I'll pull the modem and check the test socket when people finally sod off to bed and stop watching tv.
It starts as a very crackly dial tone which within 10 seconds sounds like there is a motor on the phone drowning it out, it's probably a BT side issue, it's best to be certain before sending requesting an engineer. might be the best chance yet to get a DLM reset.
-
The crackly dial tone, noise etc suggests to me that you need to contact whoever provides your phone service not your internet. This might save you some money, whatever, Openreach will have to fix it FOC, as far as I understand it. If you just say you have a crackly voice service and don't mention Internet, then I'm told that's the way to approach it. (Some people even go as far as putting networking kit to one side when the PSTN Openreach engineer is sent round, so I believe.)
-
And to add to Weaver's comments, if you are fortunate to have a multi-skilled technician (one of Black Sheep's flock) to attend for the PSTN fault you could then ask her/him, once the fault has been fixed, to perform a "circuit recalc" (which, if I remember correctly, is Openreach speak for a DLM reset). ;)
-
Could your ISP do a DLM reset for you?
(I have a likely looking button or two on Andrews and Arnold's clueless.aa.net.uk control panel server.)
-
Could your ISP do a DLM reset for you?
My understanding is that ISPs/CPs do not have access to the controls of the Openreach DSLAMs.
(I have a likely looking button or two on Andrews and Arnold's clueless.aa.net.uk control panel server.)
Could you perform a screen-scrape and then post the resulting image so that those of us interested may "have a look", please?
-
Pulled the modem, Doesn't matter if the modems or filter is connected, the wired phone in the test socket works intermittently ( lacking power ) and there is no dial tone what so ever now. it's a genuine BT open reach side fault with the added bonus the automated line diagnostic found a problem. report sent. Bt let you report faults now via the web, no need to convince a script monkey anymore you have a real problem when you know what to test.
Plus I get BT sport UHD, via BTTV, still have just enough speed to watch it. with 4mbps to spare :)
burakkucat thanks again for the info, "circuit recalc" is a new one to me.
-
I'll try to post two shots to Flickr
https://www.flickr.com/photos/cecilward/23992450631/in/dateposted-public/
https://www.flickr.com/photos/cecilward/24075035905/in/dateposted-public/
-
I'll try to post two shots to Flickr
Thank you. As soon as I looked at them I realised the difference! Your circuits are ADSL2 whereas Ragnarok's circuit is VDSL2. :)
-
Well my line is sorted now, a .3 extra db's of noise margin slightly lower error count so far, but the engineer was unable to get a line re-calc done, technically he fixed my line a 3 others without entering the premises, but he was old school, good at his job but is not fully upto date with all the technical stuff around dsl. The whole roads phone lines joins were submerged in water. He didn't have a tent so I used a couple of brollies to keep him and his work dry in the rain.
I should avoid any modem swapping today as my lines already had 3 resyncs today, much more and I might get interleaved for sure. I'm surprised it survived this week ( dropped down to 18mbps down stream ) without getting interleaving considering the entire join box was under water. I might flash my ECI modem to Open WRT if I can figure out how to back up BT's firmware first while i have the chance.
-
Overall, a good result. :)
From what you've written, I assume that the attending technician was a well-experienced in PSTN but not in xDSL. As he has fixed the underlying network fault, the VDSL2 circuit should (with time) recover of its own accord.
-
The ECI modem is back in still with BT's firmware. BT TV is working much better now. I left the BT sport UHD channel on and saw 1 glitch in an hour.
the Huawei seems to be picking up around 20ES/h, the ECI after sync the showtime nES counters remains static which probably means it's not picking up any, I assume that's the equivalent ES count on the ECI
I still suspect the Huawei is much better at detecting, handling and reporting errors. I'll have to upgrade the ECI firmware to openwrt to see if the new driver for the VDSL modem makes much difference.
The only other thing that did happen is that the day after the line fix DLM decided to band my downstream at 60mbps. Understandable considering the last week, but pointless now the line is fixed but, another example of why Openreach should let providers request a DLM reset, "line Recalc" without needing a BT engineer.
-
I'm not on FTTC, perhaps that make the difference, but I can reset the SNR and reset DLM myself. My ISP has a button in their web control panel UI (not available on 20CN).
-
Have you got the correct direction for the pmlscsg command? For pmlscsg, 0 specifies near end i.e. downstream (received at this end), 1 specifies far end.
You could also check both the CRC counters and the ES counters, if the CRC counters increase but the ES counters don't change, I think that's a fairly clear indication that the ES counter isn't working.
-
Just had a thunderstorm. woke me up. it picked up nES=3 during the storm.
a current grab from btagent_arc_version getstat
name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.ModulationType] : value= [VDSL] : found=[1]
name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.LineEncoding] : value= [DMT] : found=[1]
name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.DataPath] : value= [Fast] : found=[1]
name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.InterleaveDepth] : value= [1] : found=[1]
name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.LineNumber] : value= [1] : found=[1]
name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.UpstreamCurrRate] : value= [20000000] : found=[1]
name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.DownstreamCurrRate] : value= [59995000] : found=[1]
name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.UpstreamMaxRate] : value= [26127714] : found=[1]
name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.DownstreamMaxRate] : value= [75744752] : found=[1]
name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.UpstreamNoiseMargin] : value= [96] : found=[1]
name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.DownstreamNoiseMargin] : value= [102] : found=[1]
name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.UpstreamAttenuation] : value= [0] : found=[1]
name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.DownstreamAttenuation] : value= [171] : found=[1]
/opt/lantiq/bin/dsl_cpe_pipe.sh "g997csg 0 1" gives
nReturn=0 nChannel=0 nDirection=1 ActualDataRate=59995000 PreviousDataRate=0 ActualInterleaveDelay=0 ActualImpulseNoiseProtection=0 ActualNetDataRate=59995000 ActualImpulseNoiseProtectionRein=0 ActualImpulseNoiseProtectionNoErasure=0
So I got the correct direction
this should be the errored seconds for , Showtime , current day, previous day , current 15 minutes, previous 15mins, 15 minutes half an hour ago, /opt/lantiq/bin/dsl_cpe_pipe.sh pmlsctg 1 ; /opt/lantiq/bin/dsl_cpe_pipe.sh "pmlsc1dg 1 0" ; /opt/lantiq/bin/dsl_cpe_pipe.sh "pmlsc1dg 1 1" ; /opt/lantiq/bin/dsl_cpe_pipe.sh "pmlsc15mg 1 0" ; /opt/lantiq/bin/dsl_cpe_pipe.sh "pmlsc15mg 1 1" ; /opt/lantiq/bin/dsl_cpe_pipe.sh "pmlsc15mg 1 2"
nReturn=0 nDirection=1 nElapsedTime=214002 bValid=1 nES=2927 nSES=3 nLOSS=29 nUAS=37 nLOFS=0
nReturn=0 nDirection=1 nHistoryInterval=0 nElapsedTime=41229 bValid=1 nES=3 nSES=0 nLOSS=0 nUAS=0 nLOFS=0
nReturn=0 nDirection=1 nHistoryInterval=1 nElapsedTime=86400 bValid=1 nES=0 nSES=0 nLOSS=0 nUAS=0 nLOFS=0
nReturn=0 nDirection=1 nHistoryInterval=0 nElapsedTime=729 bValid=1 nES=2 nSES=0 nLOSS=0 nUAS=0 nLOFS=0
nReturn=0 nDirection=1 nHistoryInterval=1 nElapsedTime=900 bValid=1 nES=1 nSES=0 nLOSS=0 nUAS=0 nLOFS=0
nReturn=0 nDirection=1 nHistoryInterval=2 nElapsedTime=900 bValid=1 nES=0 nSES=0 nLOSS=0 nUAS=0 nLOFS=0
I think this includes daily crc's. /opt/lantiq/bin/dsl_cpe_pipe.sh "pmdpc1dg 0 1 0" ; /opt/lantiq/bin/dsl_cpe_pipe.sh "pmdpc1dg 0 1 1" ;
nReturn=0 nChannel=0 nDirection=1 nHistoryInterval=0 nElapsedTime=45694 bValid=1 nHEC=0 nTotalCells=0 nUserTotalCells=0 nIBE=0 nTxUserTotalCells=0 nTxIBE=0 nCRC_P=0 nCRCP_P=0 nCV_P=0 nCVP_P=0
nReturn=0 nChannel=0 nDirection=1 nHistoryInterval=1 nElapsedTime=86400 bValid=1 nHEC=0 nTotalCells=0 nUserTotalCells=0 nIBE=0 nTxUserTotalCells=0 nTxIBE=0 nCRC_P=0 nCRCP_P=0 nCV_P=0 nCVP_P=0
My HG612 usually picks up about 20-30es an hour, which seems to make sense as that would put using the http://www.kitz.co.uk/adsl/DLM_calculator.php (http://www.kitz.co.uk/adsl/DLM_calculator.php) MTBE high enough to be in amber territory, DLM never makes any positive decisions with that connected. I never thought there would be that big a difference between the ECI and Huawei modems. So it looks like I need the ECI in place to recover my line speed.
the HG612 however always seems to provide a more stable BTTV service, I wondered if the ECI was actually catching all the errors.
-
/opt/lantiq/bin/dsl_cpe_pipe.sh "g997csg 0 1" gives
nReturn=0 nChannel=0 nDirection=1 ActualDataRate=59995000 PreviousDataRate=0 ActualInterleaveDelay=0 ActualImpulseNoiseProtection=0 ActualNetDataRate=59995000 ActualImpulseNoiseProtectionRein=0 ActualImpulseNoiseProtectionNoErasure=0
So I got the correct direction
Unfortunately not. Some commands, like g997csg, take 0 = upstream and 1 = downstream. Other commands, like pmlsctg and pmdpc1dg, take 0 = near end and 1 = far end.
-
Ok, change of direction.
nReturn=0 nDirection=0 nElapsedTime=243829 bValid=1 nES=487 nSES=0 nLOSS=0 nUAS=37 nLOFS=0
nReturn=0 nDirection=0 nHistoryInterval=0 nElapsedTime=71057 bValid=1 nES=152 nSES=0 nLOSS=0 nUAS=0 nLOFS=0
nReturn=0 nDirection=0 nHistoryInterval=1 nElapsedTime=86400 bValid=1 nES=217 nSES=0 nLOSS=0 nUAS=0 nLOFS=0
nReturn=0 nDirection=0 nHistoryInterval=0 nElapsedTime=857 bValid=1 nES=0 nSES=0 nLOSS=0 nUAS=0 nLOFS=0
nReturn=0 nDirection=0 nHistoryInterval=1 nElapsedTime=900 bValid=1 nES=0 nSES=0 nLOSS=0 nUAS=0 nLOFS=0
nReturn=0 nDirection=0 nHistoryInterval=2 nElapsedTime=900 bValid=1 nES=1 nSES=0 nLOSS=0 nUAS=0 nLOFS=0
That looks more realistic! Still Lower than the HG612 and low enough to make the speed profile on DLM go green, I'm with BT. Thanks EJS.
I'll put the prior BT TV glitches down to a pending line fault.
Lets see if I get some speed back.
-
I just want to add my latest findings.
The ECI modem is fine, I have borrowed a nearly new spare from a friend and it's identical. There does not appear to be anything wrong with the DSL line and the way the ECI handles it. However it seems the ethernet driver in these modems is likely significantly weaker ( I don't have the measuring equipment to confirm absolutely this as fact ), and makes the signal between the modem and router prone to impulse noise. The give away moment was watching TV and the Water heating kicked in and it glitched badly for a few seconds. It didn't matter if i put my BT HH4 back in or my own router.
I eliminated the glitches on BT TV by putting an old 10/100 switch in between modem and router. The Switch has a grounding post I ran a cable to a near by radiator and hooked it up by attaching a grounding strap to the copper pipe. I replaced the ethernet cables with two shielded FTP cat6a cables.
BTTV is finally glitch free, with the ECI modem. Also bear in mind the UHD BTTV box comes with a Shielded FTP cable, not sure what catagory, looks like cat5e, this is also needed between box and router for glitch free tv too in my case. I've also Grounded my router and BT youview box via the aerial to eliminate, floating earth's, ground loops, and any unnecessary current flowing through the shields.
My modem does appear to be the later version with the a newer ethernet driver, I wonder if the older version is any better or worse?
The HG612 appears to be fine with regular UTP cable. It doesn't make much sense. I'm used to impulse noise affecting DSL upping error counts, but I have never seen it happen with regular unshielded ethernet cabling in a home environment. I've never seen any issue like this with ethernet cabling before except copper clad aluminium. One cable I tried was solid core pure copper cat6 still had problems with the ECI modem but not the HG612.
Now I just need to hope my DSL line recovers it's speed.