Print

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

[ejs]

The xcpe_574306_571801.bin DSL firmware file in this TP-Link release is identical to the one in the 141215 release. The version string in the DSL driver drv_dsl_cpe_api.ko and dsl_cpe_control is unchanged at 4.16.6. So that does make it look like it's just configuration changes (that we could have checked and changed ourselves with telnet shell access).

[mpmc]

Here's what mine says:-

Code: [Select]

/usr/sbin # ./dslLineStatusCheck.sh
nReturn=0 nDirection=0 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=1 bVirtualNoiseSupport=0 b20BitSupport=0

nReturn=0 nDirection=1 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=1 bVirtualNoiseSupport=0 b20BitSupport=0

nReturn=0 nChannel=0 nDirection=0 nNFEC=32 nRFEC=16 nLSYMB=16 nINTLVDEPTH=1 nINTLVBLOCK=32 nLPATH=0

nReturn=0 nChannel=0 nDirection=1 nNFEC=32 nRFEC=16 nLSYMB=16 nINTLVDEPTH=1 nINTLVBLOCK=32 nLPATH=0

nReturn=0 nChannel=0 nDirection=0 nTp=2 nMp=2 nSEQ=64 nBP=0 nMSGC=58 nMSGLP=0

nReturn=0 nChannel=0 nDirection=1 nTp=2 nMp=2 nSEQ=64 nBP=0 nMSGC=58 nMSGLP=0

nReturn=0 nDirection=0 nHistoryInterval=0 nElapsedTime=780 bValid=1 nEftrMin=656000 nErrorFreeBits=240752 nLeftr=19839

nReturn=0 nDirection=1 nHistoryInterval=0 nElapsedTime=780 bValid=1 nEftrMin=4294967295 nErrorFreeBits=61541 nLeftr=0

nReturn=0 nData="5008 0000 0001 0102 "

nReturn=0 nChannel=0 nDirection=0 ActualDataRate=5198000 PreviousDataRate=0 ActualInterleaveDelay=0 ActualImpulseNoiseProtection=470 ActualNetDataRate=5204000 ActualImpulseNoiseProtectionRein=0 ActualImpulseNoiseProtectionNoErasure=40

nReturn=0 nChannel=0 nDirection=1 ActualDataRate=19135000 PreviousDataRate=19998000 ActualInterleaveDelay=13 ActualImpulseNoiseProtection=440 ActualNetDataRate=19998000 ActualImpulseNoiseProtectionRein=10 ActualImpulseNoiseProtectionNoErasure=40

Not sure what any of that means though or whether G.INP is even enabled! Interestingly the SNR margin has gone up quite a bit.. Both used to be around 6~dB.

Code: [Select]

Upstream Downstream
Current Rate (Kbps) 5204 19998
Max Rate (Kbps) 5282 27598
SNR Margin (dB) 6.4 11.1
Line Attenuation (dB) 31.2 27
Errors (Pkts) 0 0


[WWWombat]

I therefore suspect ActualInterleaveDelay=16 is indeed 1.6ms.   iirc wwwombat did some rough calculations at how much reTX would add to delay and came out with something like 1.2 or 1.4 ms.   I cant find his post atm so apologies to wombat if I remembered wrong.

Sorry - I don't look in on this thread much.

The calculations I did were to multiply the interleaving depth by the width, and calculated the ratio for old-style and new-style, then factored against the knowledge that the old-style delay was 8ms. If that really is a valid way to calculate the new delay, it suggested a figure of 0.2ms ... which would be close to DLM's requirement of 0.

At the time I hadn't really gone into the G.INP spec so much, so wasn't sure whether there were more changes to the framing to take account of, that would increase the delay. I've looked more, and I still think the comparison is valid.

[kitz]

Cheers wombat.  I just realised that was on the upstream

After todays news about IFTN being unable to support reTX on the upstream, Im a bit concerned about things such as this

nReturn=0 nChannel=0 nDirection=1 ActualDataRate=23830000 PreviousDataRate=24998000 ActualInterleaveDelay=17

Can someone using this beta firmware please do me a favour and perform the following tests:-

1) A tracert to the BBC
2) A ping test to your IP using the tool here - dont forget to remove your IP from the results

Code: [Select]

ping -c 5 x
(please be patient, this script may take a moment before you see anything)

PING x: 56 data bytes
64 bytes from x: icmp_seq=0 ttl=53 time=14.746 ms
64 bytes from x: icmp_seq=1 ttl=53 time=14.688 ms
64 bytes from x: icmp_seq=2 ttl=53 time=14.527 ms
64 bytes from x: icmp_seq=3 ttl=53 time=14.590 ms
64 bytes from x: icmp_seq=4 ttl=53 time=14.654 ms

