Kitz Forum
Broadband Related => Broadband Hardware => Topic started by: kitz on April 13, 2015, 09:47:25 AM
-
TP-Link have made debug firmware available that has hopefully corrected the g.inp issue.
This is debug firmware and they would like some feedback to see if it fixes the issue.
The information that they would like is
1) Has it corrected the low speed issue
2) Line Stats
To get line stats use telnet with the following command:
C:\Documents and Settings\Administrator>telnet 192.168.1.1
username:admin
password:admin
TP-LINK(conf)#sh
~ # cd /usr/sbin
/usr/sbin # ./dslLineStatusCheck.sh
Please paste the results in this thread so that TP-Link can monitor any feedback.
--
Firmware attached to this post.
-
I'm on Infinity1 capped at less than my max rate and don't do any online gaming so my interest is academic rather than having a problem. However, the new firmware seems to have had an effect. My previous d/l max rate was about 46/47M with an SNR margin of 6dB. It is now 48M with a margin of 9.3dB. Telnet info below.
username:admin
password:
--------------------------------------------------------------------------------
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=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=1340 bValid=1 nEftrMin=1568000 nErrorFreeBits=824768 nLeftr=39987
nReturn=0 nDirection=1 nHistoryInterval=0 nElapsedTime=1340 bValid=1 nEftrMin=4294967295 nErrorFreeBits=203528 nLeftr=0
nReturn=0 nData="5008 0000 0001 0102 "
nReturn=0 nChannel=0 nDirection=0 ActualDataRate=9989000 PreviousDataRate=0 ActualInterleaveDelay=0 ActualImpulseNoiseProtection=470 ActualNetDataRate=10000000 ActualImpulseNoiseProtectionRein=0 ActualImpulseNoiseProtectionNoErasure=40
nReturn=0 nChannel=0 nDirection=1 ActualDataRate=39950000 PreviousDataRate=39998000 ActualInterleaveDelay=16 ActualImpulseNoiseProtection=440 ActualNetDataRate=39998000 ActualImpulseNoiseProtectionRein=0 ActualImpulseNoiseProtectionNoErasure=40
/usr/sbin #
-
I'd be interested to know if anyone else experiences a funky dancing d/s SNR as well. Mine is all over the place. My connected rate has held steady at 79993 (or thereabouts) since Sat, but the attainable rate shifts about and has been as low as 50 something with an SNR of 1.2db. The connection has never dropped, which makes me wonder if it's a bug.
-
Hi licquorice - thanks for posting your stats, please do let us know how things go.
@ jHewess - When originally beta testing the original f/w I had a weird issue with the SNR which would drift. My line is normally rock solid and at the time (pre x-talker) it would sit at 7.2 for weeks on end never changing anymore than 0.1db either way. It took my line so low that I ended up being DLM'd for interleaving. I thought they fixed it though, because I ran it for several weeks after and it was fine, so perhaps not related.
I'm not running the beta version as Im still on an ECI cab and not affected by g.inp yet.
-
1) Has it corrected the low speed issue
2) Line Stats
1) Yes, get 79997/19999 sync.
2) /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=3879 bValid=1 nEftrMin=1568000 nErrorFreeBits=4771424 nLeftr=79996
nReturn=0 nDirection=1 nHistoryInterval=0 nElapsedTime=3879 bValid=1 nEftrMin=4294967295 nErrorFreeBits=63852078 nLeftr=0
nReturn=0 nData="5008 0000 0001 0102 "
nReturn=0 nChannel=0 nDirection=0 ActualDataRate=19978000 PreviousDataRate=0 ActualInterleaveDelay=0 ActualImpulseNoiseProtection=460 ActualNetDataRate=19999000 ActualImpulseNoiseProtectionRein=0 ActualImpulseNoiseProtectionNoErasure=40
nReturn=0 nChannel=0 nDirection=1 ActualDataRate=79903000 PreviousDataRate=79997000 ActualInterleaveDelay=16 ActualImpulseNoiseProtection=440 ActualNetDataRate=79997000 ActualImpulseNoiseProtectionRein=0 ActualImpulseNoiseProtectionNoErasure=40
-
I tried the beta firmware this evening. Mixed results...
Speedtest.net ping went down from 35ms to 30ms. Speedtest was down from 25M to 22M.
In the stats on the router summary page, speed was down from 25000 to 24998
Downstream SNR margin was 6db, now 10.5db
Stats from telnet
/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=109 bValid=1 nEftrMin=522000 nErrorFreeBits=42282 nLeftr=24996
nReturn=0 nDirection=1 nHistoryInterval=0 nElapsedTime=109 bValid=1 nEftrMin=4294967295 nErrorFreeBits=468690 nLeftr=0
nReturn=0 nData="5008 0000 0001 0102 "
nReturn=0 nChannel=0 nDirection=0 ActualDataRate=6532000 PreviousDataRate=0 ActualInterleaveDelay=0 ActualImpulseNoiseProtection=500 ActualNetDataRate=6895000 ActualImpulseNoiseProtectionRein=10 ActualImpulseNoiseProtectionNoErasure=40
nReturn=0 nChannel=0 nDirection=1 ActualDataRate=23830000 PreviousDataRate=24998000 ActualInterleaveDelay=17 ActualImpulseNoiseProtection=450 ActualNetDataRate=24998000 ActualImpulseNoiseProtectionRein=10 ActualImpulseNoiseProtectionNoErasure=40
/usr/sbin # Connection closed by foreign host.
-
Thank you Andy & Kirbyan
-------
For PT @ TP-Link, these are 'Hairy Bikers' stats.
He says "he is syncing a lot better now" (speed)
/usr/sbin # ./dslLineStatusCheck.sh
nReturn=0 nDirection=0 bTrellisEnable=1 bBitswapEnable=0 bReTxEnable=0 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=96 nRFEC=16 nLSYMB=6053 nINTLVDEPTH=253 nINTLVBLOCK=96 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=5 nMp=1 nSEQ=70 nBP=79 nMSGC=64 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=176458 bValid=1 nEftrMin=166528 nErrorFreeBits=175691880 nLeftr=64218
nReturn=0 nDirection=1 nHistoryInterval=0 nElapsedTime=176458 bValid=1 nEftrMin=4294967295 nErrorFreeBits=0 nLeftr=0
nReturn=0 nData="5008 0000 0001 0102 "
nReturn=0 nChannel=0 nDirection=0 ActualDataRate=19997000 PreviousDataRate=0 ActualInterleaveDelay=800 ActualImpulseNoiseProtection=20 ActualNetDataRate=19997000 ActualImpulseNoiseProtectionRein=0 ActualImpulseNoiseProtectionNoErasure=20
nReturn=0 nChannel=0 nDirection=1 ActualDataRate=62018000 PreviousDataRate=64961000 ActualInterleaveDelay=15 ActualImpulseNoiseProtection=420 ActualNetDataRate=64961000 ActualImpulseNoiseProtectionRein=10 ActualImpulseNoiseProtectionNoErasure=40
-
For PT @ TP-Link
These are J Hewess's stats. He is reporting direct to another of your collegues @ TPlink already so you should already have his full info and feedback
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=27093 bValid=1 nEftrMin=60928 nErrorFreeBits=4159510911 nLeftr=4294967261
nReturn=0 nDirection=1 nHistoryInterval=0 nElapsedTime=27094 bValid=1 nEftrMin=4294967295 nErrorFreeBits=8264771 nLeftr=0
nReturn=0 nData="5008 0000 0001 0102 "
nReturn=0 nChannel=0 nDirection=0 ActualDataRate=19978000 PreviousDataRate=0 ActualInterleaveDelay=0 ActualImpulseNoiseProtection=470 ActualNetDataRate=19999000
ActualImpulseNoiseProtectionRein=0 ActualImpulseNoiseProtectionNoErasure=40
nReturn=0 nChannel=0 nDirection=1 ActualDataRate=79899000 PreviousDataRate=79993000 ActualInterleaveDelay=16 ActualImpulseNoiseProtection=440 ActualNetDataRate=79993000
ActualImpulseNoiseProtectionRein=0 ActualImpulseNoiseProtectionNoErasure=40
-
It looks like the DSLAM forced a resync just after 5 this morning, I'm on a short line so it doesn't normally drop by itself. The stats have changed a bit, so I'm posting them again:
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=5719 bValid=1 nEftrMin=1352704 nErrorFreeBits=4258133407 nLeftr=4294967295
nReturn=0 nDirection=1 nHistoryInterval=0 nElapsedTime=5719 bValid=1 nEftrMin=4294967295 nErrorFreeBits=1745469 nLeftr=0
nReturn=0 nData="5008 0000 0001 0102 "
nReturn=0 nChannel=0 nDirection=0 ActualDataRate=19139000 PreviousDataRate=0 ActualInterleaveDelay=0 ActualImpulseNoiseProtection=550 ActualNetDataRate=19999000 ActualImpulseNoiseProtectionRein=10 ActualImpulseNoiseProtectionNoErasure=40
nReturn=0 nChannel=0 nDirection=1 ActualDataRate=76343000 PreviousDataRate=79997000 ActualInterleaveDelay=16 ActualImpulseNoiseProtection=440 ActualNetDataRate=79997000 ActualImpulseNoiseProtectionRein=10 ActualImpulseNoiseProtectionNoErasure=40
The ActualImpulseNoiseProtection has increased and the up and down ActualDataRate's have dropped. Speedtests are slighty lower than before.
-
No resync since last post, stats as previously.
-
The Eftr etc figures are your G.INP counters
ActualImpulseNoiseProtection=460 - I suspect that will actually be 46 & 44
ActualInterleaveDelay=16m - In the same vein I suspect that may be 1.6ms
But just to double check whats your latency like?
-
My latency is fine, pinging bbc.co.uk averages 13.5ms at the moment. With the old firmware it was more like 30.
Here is a snapshot thinkbroadband graph. The drop Monday night was when I swapped from a Billion 8800NL back to the TP-Link with the new firmware.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fping%2Fshare-thumb%2Fda5e100177325d8007bae57ca921172d-13-04-2015.png&hash=5f2ecdb0b7ea319c8e82555dfd9ebde53dd35acf)
This second one is from Saturday when I swapped the TP-Link with the old firmware for the Billion:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fping%2Fshare-thumb%2Ff77fa0d2dacae85a0120d3d1ab7aade1-11-04-2015.png&hash=f056b712acb8630f8364f5c8a40a42d89b52fa29)
-
Looks like Tplink / lantiq may of changed the bRetTXEnable Boolean from false to true lineFeature DataCfg & xTM_Mgmt_Mode RETX_ENA=1
The infineon-utilities GPL has been realised many times so I Wonder if our friends from tplink {welcome btw} could add any insight to the change log ?
Thanks :)
-
My latency is fine, pinging bbc.co.uk averages 13.5ms at the moment. With the old firmware it was more like 30.
Thanks, that looks good :)
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. I think most people will agree that for the benefits of reTx when it comes to noise protection <2ms is nothing and much better than the old system - when it is working correctly :D
-
Looks like Tplink / lantiq may of changed the bRetTXEnable Boolean from false to true lineFeature DataCfg & xTM_Mgmt_Mode RETX_ENA=1
Not sure HB, all I know is that its in the lantiq f/w and ReTX not open properly. I'll ask.
-
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).
-
Here's what mine says:-
/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.
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
-
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.
-
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 (http://www.erik.co.uk/lg/) - dont forget to remove your IP from the results
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
-
tracert to BBC:
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:
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
-
Thank you very much.
I notice the addition 10ms delay at pcl-cr01 plusnet. Didnt expect to see that there. :hmm:
-
Thank you very much.
I notice the addition 10ms delay at pcl-cr01 plusnet. Didnt expect to see that there. :hmm:
very odd, and IMO can't be connection related ,as latency only increases once on plusnets network, maybe a dodgy endpoint
-
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.
-
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:
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 :(
-
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.
-
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.
-
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. :'(
-
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
-
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 ?
--------------------------------------------------------------------------------
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 #
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
-
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.
-
Reporting back. Looks like my connection dropped even further overnight to 49Mbps
-
Hi rapid.
Once the new firmware has been implemented, most users have found that it has restored their speeds. Most saw an immediate improvement, but for some it takes a couple of days.
Ive had a look at your stats. Im afraid Im not very good at reading the raw data because I dont know what some of them are, but the one thing that does stand out is this
nReturn=0 nChannel=0 nDirection=0 ActualDataRate=17000000 PreviousDataRate=0 ActualInterleaveDelay=600 ActualImpulseNoiseProtection=30 ActualNetDataRate=17000000 ActualImpulseNoiseProtectionRein=0 ActualImpulseNoiseProtectionNoErasure=30
nReturn=0 nChannel=0 nDirection=1 ActualDataRate=55032000 PreviousDataRate=0 ActualInterleaveDelay=800 ActualImpulseNoiseProtection=50 ActualNetDataRate=55032000 ActualImpulseNoiseProtectionRein=0 ActualImpulseNoiseProtectionNoErasure=50
The figures in blue suggest INP rather than G.INP and the figures in red suggest a higher interleave delay than you'd expect with G.INP.
Are you definitely on a Huawei cabinet?
-
On the phone with Plusnet now, they seem to think that G.INP is not enabled. and i'm on just INP like you're saying.
Asked to check if i'm on Huawei cabinet, they're not sure.
Quite confused now what the problem may be, all the symptoms reported for G.INP seem very similar to what i'm getting.
Have had 2 engineers come and check my home and the cabinet both to report no faults. There's a 3rd one booked to go to the exchange a week from now as i'm away. Will see what happens
-
Out of interest is that 10ms delay still there this morning @ hop3
I've just done another test, and bizarrely I think my homeplugs may be skewing the results somewhat.
Tracert to BBC via homeplug:
Tracing route to bbc.co.uk [212.58.244.20]
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms 192.168.1.1
2 9 ms 9 ms 11 ms lo0.11.central11.pcl-bng02.plus.net [195.166.130.152]
3 22 ms 19 ms 23 ms irb.11.PCL-CR02.plus.net [84.93.249.98]
4 20 ms 24 ms 19 ms ae2.pcl-cr01.plus.net [195.166.129.6]
5 24 ms 22 ms 19 ms ae1.ptw-cr01.plus.net [195.166.129.0]
6 19 ms 30 ms 26 ms kingston-gw.thdo.bbc.co.uk [212.58.239.6]
7 * * * Request timed out.
8 * * * Request timed out.
9 22 ms 19 ms 19 ms ae0.er01.telhc.bbc.co.uk [132.185.254.109]
10 21 ms 19 ms 21 ms 132.185.255.149
11 20 ms 19 ms 19 ms fmt-vip71.telhc.bbc.co.uk [212.58.244.20]
Trace complete.
Tracert to BBC with a direct Ethernet connection:
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 8 ms 7 ms 8 ms lo0.11.central11.pcl-bng02.plus.net [195.166.130.152]
3 22 ms 7 ms 8 ms irb.11.PCL-CR01.plus.net [84.93.249.97]
4 22 ms 7 ms 7 ms ae1.ptw-cr01.plus.net [195.166.129.0]
5 8 ms 8 ms 8 ms kingston-gw.thdo.bbc.co.uk [212.58.239.6]
6 * * * Request timed out.
7 * * * Request timed out.
8 9 ms 8 ms 8 ms ae0.er01.telhc.bbc.co.uk [132.185.254.109]
9 9 ms 9 ms 8 ms 132.185.255.149
10 8 ms 8 ms 8 ms fmt-vip72.telhc.bbc.co.uk [212.58.244.18]
Trace complete.
No idea why they only appear to be effecting the connection from hop 3 onwards, but it does appear that the routing is changing.
Have just switched back and forth again, and it doesn't look like it's the routing as the hops are reversed below but with the same respective pings, so definitely an odd side effect of the homeplugs...
via homeplug:
Tracing route to bbc.co.uk [212.58.246.103]
over a maximum of 30 hops:
1 2 ms 1 ms 1 ms 192.168.1.1
2 9 ms 9 ms 9 ms lo0.11.central11.pcl-bng02.plus.net [195.166.130.152]
3 22 ms 23 ms 19 ms irb.11.PCL-CR01.plus.net [84.93.249.97]
4 19 ms 19 ms 23 ms ae1.ptw-cr01.plus.net [195.166.129.0]
5 23 ms 19 ms 27 ms kingston-gw.thdo.bbc.co.uk [212.58.239.6]
6 * * * Request timed out.
7 20 ms 20 ms 20 ms ae0.er01.cwwtf.bbc.co.uk [132.185.254.93]
8 23 ms 24 ms 20 ms 132.185.255.165
9 20 ms 20 ms 24 ms fmt-vip132.cwwtf.bbc.co.uk [212.58.246.103]
Trace complete.
direct:
Tracing route to bbc.co.uk [212.58.244.20]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 8 ms 9 ms 8 ms lo0.11.central11.pcl-bng02.plus.net [195.166.130
.152]
3 15 ms 7 ms 7 ms irb.11.PCL-CR02.plus.net [84.93.249.98]
4 8 ms 8 ms 8 ms ae2.pcl-cr01.plus.net [195.166.129.6]
5 8 ms 8 ms 9 ms ae1.ptw-cr01.plus.net [195.166.129.0]
6 8 ms 8 ms 8 ms kingston-gw.thdo.bbc.co.uk [212.58.239.6]
7 * * * Request timed out.
8 * * * Request timed out.
9 9 ms 8 ms 8 ms ae0.er01.telhc.bbc.co.uk [132.185.254.109]
10 9 ms 9 ms 9 ms 132.185.255.149
11 8 ms 8 ms 8 ms fmt-vip71.telhc.bbc.co.uk [212.58.244.20]
Trace complete.
-
On the phone with Plusnet now, they seem to think that G.INP is not enabled. and i'm on just INP like you're saying.
One thing that has been observed is if there is a G.INP issue then the ISP cant perform a GEA test and it comes back blank. Im sure they would have spotted this.
Asked to check if i'm on Huawei cabinet, they're not sure.
They wont know. That may take some detective work on your part. If you put your phone no in here (https://www.dslchecker.bt.com/), it should tell you which cabinet you are attached to. Then its a case of walking around your area to see what the cab looks like. We can then identify it from the shape of the FTTC cabinet (http://www.kitz.co.uk/adsl/fttc-cabinets.htm#fttc_street_cabinet)(the grills are the easiest way to identify)
-
I've just done another test, and bizarrely I think my homeplugs may be skewing the results somewhat.
No idea why they only appear to be effecting the connection from hop 3 onwards, but it does appear that the routing is changing.
Have just switched back and forth again, and it doesn't look like it's the routing as the hops are reversed below but with the same respective pings, so definitely an odd side effect of the homeplugs...
I'm scratching my head because I cannot see any possible way that the plugs could affect hop 3 and send you to a different ibr router @ plusnet. :hmm:
Are you using different DNS in your network settings on the LAN interface than is set for wireless?
-
Nope, nothing's changing other than switching from one cable that's going via the homeplug by the PC, for another cable that's running down the stairs directly to the router. Although the second set of tests seems to indicate that it's not the homeplug effecting the route, just the pings.
IIRC they do have some sort of inbuilt QoS system, perhaps that's effecting the ping. They certainly seem to throttle speeds, because while the connection between the upstairs homeplug and the one by the router is 200Mbps+ the throughput speed hovers around the 50Mbps region.
-
Plusnet routing often has multiple paths to the same destination, and bbc.co.uk has multiple IP addresses.
The beta firmware appears to have given full telnet shell access, so you could find the remote equipment vendor with the command:
/firmware/dsl_cpe_pipe.sh g997listrg 1
-
I remember seeing - and visiting - a link to a random website that listed all cabinets for a given exchange, and showed if they were Huawei or ECI. Like a div I didn't save the link but I'll have a look and see if I can find it again.
EDIT
Found it: https://www.telecom-tariffs.co.uk/codelook.htm
You'll need to know what your cabinet's number is first.
Pop in a phone number, or partial, click 'lookup number'. Then click on your locality, and then on 'All *** Fibre Cabinets' (*** will change depending how many your exchange has). Scroll down, and it should show which brand of cabinet you're connected to.
-
Thanks for that. Just checked. It says ECI for the cabinet according to that website from Jhewess.
-
That lookup isn't up to date. Look up Mere,Warminster and it say no cabinets found and fibre not planned!
-
Right. I guess I'll have to have a wonder round and see when I'm back in a week
-
I would think that if it says your cab is ECI, it doesn't really matter if Mere is up to date or not - your cabinet is going to be ECI.
-
That lookup isn't up to date. Look up Mere,Warminster and it say no cabinets found and fibre not planned!
It will depend on the date of the latest dataset they managed to get hold of.
Source: BT Wholesale broadband datasets dated February 2015
-
Found it: https://www.telecom-tariffs.co.uk/codelook.htm
OT:
JHewess,
Many thanks for link, it has filled in some missing information on my line ;D
Much appreciated.
Kitz,
Might it be useful to post link somewhere else to help answer all the questions about cabs etc.
Even if out of date lots of the information is still valid and useful.
It might get lost over time mid thread.
-
Yep it had already crossed my mind to put the info on the main site and I'd added a note to my desktop. I have to go out now but will look again later.
-
Looking at Mere again, does 21CN WBC: 30th September 2013 mean TalkTalk LLU? I would not have expected so and for ADSL Mere is 20CN or TalkTalk LLU only.
If others are seeing a level of inaccuracy on that site, if it is linked it should have a big warning attached!
Edit: The exchange information from http://www.kitz.co.uk/adsl/adslchecker.php is correct.
-
If you would like inaccurate (but historic) information about the Mere exchange, I can look it up in my 1977 copies of the red and green books! :P
-
Yep it had already crossed my mind to put the info on the main site and I'd added a note to my desktop. I have to go out now but will look again later.
New page added: Look up your Fibre cabinet (http://www.kitz.co.uk/adsl/cabinet-lookup.htm)
-
I've just installed the beta firmware, my dl has gone from 52 to 59mb and ul from 15 to 17mb, still some way to go though to reach my original stats before BT shafted the HH5 in Feb with a firmware 'upgrade', I was on dl 72mb and ul 19mb for 13 months.
here are the current stats from telnet
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=213472 bValid=1 nEftrMin=266680 nErrorFreeBits=196826795 nLeftr=59881
nReturn=0 nDirection=1 nHistoryInterval=0 nElapsedTime=213472 bValid=1 nEftrMin=4294967295 nErrorFreeBits=58924378 nLeftr=0
nReturn=0 nData="5008 0000 0001 0102 "
nReturn=0 nChannel=0 nDirection=0 ActualDataRate=16229000 PreviousDataRate=0 ActualInterleaveDelay=0 ActualImpulseNoiseProtection=550 ActualNetDataRate=17000000 ActualImpulseNoiseProtectionRein=10 ActualImpulseNoiseProtectionNoErasure=40
nReturn=0 nChannel=0 nDirection=1 ActualDataRate=57362000 PreviousDataRate=59997000 ActualInterleaveDelay=14 ActualImpulseNoiseProtection=440 ActualNetDataRate=59997000 ActualImpulseNoiseProtectionRein=10 ActualImpulseNoiseProtectionNoErasure=40
-
To report back, 3rd engineer came today.
turns out a new a pair was placed (old pair contacts were damaged according to engineer) in the building basement and my line is now full speed and better than before achieving full 80mbps and i'm seeing single digit pings on game servers which i haven't come across before. I guess that means interleaving is off.
So it had nothing to do with G.INP or TP-W9880 in this case.
-
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.
Been on holiday, but if you are still looking for data from BT Retail customer, ping and tracert to BBC below.
Tracing route to www.bbc.net.uk [212.58.244.69]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.1.254
2 * * * Request timed out.
3 * 9 ms 8 ms 31.55.186.193
4 10 ms 9 ms 9 ms 31.55.186.212
5 9 ms 10 ms 9 ms 195.99.127.54
6 10 ms 10 ms 10 ms host213-121-193-111.ukcore.bt.net [213.121.
11]
7 10 ms 10 ms 10 ms 194.74.65.42
8 * * * Request timed out.
9 * * * Request timed out.
10 10 ms 10 ms 10 ms ae0.er01.telhc.bbc.co.uk [132.185.254.109]
11 11 ms 11 ms 11 ms 132.185.255.149
12 10 ms 10 ms 10 ms bbc-vip114.telhc.bbc.co.uk [212.58.244.69]
Trace complete.
Pinging www.bbc.net.uk [212.58.244.69] with 32 bytes of data:
Reply from 212.58.244.69: bytes=32 time=10ms TTL=53
Reply from 212.58.244.69: bytes=32 time=10ms TTL=53
Reply from 212.58.244.69: bytes=32 time=10ms TTL=53
Reply from 212.58.244.69: bytes=32 time=11ms TTL=53
Ping statistics for 212.58.244.69:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 10ms, Maximum = 11ms, Average = 10ms
-
Thanks guys. :)
@Licquorice
Thanks for that ping. It confirms that there is no delay downstream.. as per this from your earlier figures.
Return=0 nChannel=0 nDirection=0 ActualDataRate=9989000 PreviousDataRate=0 ActualInterleaveDelay=0 ActualImpulseNoiseProtection=470 ActualNetDataRate=10000000 ActualImpulseNoiseProtectionRein=0 ActualImpulseNoiseProtectionNoErasure=40
What I'd also be interested in seeing is your upstream latency - because I see this on your earlier results:
nReturn=0 nChannel=0 nDirection=1 ActualDataRate=39950000 PreviousDataRate=39998000 ActualInterleaveDelay=16 ActualImpulseNoiseProtection=440 ActualNetDataRate=39998000 ActualImpulseNoiseProtectionRein=0 ActualImpulseNoiseProtectionNoErasure=40
For that you'd need to do the test at erik.co.uk (http://www.erik.co.uk/lg/) as outlined in this post (http://forum.kitz.co.uk/index.php/topic,15322.15.html) to get a reverse ping.
TIA
-
Reverse ping below. ActualInterleaveDelay=16 still.
PING : 56 data bytes
64 bytes from : icmp_seq=0 ttl=49 time=11.267 ms
64 bytes from : icmp_seq=1 ttl=49 time=11.122 ms
64 bytes from : icmp_seq=2 ttl=49 time=10.885 ms
64 bytes from : icmp_seq=3 ttl=49 time=11.352 ms
64 bytes from : icmp_seq=4 ttl=49 time=11.176 ms
-
ADSL2+ WBC Customer here.
Here is what my W8980 Modded to W9980 says using said command.
nReturn=0 nDirection=0 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=0 bVirtualNoiseSupport=0 b20BitSupport=0
nReturn=0 nDirection=1 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=0 bVirtualNoiseSupport=0 b20BitSupport=0
nReturn=0 nChannel=0 nDirection=0 nNFEC=248 nRFEC=16 nLSYMB=264 nINTLVDEPTH=2 nINTLVBLOCK=248 nLPATH=0
nReturn=0 nChannel=0 nDirection=1 nNFEC=255 nRFEC=4 nLSYMB=1847 nINTLVDEPTH=32 nINTLVBLOCK=255 nLPATH=0
nReturn=0 nChannel=0 nDirection=0 nTp=1 nMp=8 nSEQ=76 nBP=28 nMSGC=70 nMSGLP=0
nReturn=0 nChannel=0 nDirection=1 nTp=1 nMp=1 nSEQ=63 nBP=250 nMSGC=57 nMSGLP=0
nReturn=0 nDirection=0 nHistoryInterval=0 nElapsedTime=8513 bValid=1 nEftrMin=4294967295 nErrorFreeBits=0 nLeftr=0
nReturn=0 nDirection=1 nHistoryInterval=0 nElapsedTime=8513 bValid=1 nEftrMin=0 nErrorFreeBits=0 nLeftr=0
nReturn=0 nData="5008 0000 0001 0000 "
nReturn=0 nChannel=0 nDirection=0 ActualDataRate=953000 PreviousDataRate=0 ActualInterleaveDelay=400 ActualImpulseNoiseProtection=20 ActualNetDataRate=953000 Ac
tualImpulseNoiseProtectionRein=0 ActualImpulseNoiseProtectionNoErasure=4
nReturn=0 nChannel=0 nDirection=1 ActualDataRate=7243000 PreviousDataRate=0 ActualInterleaveDelay=900 ActualImpulseNoiseProtection=2 ActualNetDataRate=7243000 A
ctualImpulseNoiseProtectionRein=0 ActualImpulseNoiseProtectionNoErasure=2
Not sure what all that means which makes a change however the connection seems very stable now on this firmware.
-
some more stats from a BT Infinity II end user, as far as I know I'm connected to a Huawei cabinet.
Traceroute to www.bbc.net.uk, ping test and a reverse ping, plus my router stats which show my upload speed has increased from when I ran the router stats on the 5th May.
Router stats from telnet
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=141372 bValid=1 nEftrMin=526120 nErrorFreeBits=4081378700 nLeftr=4294967207
nReturn=0 nDirection=1 nHistoryInterval=0 nElapsedTime=141372 bValid=1 nEftrMin=4294967295 nErrorFreeBits=40941709 nLeftr=0
nReturn=0 nData="5008 0000 0001 0102 "
nReturn=0 nChannel=0 nDirection=0 ActualDataRate=18169000 PreviousDataRate=0 ActualInterleaveDelay=0 ActualImpulseNoiseProtection=550 ActualNetDataRate=19000000 ActualImpulseNoiseProtectionRein=10 ActualImpulseNoiseProtectionNoErasure=40
nReturn=0 nChannel=0 nDirection=1 ActualDataRate=57362000 PreviousDataRate=59997000 ActualInterleaveDelay=14 ActualImpulseNoiseProtection=440 ActualNetDataRate=59997000 ActualImpulseNoiseProtectionRein=10 ActualImpulseNoiseProtectionNoErasure=40
Traceroute www.bbc.net.uk via Network Utlity Mac OSX
traceroute: Warning: www.bbc.net.uk has multiple addresses; using 212.58.246.90
traceroute to www.bbc.net.uk (212.58.246.90), 64 hops max, 72 byte packets
1 192.168.1.1 (192.168.1.1) 3.761 ms 4.394 ms 9.965 ms
2 * * *
3 * * *
4 31.55.186.140 (31.55.186.140) 19.691 ms 13.129 ms 13.563 ms
5 195.99.127.38 (195.99.127.38) 13.784 ms 14.331 ms 28.132 ms
6 peer2-xe8-1-0.telehouse.ukcore.bt.net (109.159.255.101) 19.539 ms 22.341 ms 25.423 ms
7 194.74.65.42 (194.74.65.42) 13.479 ms 13.642 ms 24.681 ms
8 * * *
9 ae0.er01.cwwtf.bbc.co.uk (132.185.254.93) 17.505 ms 15.360 ms 18.272 ms
10 132.185.255.165 (132.185.255.165) 19.273 ms 21.148 ms 20.252 ms
11 bbc-vip011.cwwtf.bbc.co.uk (212.58.246.90) 20.475 ms 22.776 ms 20.292 ms
Ping www.bbc.net.uk via Network Utlity Mac OSX
PING www.bbc.net.uk (212.58.244.71): 56 data bytes
64 bytes from 212.58.244.71: icmp_seq=0 ttl=53 time=11.098 ms
64 bytes from 212.58.244.71: icmp_seq=1 ttl=53 time=10.549 ms
64 bytes from 212.58.244.71: icmp_seq=2 ttl=53 time=10.631 ms
64 bytes from 212.58.244.71: icmp_seq=3 ttl=53 time=10.928 ms
64 bytes from 212.58.244.71: icmp_seq=4 ttl=53 time=10.996 ms
64 bytes from 212.58.244.71: icmp_seq=5 ttl=53 time=10.787 ms
64 bytes from 212.58.244.71: icmp_seq=6 ttl=53 time=10.979 ms
64 bytes from 212.58.244.71: icmp_seq=7 ttl=53 time=10.616 ms
64 bytes from 212.58.244.71: icmp_seq=8 ttl=53 time=10.778 ms
64 bytes from 212.58.244.71: icmp_seq=9 ttl=53 time=10.891 ms
--- www.bbc.net.uk ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 10.549/10.825/11.098/0.174 ms
Reverse Ping
PING: 56 data bytes
64 bytes from 81.140.163.177: icmp_seq=0 ttl=49 time=11.081 ms
64 bytes from 81.140.163.177: icmp_seq=1 ttl=49 time=10.987 ms
64 bytes from 81.140.163.177: icmp_seq=2 ttl=49 time=11.564 ms
64 bytes from 81.140.163.177: icmp_seq=3 ttl=49 time=11.057 ms
64 bytes from 81.140.163.177: icmp_seq=4 ttl=49 time=11.016 ms
--- ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 10.987/11.141/11.564/0.214 ms
Hope they help
-
Here are my BT Infinity stats also:
nReturn=0 nDirection=1 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=0 bVirtualNoiseSupport=0 b20BitSupport=0
nReturn=0 nChannel=0 nDirection=0 nNFEC=95 nRFEC=16 nLSYMB=5949 nINTLVDEPTH=251 nINTLVBLOCK=95 nLPATH=0
nReturn=0 nChannel=0 nDirection=1 nNFEC=80 nRFEC=16 nLSYMB=19758 nINTLVDEPTH=933 nINTLVBLOCK=80 nLPATH=0
nReturn=0 nChannel=0 nDirection=0 nTp=59 nMp=1 nSEQ=18 nBP=78 nMSGC=12 nMSGLP=0
nReturn=0 nChannel=0 nDirection=1 nTp=21 nMp=1 nSEQ=10 nBP=63 nMSGC=4 nMSGLP=0
nReturn=0 nDirection=0 nHistoryInterval=0 nElapsedTime=103306 bValid=1 nEftrMin=4294967295 nErrorFreeBits=0 nLeftr=0
nReturn=0 nDirection=1 nHistoryInterval=0 nElapsedTime=103306 bValid=1 nEftrMin=4294967295 nErrorFreeBits=0 nLeftr=0
nReturn=0 nData="5008 0000 0001 0102 "
nReturn=0 nChannel=0 nDirection=0 ActualDataRate=19686000 PreviousDataRate=18702000 ActualInterleaveDelay=800 ActualImpulseNoiseProtection=20 ActualNetDataRate=19686000 ActualImpulseNoiseProtectionRein=0 ActualImpulseNoiseProtectionNoErasure=20
nReturn=0 nChannel=0 nDirection=1 ActualDataRate=62932000 PreviousDataRate=62472000 ActualInterleaveDelay=700 ActualImpulseNoiseProtection=30 ActualNetDataRate=62932000 ActualImpulseNoiseProtectionRein=0 ActualImpulseNoiseProtectionNoErasure=30
TP-LINK(conf)#adsl show info
INDEX=1
{
enable=1
status=Up
modulationType=VDSL2
X_TPLINK_CurrSupportLinkType=2
lineEncoding=
allowedProfiles=
currentProfile=
dataPath=
interleaveDepth=0
lineNumber=0
upstreamCurrRate=19686
downstreamCurrRate=62932
upstreamMaxRate=19320
downstreamMaxRate=71975
upstreamNoiseMargin=59
downstreamNoiseMargin=55
upstreamAttenuation=83
downstreamAttenuation=103
upstreamPower=129
downstreamPower=-13
ATURVendor=
ATURCountry=
ATUCVendor=
ATUCCountry=
totalStart=533512
showtimeStart=409
quarterHourStart=0
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FenaZalZ.jpg&hash=26febf786a84fb7e34bc60f14a070dd6137f1b03)
Does everything seem in order here? To make a long story short I had the full 80mbit for over two years. I recently had lost 10mbit before moving to the TP-Link unit and by the time I had finished setting it up I had lost another 10mbit and my pings have gained 12ms. Interleaving? Can we tell if G.INP is working from my stats?
Yesterday I accidentally forced a reconnect after 5days of being connected with no drops etc. My downstream SNR was jumping between 6 and 6.1, not that it means much to me. I don't have any stats from when I was hitting the full 80mbit either.
Do any projects exist to log this useful info like I see for other devices, pretty graphs and such?
I hope I will slowly creep back up to at least 70mbit, how quickly would/should that happen?
Perhaps I should make a new thread?
-
Obviously there are no guarantees, but, since installing this beta firmware 8 days ago, my upstream speed has gone from 15mb to 19mb and my downstream from 53mb to 66mb, so it's all heading in the right direction for me. I've had no disconnects, uptime keeps going up and the WiFi is stable too.
Fo me, it's all good.
Device Information
Firmware Version:0.6.0 1.10 v0021.0 Build 150409 Rel.40749n
Hardware Version:TD-W9980 v1 00000000
System Up Time:8 day(s) 10:19:48
DSL
Line Status:Connected
DSL Modulation Type:VDSL2
Annex Type:Annex A/B/L/M
Upstream
Downstream
Current Rate (Kbps)
19000
66997
Max Rate (Kbps)
22913
70978
SNR Margin (dB)
8.6
7
Line Attenuation (dB)
18.1
15.4
Errors (Pkts)
0
-
Ohh does this confirm interleaving on my line?
nINTLVDEPTH=251
nINTLVDEPTH=933
Only twigged on when I saw someone mention "interleaving depth".
-
The bReTxEnable=0 indicates G.INP (a.k.a. ReTx) is not in use.
Are you connected to an ECI cabinet? If the output of this command contains IFTN, then that indicates an ECI cab.
/firmware/dsl_cpe_pipe.sh g997listrg 1
ECI cabs haven't had G.INP enabled yet, and when they it it sounds like they will only support G.INP on the downstream (the up to 80Mb part).
-
The bReTxEnable=0 indicates G.INP (a.k.a. ReTx) is not in use.
Are you connected to an ECI cabinet? If the output of this command contains IFTN, then that indicates an ECI cab.
/firmware/dsl_cpe_pipe.sh g997listrg 1
ECI cabs haven't had G.INP enabled yet, and when they it it sounds like they will only support G.INP on the downstream (the up to 80Mb part).
Neat, thanks for the info. Something (I forget, a online checker?) last year lead me to believe I was on a Huawei cabinet with a mismatched ECI modem.
~ # /firmware/dsl_cpe_pipe.sh g997listrg 1
nReturn=0 nDirection=1 G994VendorID=IFTN SystemVendorID=ECI tele VersionNumber= SerialNumber=x SelfTestResult=0 XTSECapabilities=(00,00,00,00,00,00,00,00)
-
@ Licquorice & edjonesy - Thank you, all looks good and no sign of increased latency :)
@ Mooingall, I was beginning to suspect you weren't G.INPed yet, but a I was reading further down the thread, ejs has already picked up on this and helped to confirm you are on an ECI cab
-
It looks as though the beta firmware has been replaced by a stable firmware, dated 07/05/15, I've not downloaded/tried it yet.
description:
New Features/Enhancement:
1.The prefix length of the Static IP of IPV6 now can be changed from 0 to 128.
2.Updated the ISP information list.
3.Improved the performance of Wireless 5GHz in short distances.
Bug Fixed:
1.Fixed the bug that the speed dropped on the BT line of UK when G.INP was enabled.
2.Fixed the kcodes security bug.
3.Fixed the bug that TD-W9980 had compatibility issues with the line of ZEN in UK.
4.Fixed the bug that TD-W9980 had compatibility issues with the line of TALK TALK in UK.
5.Fixed the bug that static IPV6 connection did not take effect after a reboot.
url: http://www.tp-link.com/en/download/TD-W9980_V1.html#Firmware
-
Downloaded and running currently, seems to be very stable. Although SH has now gone so its back to locked down telnet.