Print

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

[burakkucat]

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. 

[Ragnarok]

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.

[burakkucat]

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.

[Ragnarok]

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.

[Weaver]

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).

[ejs]

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.

[Ragnarok]

Just had a thunderstorm. woke me up. it picked up nES=3  during the storm.

a current grab from btagent_arc_version getstat

Code: [Select]

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"

Code: [Select]

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" ;

Code: [Select]

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 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.

[ejs]

/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.

[Ragnarok]

Ok, change of direction.

Code: [Select]

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.

[Ragnarok]

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.