--- x ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 14.527/14.641/14.746/0.076 ms

TIA

[JHewess]

tracert to BBC:

Code: [Select]

Tracing route to bbc.co.uk [212.58.244.18]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  192.168.1.1
  2     9 ms     8 ms     9 ms  lo0.11.central11.pcl-bng02.plus.net [195.166.130
.152]
  3    19 ms    19 ms    19 ms  irb.11.PCL-CR01.plus.net [84.93.249.97]
  4    19 ms    19 ms    19 ms  ae1.ptw-cr01.plus.net [195.166.129.0]
  5    19 ms    19 ms    19 ms  kingston-gw.thdo.bbc.co.uk [212.58.239.6]
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8    21 ms    19 ms    20 ms  ae0.er01.telhc.bbc.co.uk [132.185.254.109]
  9    20 ms    20 ms    20 ms  132.185.255.149
 10    19 ms    19 ms    19 ms  fmt-vip72.telhc.bbc.co.uk [212.58.244.18]

Trace complete.
ping test:

Code: [Select]

PING *** (***): 56 data bytes
64 bytes from ***: icmp_seq=0 ttl=56 time=10.831 ms
64 bytes from ***: icmp_seq=1 ttl=56 time=11.003 ms
64 bytes from ***: icmp_seq=2 ttl=56 time=12.059 ms
64 bytes from ***: icmp_seq=3 ttl=56 time=10.984 ms
64 bytes from ***: icmp_seq=4 ttl=56 time=11.175 ms

--- ** ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 10.831/11.210/12.059/0.438 ms

[kitz]

Thank you very much.

I notice the addition 10ms delay at pcl-cr01 plusnet.    Didnt expect to see that there. 

[tommy45]

Thank you very much.

I notice the addition 10ms delay at pcl-cr01 plusnet.    Didnt expect to see that there. 

very odd, and IMO can't be connection related ,as latency only increases once on plusnets network, maybe a dodgy endpoint

[kitz]

Nope I expected to see it at hop 2
Cant be endpoint either because its already passed through the BNG.

Would ideally like to also see one from someone on BTretail as they dont use L2TP so we should see the path from backhaul -> RAS -> Internet.

[Mooingall]

I am playing about with the above beta firmware before I connect it up to my BT line.

I have disabled:
DDDNS (noipdns + dyndns processes)
Media Server (ushare processes)
SNMP (snmpd processes)
CWMP (cwmp TR-069 processes)

Yet in the process list they are all running still, on every boot:

Code: [Select]

  256 admin     2180 S    igmpd
  348 admin     2892 S    cos
  349 admin     2892 S    cos
  350 admin     2892 S    cos
  580 admin     4100 S    cwmp
  581 admin     4100 S    cwmp
  582 admin     4100 S    cwmp
  584 admin     2148 S    ntpc
  592 admin     2156 S    dyndns /var/tmp/dconf/dyndns.conf
  595 admin     2156 S    noipdns /var/tmp/dconf/noipdns.conf
  826 admin     1648 S    hostapd_ath0 /var/Wireless/2_4G_topology.conf
 1084 admin        0 DW   [mtlk]
 1095 admin        0 DW   [mtlk]
 1577 admin     2676 S    hostapd_wlan0 /var/Wireless/wlan0.ap_bss
 1969 admin     2716 S    httpd
 1971 admin     1820 S    upnpd -L br0 -W eth1 -en 1 -nat 0 -port 80 -url http
 1975 admin     2144 S    dnsProxy
 1979 admin     2564 S    ipsecVpn
 1984 admin      840 S    radvd -C /var/tmp/dconf/radvd_br0.conf -p /var/run/r
 1986 admin     1168 S    dhcpd /var/tmp/dconf/udhcpd.conf
 1991 admin     2596 S    snmpd -f /var/tmp/dconf/snmpd.conf
 2000 admin     1820 S    upnpd -L br0 -W eth1 -en 1 -nat 0 -port 80 -url http
 2003 admin     1820 S    upnpd -L br0 -W eth1 -en 1 -nat 0 -port 80 -url http
 2004 admin     1820 S    upnpd -L br0 -W eth1 -en 1 -nat 0 -port 80 -url http
 2005 admin     1820 S    upnpd -L br0 -W eth1 -en 1 -nat 0 -port 80 -url http
 2006 admin     1820 S    upnpd -L br0 -W eth1 -en 1 -nat 0 -port 80 -url http
 2007 admin     1820 S    upnpd -L br0 -W eth1 -en 1 -nat 0 -port 80 -url http
 2008 admin     1820 S    upnpd -L br0 -W eth1 -en 1 -nat 0 -port 80 -url http
 2014 admin     1080 S    dhcpc
 2026 admin     1120 S    zebra -d -f /var/tmp/dconf/zebra.conf
 2231 admin     2148 S    diagTool
 2266 admin     2604 S    ushare
 2271 admin     2604 S    ushare
 2272 admin     2604 S    ushare
 2273 admin     2604 S    ushare
 2276 admin     2604 S    ushare
 2277 admin     2604 S    ushare
 2278 admin     2604 S    ushare
 2284 admin     2604 S    ushare

Then we also have processes for stuff which I have not configured to use such as VPN stuff, yet ipsecVpn process is running.

From what I can tell these processes are all hardcoded in /lib/libccm.so to run no matter how you configure them in the WebUI.


Forcing these processes to die frees up an extra 18mb or so of RAM (we only have 60mb total) so I would much rather they never started in the first place

[ejs]

I looks like the TD-W9980 with this latest firmware supports ReTX in both directions.

There's a comment in drv_dsl_cpe_api.h in the 4.11.4 driver source code release that says ReTX was then only supported for downstream direction. There is a ChangeLog file in the driver source code, but the source code doesn't appear to be available anywhere for newer driver versions, so we can't tell exactly when it was added.

TP-Link might have only needed to change some configuration as their firmware already contained sufficiently new DSL components. If the ECI modems need a whole DSL subsystem upgrade, it might take longer for a firmware update for them to be built and tested.

[JHewess]

I'd be interested to know if anyone else experiences a funky dancing  d/s SNR as well.....

Just as an aside for anyone that might be interested....

Last weekend I was asked to do some more testing by TP-Link as they wanted to try and nail down why my ds SNR was all over the place and causing my connection to drop. I power cycled the router and started the test and, sods law, I've had a perfectly stable connection ever since! So it looks like my SNR woes may well have been a bug that was cleared by fully powering off the router. To be honest and from a purely line stats point of view, I've got the best connection I've ever had. My ds SNR never drops below 9db when previously it's always hovered just above 6db, even on the Huawei. My attenuation upstream and downstream is being held at 10.4 & 10.6 respectively, my TBB BQM is as it was before g.inp was enabled, and my line hasn't dropped once since last Friday evening when I started this last test. The firmware is certainly working for me so far.
 

[kitz]

I looks like the TD-W9980 with this latest firmware supports ReTX in both directions.

Thank you ejs.   Thats quite interesting information you managed to find and some good news for TPlink at least.

I was rather concerned when I saw things like this for the upstream

Return=0 nChannel=0 nDirection=1 ActualDataRate=19135000 PreviousDataRate=19998000 ActualInterleaveDelay=13

Where it leaves ECI and the HH5A's though is anyones guess.   Nothing coming out of BT at all about any impending fix.   

[kitz]

Last weekend I was asked to do some more testing by TP-Link as they wanted to try and nail down why my ds SNR was all over the place and causing my connection to drop. I power cycled the router and started the test and, sods law, I've had a perfectly stable connection ever since! So it looks like my SNR woes may well have been a bug that was cleared by fully powering off the router. To be honest and from a purely line stats point of view, I've got the best connection I've ever had. My ds SNR never drops below 9db when previously it's always hovered just above 6db, even on the Huawei. My attenuation upstream and downstream is being held at 10.4 & 10.6 respectively, my TBB BQM is as it was before g.inp was enabled, and my line hasn't dropped once since last Friday evening when I started this last test. The firmware is certainly working for me so far.

Thank you for the update.   I'm glad that things are now working as they should.   
Out of interest is that 10ms delay still there this morning @ hop3

[rapid111111]

I recently noticed a big drop in speeds...usually getting 70Mbps, now getting 55Mbps.
Was trying to see what it could be, perhaps implementation of G.INP and tried out this firmware. Nothings changed for me, so maybe it has nothing to do with it or perhaps i have a line fault that's separate to this. I've had a few BT engineers come out this week and they said my line stats are good with no errors and they're unsure why my speed is slow. I've tried both the BT Openreach modem and this TP link one...Same speeds...anyway, here is the log from telnet using this beta firmware.
Is there anyway i can tell if G.INP is enabled ?

Code: [Select]

--------------------------------------------------------------------------------
Welcome To Use TP-LINK COMMAND-LINE Interface Model.
--------------------------------------------------------------------------------
TP-LINK(conf)#sh
~ # cd /usr/sbin
/usr/sbin # ./dslLineStatusCheck.sh
nReturn=0 nDirection=0 bTrellisEnable=1 bBitswapEnable=0 bReTxEnable=0 bVirtualN
oiseSupport=0 b20BitSupport=0

nReturn=0 nDirection=1 bTrellisEnable=1 bBitswapEnable=0 bReTxEnable=0 bVirtualN
oiseSupport=0 b20BitSupport=0

nReturn=0 nChannel=0 nDirection=0 nNFEC=55 nRFEC=16 nLSYMB=6069 nINTLVDEPTH=312
nINTLVBLOCK=55 nLPATH=0

nReturn=0 nChannel=0 nDirection=1 nNFEC=52 nRFEC=16 nLSYMB=19968 nINTLVDEPTH=156
7 nINTLVBLOCK=52 nLPATH=0

nReturn=0 nChannel=0 nDirection=0 nTp=3 nMp=1 nSEQ=103 nBP=38 nMSGC=97 nMSGLP=0

nReturn=0 nChannel=0 nDirection=1 nTp=32 nMp=1 nSEQ=10 nBP=35 nMSGC=4 nMSGLP=0

nReturn=0 nDirection=0 nHistoryInterval=0 nElapsedTime=962 bValid=1 nEftrMin=429
4967295 nErrorFreeBits=0 nLeftr=0

nReturn=0 nDirection=1 nHistoryInterval=0 nElapsedTime=962 bValid=1 nEftrMin=429
4967295 nErrorFreeBits=0 nLeftr=0

nReturn=0 nData="5008 0000 0001 0102 "

nReturn=0 nChannel=0 nDirection=0 ActualDataRate=17000000 PreviousDataRate=0 Act
ualInterleaveDelay=600 ActualImpulseNoiseProtection=30 ActualNetDataRate=1700000
0 ActualImpulseNoiseProtectionRein=0 ActualImpulseNoiseProtectionNoErasure=30

nReturn=0 nChannel=0 nDirection=1 ActualDataRate=55032000 PreviousDataRate=0 Act
ualInterleaveDelay=800 ActualImpulseNoiseProtection=50 ActualNetDataRate=5503200
0 ActualImpulseNoiseProtectionRein=0 ActualImpulseNoiseProtectionNoErasure=50

/usr/sbin #


Code: [Select]

2015.04.25 19:46:58 xDSL Stats:
[1,0,0,0,0,0]0
status=Up
modulationType=VDSL2
X_TPLINK_CurrSupportLinkType=2
lineEncoding=
allowedProfiles=
currentProfile=
dataPath=
interleaveDepth=0
lineNumber=0
upstreamCurrRate=17000
downstreamCurrRate=55032
upstreamMaxRate=24522
downstreamMaxRate=84743
upstreamNoiseMargin=95
downstreamNoiseMargin=89
upstreamAttenuation=86
downstreamAttenuation=106
upstreamPower=126
downstreamPower=-16
ATURVendor=
ATURCountry=
ATUCVendor=
ATUCCountry=
totalStart=5156
showtimeStart=118
quarterHourStart=0
X_TPLINK_Bitswap=On
X_TPLINK_SRA=On
X_TPLINK_AdslModulationCfg=Multimode
X_TPLINK_AnnexType=Annex A/B/L/M
X_TPLINK_SupportAdslMode=VDSL2:A,B,A/B;T1.413:A;G.dmt:A;ADSL2:A,A/L/M;ADSL2+:A,M,A/L/M;Auto Sync-up:A/B/L/M
X_TPLINK_PtmMainIfName=ptm0
[2,0,0,0,0,0]1
receiveBlocks=0
transmitBlocks=0
cellDelin=0
linkRetrain=0
initErrors=0
initTimeouts=0
lossOfFraming=0
erroredSecs=0
X_TPLINK_US_ErroredSecs=0
severelyErroredSecs=0
X_TPLINK_US_SeverelyErroredSecs=0
FECErrors=288308
ATUCFECErrors=961
HECErrors=0
ATUCHECErrors=0
CRCErrors=4954
ATUCCRCErrors=0
[3,0,0,0,0,0]1
receiveBlocks=0
transmitBlocks=0
cellDelin=0
linkRetrain=0
initErrors=0
initTimeouts=0
lossOfFraming=0
erroredSecs=0
X_TPLINK_US_ErroredSecs=0
severelyErroredSecs=0
X_TPLINK_US_SeverelyErroredSecs=0
FECErrors=288308
ATUCFECErrors=961
HECErrors=0
ATUCHECErrors=0
CRCErrors=4954
ATUCCRCErrors=0
[error]0



[rapid111111]

Kitz,
thanks for all the information you've provided, especially the firmware. i've had a good read through it all. the more i read, the more i believe this is do to with G.INP. I've called Plusnet a few times, they're not too sure what's going on. They said they're not sure if G.INP is enabled or not. They can see interleaving has been put on.
From what i've read about, it looks like i need to give the router 24 hours to give DLM another chance to take a look and see what's going on with this new firmware and G.INP enabled. I'll report back on what happens.