Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: broadstairs on October 29, 2014, 01:38:52 PM
-
Decided today to order 38mb FTTC but stay with TalkTalk. That way seemed easier and I hope that the FTTC will be as trouble free as my ADSL2+ service has been. The cost comparison with Plusnet is very similar now and in 12 months when the deal expires, Plusnet is where I was thinking of moving to but since they dont yet do self install and TT do decided to stay put. Yes I know TT upload is only 2mb but I dont do that much uploading, only very small text files from my weather station. The activation day is 11th November. I will initially use my Zyxel F1000 rather than their 'super router' and see how it goes. When I checked my speeds it does not show that I could get anything much faster than their medium speeds so chose not to go large.
Stuart
-
Good luck Stuart. I hope it goes well.
-
Welcome aboard the FTTC Choo-choo train ...... hope it goes as flawlessly as it should do ?
-
With any luck it will just restart on FTTC with the F1000. I already have an SSFP MK3 installed and the router is set for any type of connection so fingers crossed!
Stuart
-
Just for information, in case you were unawares, on the day of the migration you will NOT receive a phone call to inform you the switch is about to take place. This is protocol and is highlighted on the job to, "Not contact the EU".
Just a heads up in case you are working on something important, bidding on e-Bay, booking holidays on-line, etc etc etc ....
-
Just for information, in case you were unawares, on the day of the migration you will NOT receive a phone call to inform you the switch is about to take place. This is protocol and is highlighted on the job to, "Not contact the EU".
Just a heads up in case you are working on something important, bidding on e-Bay, booking holidays on-line, etc etc etc ....
Thanks for the warning, it is doubtful I'd be doing that anyway but will bear it in mind.
Stuart
-
Good luck - Hope all goes well for you :)
-
TalkTalk are not making me believe they know what they are doing.... I had a confirmation letter this morning which said two different activation days in the same letter, in one place it says the 12th and later in the letter it says the 10th of November. Since I cant rely on a broadband service on activation day until it completes I have asked on their forum for clarification.
Stuart
-
Well gone live this afternoon on TT Fibre Medium with d/l speed of 39998kbps and u/l speed of 2000kbps. Initially I put the HG635 on but once I knew it was OK I switched back to the F1000.
Now for TT the settings on Kitz page do not work. I had to set the Encapsulation to IPoE and NOT PPPoE and with this setting there is no userid or password to provide.
Now with that it is all working on the ZyXEL OK. I also have DSLStats running now and for now still uploading to MyDslWebStats. My user name on there is broadstair by the way as it wont allow more than 10 characters so no s!
Stuart
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F141580465223398863214-mini.png&hash=2f56be583fc2653c63e15133e03e270b208817a0) (http://http:http://www.thinkbroadband.com/speedtest/results.html?id=141580465223398863214)
-
Glad it all went smoothly, altgough those nice attainable figures of 86295 & 26062 seem wasted on talk talk.
-
Yay - well done :D
btw - I dont want to rain on your bonfire, but have you noticed that from that TBB speedtest your speed for a single thread seems to be limited to 20Mbps, and it took multiple connections to get the 40Mbps?
I'd keep an eye on that to see if it changes, because atm it means that your real throughput speeds are only 20Mbps. The first set of results should be similar to the 2nd eg
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F141580814685460113928.png&hash=18880d8bd2ee7c21566fd34b91fcf898e766aa4c) (http://www.thinkbroadband.com/speedtest/results.html?id=141580814685460113928)
It could be caused by several things but usually either QoS (ISP traffic shaping), Congestion or MTU
-
I concur with kitz, you want your single threaded performance to be your line speed.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F14158109385635791497.png&hash=4ae1e396a8b50ea8a4bb3de35cf9e79cd80e1eb3) (http://www.thinkbroadband.com/speedtest/results.html?id=14158109385635791497)
-
Yes I did wonder about that myself. I'll do some more tests and also test using TT's own speed tester, still 20mbps is much better than the 8 I was getting.
It was not completely straight forward as the HG635 could not stay because the DDNS wont work, and the F1000 took a while to get to connect as I could not compare the HG635 settings directly with the ZyXEL so it was a guess about the Encapsulation setting.
The F1000 MTU is 1500 btw.
Stuart
-
Just to clarify, Stuart. You are taking TalkTalk's 40/2 Mbps service? :-\
-
Just to clarify, Stuart. You are taking TalkTalk's 40/2 Mbps service? :-\
Yes because I wanted self install and Plusnet are dragging their feet over that. I may go for TTs 80/20 if I decide I want to spend the extra. To be honest we dont do a lot of TV or any movie watching and the largest downloads I do are Linux distros once or twice a year so 80/20 is not really necessary - although would be nice to have ;)
Stuart
-
<b*cat nods in acknowledgement.>
You could, with Plusnet, take the 40/20 Mbps service . . .
I am waiting for a symmetrical offering to become available. ;)
-
Yes I did wonder about that myself.
I'd check again at non-peak, just to make sure its not congestion.. either on the SVLAN or via the ISP.. and also just to make sure that any settings on the TT side have chance to catch up.
However, it should not... and must not stay like that, because it means that if you download a file, or surf or stream HDD, then you are going to be limited to 20Mbps. Whilst I appreciate it may still be more than what you were previously getting.. it means that you are not getting the full amount of what your line is capable of. 20Mbps on a line that should be able to cope with 86Mbps isnt right :/
-
Yes I agree. I've been doing a bit more testing and I get approximately the same download speeds on the TT Speed Tester and I have also tried with a cable direct into the F1000 rather than via my gigabit switch and even on wi-fi and all I get is about 20mbps any way you cut it. In the morning I'll test with the HG635 to eliminate any router settings issues and if I get similar speeds then I'll raise an issue with their support forum. I know both routers sync'd at 39998 kbps. My current SNRM is 18.4db down and 24.3db up. I do wonder if my profile is correct since the max I would have seen on ADSL2+ would be about 20mbps but that does not explain why x6 download on TBB gives me a much higher speed.
Stuart
-
try adjusting the mtu to 1492 as 1500 will only work properly with jumbo frames on pppoe.
-
try adjusting the mtu to 1492 as 1500 will only work properly with jumbo frames on pppoe.
1500 is standard ethernet mtu, it should not require jumbo frames (7500 or 9000 are jumbo frames)
-
Well 1492 or 1500 makes no difference.
I just looked at the logs of the ZyXEL and about every 2 minutes I see a set of entries like this:-
# Time Facility Level Messages
1 2014 Nov 12 21:51:00 PPPoE notice PPP LCP Down. Reason:0 lower down
2 2014 Nov 12 21:50:59 PPPoE notice PPP LCP Up.
3 2014 Nov 12 21:50:59 PPPoE notice Receive PADS
4 2014 Nov 12 21:50:52 PPPoE notice Send PADR
5 2014 Nov 12 21:50:52 PPPoE notice PADO received
6 2014 Nov 12 21:50:51 PPPoE notice Send PADI
Any idea what this means?
Stuart
-
I have this morning tested my connection with the HG635 instead and it made no significant difference to the TBB Speed Test so I have put back the ZyXEL. I have run the TT Speed Tester as well and that show I can obtain a download speed of 29.35mbps but they do not explain what kind of transfer they are using but even on that I still feel it is under performing.
I have created a thread on their forums asking them to take a look. We will see what happens.....
Stuart
-
Netmeter is a good tool to have to measure throughput speeds
http://www.metal-machine.de/readerror/index.php?action=tpmod;dl=item23
Then grab one of the files from TBB http://www.thinkbroadband.com/download.html and watch what Netmeter records for a single thread. Its also useful to monitor bandwidth for such things as HD streaming etc.
Also an excellent site for diagnosing throughput issues is http://myspeed.visualware.com/index.php
Run some of the advance tests such as 'Quality' and it will tell you if it suspects things like MTU or QoS or congestion problems.
-
Netmeter wont be useful for me as I run Linux. Running it under a VM will not be a reasonable test. The visualware stuff seems to show a higher speed download right now giving between 27 and 30mbps.
Stuart
-
ifstat or iftop for linux
-
... or better still, dstat.
-
Interesting a different speed test result using Chrome rather than Firefox....
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F141589475180979657203.png&hash=d087b339016b9ee8c0d8cae9f78a76c4a7ee8557) (http://www.thinkbroadband.com/speedtest/results.html?id=141589475180979657203)
Stuart
-
Just to prove it was not a fluke I have repeated the TBB speed tests on Chrome and then FF and on a sigle download FF gets about 20mbps and Chrome see about 29mbps so it would seem that There is a problem with FF at least on Linux and the TBB speed test (the one using Flash). There is still a difference between the single and 6x tests on Chrome, 29mbps and 37mbps respectively.
While using the HG635 TT want me to turn off the router for 30 minutes and then power it back up to see if it makes any difference, dont see why this might make a difference but hey I'll give it a go...
Stuart
-
I wonder what you might see if you try http://labs.thinkbroadband.com/ispa/ ?
-
See attached image...
Stuart
-
That looks somewhat more acceptable. :)
-
How weird re FF & chrome. I dont see it on Windows, so as you say it may perhaps be a Linux thing. Anyone else on Linux able to check to see if FF does the same thing for them?
=try http://labs.thinkbroadband.com/ispa/ ?
b*cat, do we know if that is multi or single threaded, I cant seem to find anything which says what it is.
The main thing is that Stuarts connection tonight does look much better than last night. :)
The TBB burst x6 from tonight in chrome, would seem to indicate that its not an ISP configuration issue.
Just checking.. Is this a brand new cab? See the waves on the green line could indicate congestion, which could be @ ISP or on the SVLAN.
-
http://labs.thinkbroadband.com/ispa/ ?
b*cat, do we know if that is multi or single threaded, I cant seem to find anything which says what it is.
Unfortunately not . . . I have no idea. The only thing I do know about that throughput tester is that it does not require java or flash plugins.
-
My cab is not a new one, in fact a few weeks ago I could not get FTTC because it needed to be expanded so I guess it does have quite a few users already although I have no idea as to who and what ISPs could be involved. I'm still going to progress it with TT as their speed tester still shows a lower value than I'd expect. Originally the BT site suggested I would see a range of between 50 and 65mbps as a speed so I did expect the 40mbps service to perform better than it does apparently on the TT tester which shows about 27mbps.
Stuart
-
How weird re FF & chrome. I dont see it on Windows, so as you say it may perhaps be a Linux thing. Anyone else on Linux able to check to see if FF does the same thing for them?
=try http://labs.thinkbroadband.com/ispa/ ?
On ADSL FF = 3.21 D 0.36 UP in Mbps.
Chromium = 3.1 D 0.36 Up
Opera = 6.3 D 0.35 Up I have never seen that on my line with 7.8 Mbps peak :hmm:
Konqueror = will not load test !
-
Well this morning I decided to do the TBB speed test using my wife's laptop (wired) which has W8.1 with FF and the results are
x1 avg 32.65 mbps and burst x1 35.29 mbps
x6 avg 39.30 mbps and burst x6 37.06 mbps
Just run the same test on Linux desktop and still seeing the low x1 speed with FF.
So there is something funny happening with FF on Linux with the faster speeds as I did not see this when using ADSL2+ with a sync of around 8.5 mbps, my last result using that was x1 7.32 mbps and x6 7.24 mbps.
It would be interesting to see the results from a FF Linux user on FTTC.
Stuart
-
I just ran the BT tester at http://www.speedtest.btwholesale.com (http://www.speedtest.btwholesale.com) on the Linux desktop and both FF and chrome come up with almost identical download speeds. FF was 33.22 mbps and Chrome was 32.53 mbps.
Stuart
-
No problem with FF on Linux here (but it's version 31.2, so not nearly the latest)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F1415953217329405455-mini.png&hash=1e463142cd841ff6a8fada3084843450ef50b435) (http://http:http://www.thinkbroadband.com/speedtest/results.html?id=1415953217329405455)
-
Well I've been playing some more and tried a fresh and vanilla version of a FF profile. No difference in the TBB speed tester results from their standard flash one as before. If I run their new beta version then I do see the far better results in line with what my wife's laptop reports and the BT Wholesale tester results. So I think that there is something strange either with my version of FF (33.1) or the version of flash which I have installed under Linux.
Stuart
-
Eric looking at your result for speed it is only showing the x6 result which leads me to believe you may be using their new beta speed tester.
I have booted my older F20 Linux system which has FF31 installed and using the TBB flash tester shows the same poor speeds for x1, as does booting F21 beta and running FF 31. The more testing I've done leads me to believe that the problem at least on my system is the TBB flash based speed tester because it seems to fail everywhere I've tried it on Linux using the flash plugin. However Chrome has its own version of flash built-in and using Chrome I get pretty good results. Most other testers I've tried seem to give much better results and I suspect at least some if not all dont use flash.
For now I'm going to leave things alone for a couple of days and let it all settle down as I have been swapping routers quite a lot and I dont want to DLM kicking in.
Stuart
-
Yes Stuart, you're right. I do get a slower result on the TBB Flash test:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F141596323213026452886-mini.png&hash=2473e4504ede0a2d51f3cf45e002d61bb156effd) (http://http:http://www.thinkbroadband.com/speedtest/results.html?id=141596323213026452886)
-
Eric thanks for confirming that. I think I am going to go on the TT forum and explain what I've found and suggest that in future if their users are Linux based they avoid any speed testers which are flash based as the results could be skewed. I just checked and the TT speed checker is flash based and gives me 26mbps so their tester is not reliable on Linux.
Stuart
-
Well Im glad that you found out what it was :)
-
I have updated my thread on the TT forum and one of their reps thanked me for my comments, who knows if they will do anything about it.
Still strange that FF and flash wont work well on Linux. I guess we will never get it fixed since the last Adobe Flash for Linux is V11.2 as they dont support it any more and Windows is now on V15 I believe.
Stuart
-
I opened a thread on the ThinkBroadband forums and one comment from one of the staff there was
OSX flash has an oddity that single thread connection max's out at 12 Mbps.
The HTTPx6 and tbbx1 are using different socket methods in flash, and it is feasible the Linux flash implementation has an issue just like OSX. The OSX one is easy to spot we warn users about.
and since OSX is *nix based it is perfectly feasible that Linux has a similar issue albeit not quite as restrictive.
There was at least two other users who had experienced the problem I had so it is an issue generally in Linux I believe.
Stuart
-
OSX flash has an oddity that single thread connection max's out at 12 Mbps.
Thank you Stuart, I think you may have highlighted and brought to our attenuation, an important fact that Ive not seen mentioned before, but should perhaps be more widely known.
since OSX is *nix based it is perfectly feasible that Linux has a similar issue albeit not quite as restrictive.
Now that you mention it I recall having a conversation last December with someone on Linux who was having the same issue. He thought it may have been MTU, but despite all his efforts couldnt resolve it, so it may be wider spread than we think. Perhaps its not been as noticeable before due to the fact that not many lines had such high speeds to let it be so obvious.
-
Yes I certainly think I had not noticed it on my ADSL2+ 8mbps connection and it's probably likely no one on ADSL lines would see it but get to FTTC and it becomes an issue. It would be interesting to see a single threaded speed test which is not flash driven to compare but I dont believe there are any, at least none I've found.
Stuart
-
This may be interesting. No flash or Java
http://speedof.me/
SpeedOf.Me also downloads large contiguous sample files. This is what you usually do when downloading a webpage or media. This is while other speed test services download small chunks in parallel and do heavy adjustments to calculate your approximate speed.
By contiguous it seems to imply separate files once after another (and not parrallel/multi-threaded], which is what I observed when running it. Seems to work fine for my downstream, but my upstream results are off :/
-
Works fine for me, even upload but then I only have 2mbps up ;)
I'm thinking of trying an upgrade to 80/20 with TT as you can select it to try for 30 days and if then you find no benefit you can switch back.
Stuart
-
This may be interesting. No flash or Java
http://speedof.me/
I have been using that throughput speed tester ever since Eric mentioned it a year, or so, ago.
-
I have been using that throughput speed tester ever since Eric mentioned it a year, or so, ago.
Oops I must have either missed Erics post or forgotten :-[ I found it via google. Ive now added it to the list of Speedtesters (http://www.kitz.co.uk/adsl/speedtesters.htm) on the main site, so hopefully I wont forget again. :blush:
-
No harm done, I'm sure. :friends:
-
This may be interesting. No flash or Java
http://speedof.me/
SpeedOf.Me also downloads large contiguous sample files. This is what you usually do when downloading a webpage or media. This is while other speed test services download small chunks in parallel and do heavy adjustments to calculate your approximate speed.
By contiguous it seems to imply separate files once after another (and not parrallel/multi-threaded], which is what I observed when running it. Seems to work fine for my downstream, but my upstream results are off :/
it claims to be accurate, yet according to that site I Can download faster than my sync speed, and the upload speed maxes out at a very low level suggesting they have the buffer set way too low for fast upload connections.
--edit--
interesting the sendbuffer setting in firefox works for this speedtest.
it was on 65k (the default is 128k) and that gave me approx 2mbit.
at 256k it gave me 12mbit
at 512k it maxes my upstream and I get a result of 18.19mbit.
downstream still is over my sync speed tho :)
default would probably give about 5-6mbit.
-
Now I have got my account sorted with TT (a couple of minor glitches) I have just ordered an update to Fibre Large. Nice thing about TT is that I can try this for 30 days and if it turns out not to be worthwhile I can turn it off again and revert back to Medium. So in a couple of (working) days it should switch me over.
Stuart
-
I hope it goes well Stuart.
-
Well it switched just after midnight and now my sync is 72120/20000 kbps but having run a few speed tests my actual speed is around 44000 kbps down and around 16000 kbps up. My snrm is now 6.4db down and my CRC and ES error rates have gone up from practically zero to an average of 15529 crc/day and 549 ES/day. So unless I can find out what is causing this and find a way of increasing my speeds this experiment will not last beyond the 30 days I have signed up for.
I'll let it settle for today and then tweak the snrm up to see if I can ding a value which maximises speed and minimises errors and only if it ends up much better than I was getting will I stay on this upgrade.
Any advice gratefully received ;)
Stuart
-
Does anyone know if the DSLStats snrm tweak firstly works on the ZyXEL and second if it does then will it work on an FTTC connection. I just tried it but my snrm did not re-sync any differently after trying a +3db increase using DSLStats. Still sitting at 6.4 db with 24 hours average at 22000+ CRCs!
Stuart
-
I don't think that you can tweak the SNRM on FTTC by the normal method. The DSLstats SNRM tweak should work with any compatible modem/router, but not on FTTC.
-
I don't think that you can tweak the SNRM on FTTC by the normal method. The DSLstats SNRM tweak should work with any compatible modem/router, but not on FTTC.
Eric thanks. Do you or anyone else know any abnormal ;) method for doing this?
Stuart
-
Some Broadcom based modems allow you to cap the sync speed I believe, which will cause the SNR Margin to rise
-
Although those with good lines have no issues with the Zyxel, a few of us have trouble with high crc and es with the Zyxel. You can cap the speed with the Zyxel, this helps, but judging by my line not as much as it would with a HG612 or Billion 8800NL. The crc and es rates on my Hg635 are also similar to those of the Xyxel and you can't cap the speed with the Hg635. (You can't see the stats on the HG635 without using a slightly dodgy config file to enable telnet http://forum.kitz.co.uk/index.php?topic=14185.msg273545#msg273545). Generally I use an HG612 with the HG635 connected via its WAN or an 8800NL.
-
You can cap the speed with the Zyxel, this helps, but judging by my line not as much as it would with a HG612 or Billion 8800NL.
Yes but how is the question, I've not found a way using the GUI so is there a command I can issue via DSLStats or telnet to do it.
Stuart
-
Sending the custom commands -- adsl configure --maxDataRate 64030 16030 100000 --- would get you 64/16Mb/s down/up. The 30 is only as I don't like 63998 numbers. On my line just swapping a Zyxel for a HG612 would reduces the ES by /3 and CRC by /10.
-
Sending the custom commands -- adsl configure --maxDataRate 64030 16030 100000 --- would get you 64/16Mb/s down/up. The 30 is only as I don't like 63998 numbers. On my line just swapping a Zyxel for a HG612 would reduces the ES by /3 and CRC by /10.
Thanks I'll give it a try later.
Stuart
-
Query through ignorance :( :) why "adsl configure --maxDataRate..." on FTTC connection?
-
It's intended to reduce the error rate by forcing the connection speed below what it would otherwise achieve. A lower speed will result in a higher SNRM.
(Sorry, I misunderstood the question :-[ )
-
A number of devices have adsl as the equivalent of xdslcmd.
-
Because that particular device has been provided with a software utility which responds only to an adsl invocation. ;)
My Internet access is provided over an ads2+ broadband link. Due to the physical line length it make sense for me to restrict the mode to adsl2 by an appropriate configuration of my modem/router, which is a Huawei HG622. When I access that device via telnet I can issue a whole spectrum of commands and of those commands the most useful ones begin xdslcmd . . .. The Huawei HG622 can be configured to operate in G.Dmt, ADSL2, ADSL2+ and VDSL2 modes. Clearly there was a degree of forethought by the person who originally wrote the firmware so that a generic form of command is available (xdslcmd . . .) rather than a "mode specific" command, like adsl . . ., as used by the Zyxel device. :)
[Edit: Ah, I see that Les was quicker at the keyboard than I . . . ]
-
@broadstairs From mydslwebstats your line is running quite similar to mine and with the Zyxel uncapped you look to heading towards an error rate that will give interleaving very soon. Capping the speed will help and you may be best to do it very soon!!
You may also find, like me, that Zyxel just hates to run at full sync on your line. I sent mine back as it was so much worse than an HG612 that I suspected it be faulty?
-
Well I have run the command and now have a lower sync speed and higher SNRM however the CRCs and Error Seconds are still much higher than I hoped for. My errors running on the 40000kbps sync were almost zero apart from the occasional spike in FECs which I was still seeing (used to get a lot on ADSL2+). However the strange thing (to my mind) is that I am seeing virtually zero FECs even now and prior to issuing the command. The errors are all downstream with zero up stream. Certainly at present I dont think I will continue with the 80/20 but revert back to 40/2 after my initial 30 days.
My ZyXEL is an F1000 with the original firmware on it when I got it here. Right now I'm not for shelling out for another VDSL capable router as the 40/s seemed very stable and was quite fast enough for our use. Maybe in the New Year I might consider a new router when perhaps some of the issues others are seeing have been ironed out, and perhaps the prices might drop a tad.
Stuart
-
Both the HG635 and the Xyxel can used as routers in conjunction with a separate modem in bridge mode. They are both very good that way. if you wanted to persist with 80/20 did not mind a separate modem then shelling out for just a HG612 on ebay might be worth considering. Only the Zyxel and Asus models seem to have issues. The Billion 8800NL seems to just work, but a cupboard full of routers is worth avoiding.
-
Having these issues has prompted me to take a closer look at what all these errors are and when/how they might arise.
One thing I dont understand is the FEC errors in sudden bursts I was getting on medium fibre as interleaving was off, I thought that FECs happened when NOT on fast path. Am I wrong in that assumption? Also although I am seeing CRCs HECs and ESs on 80/20 I dont see (so far) any FECs. All the errors I do see are down with all zeros up.
Also I have taken a look at how far I am from the cabinet No 10 in Thanet it is about 325 metres by probably the only realistic route the cable could take. Assuming this is correct the cable will pass an electricity sub-station some 100 metres before my house so I wonder if this could be a cause of some interference I have been seeing on 80/20 and perhaps the FEC spikes I saw on 40/2?
I do have unlocked HG612 and HG622 somewhere in the cupboard which I could try.
Stuart
-
You can get FECs when interleaving is off. Although we've become accustomed to expecting them to be linked together, they are actually separate items, and on VDSL2 it's quite common to see FECs without interleaving. I get a few myself.
-
Thanks Eric.
I am still in two minds over what to do now. I might dig out the HG622 and HG612 and see how I set them up as modem only so I can still use the ZyXEL as a router, I an also get stats from either as they are unlocked. I'll definitely leave it for now and see how it goes for a few days. The error count now is less than it was and actually using the connection seems fine. In a week or so I might try one of the Huawei routers as a modem and check the difference in error rates. Dont really want two devices but as a test it is fine for a while.
Stuart
-
The HG612 (with the latest unlocked firmware and in the factory default bridge mode with only modems IP changed if needed) can be connected to the WAN port of the Zyxel and would be my recommendation for a later test. The Zyxel is then set to do PPoE and the usual router functions. It is "possible" that this will give a big error reduction if your line is like mine. I am a bit further from the CAB than you ~440m and odd CRC and SES spikes are my problem makers.
-
With ADSL the payload frame contains 2 channels. FAST or Interleaved.
Since 21CN, BT doesnt appear to use the FAST channel (FAST path) at all, and all data within the frame uses the Interleaved channel. (Its up to the Network provider how they construct their framing parameters).
However a depth of 1 interleaving means thats bits are contiguous and not chopped up, therefore almost the equivalent of FAST.
Error Correction (RS Coding) and INP is a separate configuration to Interleaving. Historically if Interleaving was switched on (ie move from fast path to interleaved path), then Error Correction (RS) would be switched on too. With FTTC (and 21CN adsl2+) because all data is sent in the interleaved channel then its possible for the DLM to use INP, Error Correction & Interleaving depth as 3 separate configurations. So you can see Error Correction occur without any changes in interleaving depth.
With FTTC Error Correction appears to occur 'on the fly' & whether its something to do with INP & PhyR - Ive not looked in to.
-
Thanks Eric.
I am still in two minds over what to do now. I might dig out the HG622 and HG612 and see how I set them up as modem only so I can still use the ZyXEL as a router, I an also get stats from either as they are unlocked. I'll definitely leave it for now and see how it goes for a few days. The error count now is less than it was and actually using the connection seems fine. In a week or so I might try one of the Huawei routers as a modem and check the difference in error rates. Dont really want two devices but as a test it is fine for a while.
Stuart
It would be interesting to see a comparison if you do. Not all of us have seen this behaviour. Practically all users of the Zyxel get a higher bit rate (higher sync speed). afaik theres only les... and I think chrys who said there was a slight increase in his errors.
Not all see the increased errors - I certainly dont. In fact when I recently had a line issue when BT mucked something up, I put the HG612 back on for a while, but I soon put the Zyxel back on because the line was slightly better. Ronski's line appears to perform better with the Zyxel - his isnt a short line and its historically prone to getting lots of CRCs.
Ive also got 2 lantiq based routers that perform much worse on my line. Because Ive very recently picked up a x-talk disturber who knocked 5Mbps from my overhead, Ive no doubt that if I put either of those routers on today that Id be able to sync at the full 80/20 - despite me being on an ECI cab. :/
I think it may just be a case of suck it and see as to which router performs best on your individual line :/
PS. The first time I was interleaved was by using one of the lantiq based routers.
-
@kitz Your right to question my view of the Zyxel. You may recall that when I had it, I observed almost the same error rate with as the Hg612 except in what I guess are odd SHINE events when the Zyxel just went crazy but the HG612 showed just a moderate error burst. I concluded that your line was free from SHINE but mine suffered from it making the Zyxel unsuitable. From mydslwebstats broadstairs looked to suffer from similar error busts to the ones I had with the Zyxel. He hit ~600ES in just one hour which had just two CRC spikes -- not good!
-
Thats interesting that you mention SHINE, because at about the same time I picked up the bad disturber, Ive also been seeing periodic bursts of SHINE. :(
My line holds on through these burst of SHINE & although I do get a lot of CRCs, because it is such a short burst fortunately I dont get too many ErrSecs. What is amusing is that its quite clear that my disturber doesnt.... I can tell exactly when his router is switched off or resyncing as my SNRm immediately blips higher as does my max attainable, and both of these figures go back up to exactly what they were before. Its happened too many times now to be a co-incidence.
The last one happened yesterday morning.. presumably it will be evident on MDWS
-
I have never had a resync (except with the Xyxel) on my FTTC line due to errors but the CRC bursts are accompanied by up a hundred or ES, so it must be a persistent thing for a minute or so. The typical timing seems to have moved as it has got darker and I suspect it may be something like big tube fluorescent lights flickering as they take a minute or so to properly start. None in my house though.
I can't see anything on your line re SHINE in the last day or so but I have wondered whether everything get picked up properly for CRC on mydslwebstats. I find that for CRC it does not always seem to quite match the dslststs doing the uploading.
-
I've been watching my errors today and I'm seeing bursts of about 1000 CRCs roughly every 20 to 30 minutes or so with some 45-75 ES per hour for those hours. In between the bursts are some periods of 100-300 CRCs per minute as well. Still zero FECs since I moved to the 80/20 despite seeing some bursts on 40/2!
Stuart
-
On 80/20 you are pushing the line to its limits, so its no big surprise that errors will differentiate between the 2. I'd expect to see more errors whilst on the higher speed product.
Not sure if MDWS is showing the correct information as this looks a bit weird, ie I'd expect the blue line to drop suddenly at midnight, not give that slope - see BaldEagles for comparison. Are you using HG612 stats or DSLstats to upload your linestats?
As things stand and based on that graph it looks like you are remaining under the DLM amount. Its does look like you have SHINE type noise. Interleaving is about as much use as a chocolate teapot when it comes to SHINE because the bursts come to rapid and at a high rate. Its also entirely possible that the noise bursts are occurring at a frequency not used for 40/2 which is why you only see them happen when on 80/20. The higher the frequency then the more susceptible it is to noise ingress.
-
I am using DSLStats. They may look a bit odd as I reset them the other day when I restricted the max sync speed.
Not sure what could be causing my interference as there are no business premises anywhere near me, the likely cable route or cab. The only thing I do wonder about is the substation just down the road (about 100 metres).
I'd love to know if one of my neighbours has errors like mine, he is on the same cabinet and I think FTTC, but I doubt he has any stats available and I would not want to suggest he messes with his connection.
Stuart
Just checked my stats and my CRCs have dropped to under 10 per minute since about 17:10 this evening and my ES rate is now around 20 per hour so something changed but I have no idea what!
-
I am using DSLStats. They may look a bit odd as I reset them the other day when I restricted the max sync speed.
Ive no idea what its recording, but those figures dont look right. MDWS is supposed to reset the totals at midnight but hasnt.. and look how it graphs to a point. It shouldnt do that. [img3]
Then look at how its graphing the past 24hrs [img 2]. Its a smooth increase - more like cumulative figures rather than the peaks and troughs it should be - Compare yours to mine and BE's which gets the figures from HG612 stats.. Im beginning to wonder what info DSL stats is recording and sending to MDWS, because something just doesnt look right. :hmm:
-
I am using DSLstats RPI version to upload stats and it looks ok from my perspective, don't think DSLstats is the cause it must be on the EU's side.
-
Thanks NS for confirming that.
As a test Ive just swapped my logging from HG612 to DSLstats and see what happens for me.. as Im using the same router.
-
Mine looks quite normal too (using DSLstats):
-
That fumy plot occurs when only odd bit of data are uploaded. I used to get plots like that when i did not upload 24/7. bitswaps/min is good to show data gaps. dslststs sseems some times, when a router is swapped or a resync is forced, to need to have the upload option reset and the login info rechecked.
-
Sorry to have confused you all but Newtronstar is correct it was my fault. I am in the process of moving my weather station software from an old W2K and slow AMD processor PC to a spare i5 laptop. As this system runs 24x7 it is where I run DSLStats, as part of the move I stopped the upload and forgot to turn it back on :blush: :blush: There might be a few more interrupts over the coming days as I finish the move but no more than a few minutes at a time while I reboot etc.
So now things should look better in a few days time when it has had time to upload more data.
Stuart
-
I have had just one more thought about my interference. My neighbour at the back has a bank of solar panels on his roof facing us and these generate electicity (not water heating). Is there any evidence that these can cause problems?
Stuart
-
I suppose the inverter could cause noise, but does the interference happen at night or when the sun's in?
-
It sounds quite possible. Solar panels produce DC, so there has to be some sort of inverter to convert it to 230V AC.
-
So far the last spike was about 16:15 by which time I'd guess it is not generating especially today when overcast and raining. The last spike yesterday was about 17:15 or so which was dark as well. Spikes today have been quite frequent but not quite as high as before and the ES levels per hour seem lower as well.
Stuart
-
Well last night there was a spike again around 02:19 of 100 CRCs. This morning the spikes started again around 07:15.
So there is obviously some interference which is causing this but how to find it is the issue. Because of the nature of the spikes it is unlikely I will find anything searching with a radio. I also suspect it is unlikely TT will take much notice of any complaint and will more than likely just say go back to Fibre Medium, although that suffers similar spikes but of FECs not CRCs. I'd be more likely to get it sorted if my neighbours on the same cab were seening this but since none of them is IT savvy it is unlikely they know if they have these errors or not.
Does anyone have any ideas as to how to proceed?
Stuart
-
The possible causes are many and in many locations so unless it is so severe as to cause a disconnect every time it hard to do much, or get much engagement other than to decide on the best speed cap and modem to use with the issue. The evidence suggests that if you keep below 60*24 ES/24 hours all will be OK. A figure of 120*24/hours has been suggested but no one on mydslwebstats gets above 1000ES/day more than once in while as I guess that if you do, an odd bad day or so will get you interleaved. Your current speed cap looks to be helping but, as Kitz commented, comparing with a HG612 would be interesting as the Hg612 might also help.
-
Unfortunately like you say, with SHINE is often very hard to find the culprit and it may not be in your own home. Im getting the odd burst of a few thousand at a time, but because it also frequently knocks out a neighbouring line completely, then I think I can safely assume that its not in my own property and theres nothing much more I can do about it.
Having looked on MDWS and if thats recording the Err Secs correctly then at your current level you should be fine and escape notice of the DLM. The system is built to tollerate a certain amount of SHINE because it doesnt count the CRCs, so its only the Err Secs you need to be aware of. SHINE can rack up lots of CRC errors in a second but the DLM will only perhaps see 1 or 2 Err Seconds per instance.* As long as you stay below the daily quota (believed to be 2880 for 24hrs uptime) then you should be fine.
*Another reason why I dont believe the DLM would looks at FECs, why on earth would it count 1000s of FECs that could be racked up from what could be bouts of SHINE when it ignores the CRCs?
-
I think I'll dig out the unlocked HG612 and put it in to see if it records similar data. I'll try to do that in the next few days.
My stats should be better now on MDWS as it is recording now properly. I'll have to reboot that W7 PC in the next couple of days for parts of my reorganisation but I'll make sure DSLStats starts and continues to upload OK.
Stuart
-
I recommend that, for safety, you view 1440Es/day as the limit before interleaving occurs. As I said no one at all on fast path on mydslwebstats is ever much over 1000ES/day and that make me very suspicious of 2880ES/day. Which is the limit would depend on what option the ISP has provisoned with. I won't believe 2880Es/day until I see a connection running with values between 1440 and 2880 for two days running. I say two days as I don't think the exact timing of the 24 hours is certain.
I think only Ronski has recently transitioned fast/interleaved recently. He went fast path and stayed there for a few days with a high ES but less than 1000ES/day then a odd few hours took him to more than 1440 and also well over 2880 and he has been back interleaved every since. Unfortunately his error burst exceeded all the limits so you can't learn from it. I think he is also on a Xyxel so a test c.f. the HG612 on a line with suspected SHINE other than mine would be really interesting.
-
As I said no one at all on fast path on mydslwebstats is ever much over 1000ES/day and that make me very suspicious of 2880ES/day.
Er... except me possibly, at least eight times over 1000 in the past 10 days max was 1292. I was on interleave for about 30 days and then suddenly went to fast path on 29th Oct and have been there ever since.
-
Yes I should have been more precise than "much over 1000". BaldEagle1 has also almost got to 1200 on an odd day but as I said no one seems to be above 1440 and certainly not for two days running. I only scan though things every couple of weeks so it also easy to miss odd events.
-
I should keep quiet -- most surprising -- some one about to be over 2880 for three days running --see http://forum.kitz.co.uk/index.php?topic=14598.msg275006#msg275006
-
Yes I should have been more precise than "much over 1000". BaldEagle1 has also almost got to 1200 on an odd day but as I said no one seems to be above 1440 and certainly not for two days running. I only scan though things every couple of weeks so it also easy to miss odd events.
1440 = MTBE of 60
2880 = MTBE of 30
The MTBE for adsl = 5
In April 2011 the MTBE supposedly changed from 60/600 and there's possibly been yet another more recent change some time this year.
20311 GEA-FTTC: DLM policy threshold changes for mean time between errors (MTBE).
--
Edit MTBE typo
-
Well this morning I have installed the HG612 and my data from about 07:35 this morning (or a little later after I got the ZyXEL to connect ;) ) should show the stats with this online. So far I am still seeing CRC bursts and the HG612 is sync'd at a higher rate as I have not restricted it like I did with the ZyXEL. I might do this later assuming the xdlscmd works on the HG612.
Stuart
-
The xdslcmd works on the HG612 provied you have the lastest firmware with the 038 dsl driver (the device info page should show A2pv6C038m.d24j under firmware). I notice that you only seem to have lost about 1Mb/s sync relative to the Xyxel.
On my line the Xyxel gave 3 x the ES rate as the Hg612 and a cap of about 8mb/s like the one you used gave an error reduction of /3 on the ES rate. So on my line the test your doing would result in about the same error rate with the HG612 uncapped as the Xyxel capped. I await your result with interest! My big issue with the Xyxel is that it did loose sync with some error burst whilst the Hg612 never did that.
-
I do have the f/w installed so I might try capping later today.
One puzzle with DSLStats is that the average ES is showing zeros for all values, the stats tab shows es/hour as 0 0, but the connection stats does show ES values for downstream. Is this a bug in the f/w or a problem with DSLStats?
Stuart
-
I am not the person to know but I find the average errors since uptime are always correct but the 24 hours figures can have issues. I can't get the "reset values" to work correctly on current versions. The stats zero but the time interval does not seem to reset. I am sure you can always trust the telnet-connection stats page though.
edit -- I would try the HG612 uncapped for a day as long as the errors don't look to be heading too high eg over ~1000/day. That will give proper test against the Xyxel capped which you ran for that long.
-
One puzzle with DSLStats is that the average ES is showing zeros for all values, the stats tab shows es/hour as 0 0, but the connection stats does show ES values for downstream. Is this a bug in the f/w or a problem with DSLStats?
The important thing is whether the ES values in the connection stats change from hour to hour, because that's what the graph, the averages, and the stats summary reflect. If the ES per hour graph shows values but they don't show in the averages or the stats summary, then that could be a bug (although it does take a bit of time after a new start or a new 24-hour period before the averages show sensible values).
-
The important thing is whether the ES values in the connection stats change from hour to hour, because that's what the graph, the averages, and the stats summary reflect. If the ES per hour graph shows values but they don't show in the averages or the stats summary, then that could be a bug (although it does take a bit of time after a new start or a new 24-hour period before the averages show sensible values).
Eric the ES/hour graph shows values for each hour the HG612 has been running as well as totals for the house before I switched. It is just all three average values for ES which are all zeros both down (which does happen) and up (which does not). I did try a restart of DSLStats at around 09:30 this morning but these ES averages are still all zero now at 12:12. I should have pointed out that it is the 24 hour value which is zero, if I select modem/router averages values are shown.
Seems like MDWS is seeing valid ES values when I look at the graphs.
Stuart
-
OK Stuart, I'll check it out. It works properly here, but that doesn't mean there isn't a bug of course.
-
OK Stuart, I'll check it out. It works properly here, but that doesn't mean there isn't a bug of course.
Eric I'm wondering if it has something to do with swapping routers without a completely new setup for DSLStats? I just stopped recording, changed routers and details for login and started it up again.
Stuart
-
Looking at MDWS you may well wish to try the speed cap on HG612 quite soon!! it is probably safer to compare with Zyxel on a like for like speed cap.
Testing with any sort of noise spikes on the line is however always quite difficult as things can vary quite a bit from day to day.
-
Well I just issued the xdslcmd command on the HG612 to cap rates as yes the ES level was increasing. However the CRC rate is not as high on the HG612. Later tonight I'll have to at least reboot the HG612 or put the ZyXEL back as I need to alter where the power plugs are situated (part of my other move round).
Based on what I'm seeing here I might well put the ZyXEL back as capped it does not seem significantly worse. I also have to reboot the PC running DSLStats to finish an install which means a break for a few minutes in the stats gathering.
I have an HG622 plus the TT HG635 I could try however unless someone know how there would be no stats from the TT router.
Stuart
-
Eric I'm wondering if it has something to do with swapping routers without a completely new setup for DSLStats? I just stopped recording, changed routers and details for login and started it up again.
Stuart
Yes, Stuart, I guess that might be relevant. You could try the "Reset values" button on the average errors page. As it happens there will be some changes in that section of the program in the next release, but the version you have should work OK mostly.
-
I have an HG622 plus the TT HG635 I could try however unless someone know how there would be no stats from the TT router.
Stuart
Stats are possible see http://forum.kitz.co.uk/index.php?topic=14185.msg273545#msg273545 . Do however check with shields up that all is in stealth -- that seems to be the only issue. I would recheck with shields up after any reboot. It will at least let you see what happening in a test. The trouble is that I am running the actual unlocked firmware and can't properly test these config files myself.
p.s. It would be interesting to me and others if you could continue with the capped HG612 for long enough to give a proper comparison with the capped Zyxel.
-
Well if my ES stay reasonable I'll leave the HG612 on for now (will have to power it off and on later to move PSU though). I'll have a play with the HG635 later on my laptop prior to testing it in a few days time.
Stuart
-
Hmm . . . If what I post is not that relevant to this thread, perhaps Eric or Kitz would "split it out" and re-home it . . .
On the subject of resetting parameters, the following can be performed on a Huawei HG622, a HG612 & a HG610 as a function of the Broadcom xDSL driver --
# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 1012 Kbps, Downstream rate = 5720 Kbps
Channel: INTR, Upstream rate = 1004 Kbps, Downstream rate = 5494 Kbps
Link Power State: L0
Mode: ADSL2
TPS-TC: ATM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 4.1 5.9
Attn(dB): 46.5 27.8
Pwr(dBm): 0.0 12.8
ADSL2 framing
Bearer 0
MSGc: 39 10
B: 246 46
M: 1 4
T: 1 3
R: 8 6
S: 1.4326 5.9464
L: 1424 261
D: 32 4
Counters
Bearer 0
SF: 11100089 623755
SFErr: 59855 126
RS: 499504027 4254956
RSCorr: 2866291 1471
RSUnCorr: 305492 0
Bearer 0
HEC: 166413 69
OCD: 79 0
LCD: 79 0
Total Cells: 2318416977 423197221
Data Cells: 62050237 3833409
Drop Cells: 0
Bit Errors: 13490197 9921
ES: 3900 95
SES: 1473 0
UAS: 0 0
AS: 178881
Bearer 0
INP: 0.50 0.00
INPRein: 0 0
delay: 11 5
PER: 16.11 17.83
OR: 22.33 7.17
Bitswap: 96237/96354 704/704
Total time = 1 days 1 hours 41 min 37 sec
FEC: 2866291 1471
CRC: 59855 126
ES: 3900 95
SES: 1473 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 15 minutes time = 11 min 37 sec
FEC: 110875 0
CRC: 1379 0
ES: 316 0
SES: 2 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 52680 0
CRC: 643 0
ES: 117 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day time = 1 hours 41 min 37 sec
FEC: 166647 40
CRC: 2072 0
ES: 456 0
SES: 2 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 2660075 797
CRC: 56473 68
ES: 3014 49
SES: 1461 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Since Link time = 2 days 1 hours 41 min 37 sec
FEC: 2866291 1471
CRC: 59855 126
ES: 3900 95
SES: 1473 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
# xdslcmd info --reset
# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 1008 Kbps, Downstream rate = 5780 Kbps
Channel: INTR, Upstream rate = 1004 Kbps, Downstream rate = 5494 Kbps
Link Power State: L0
Mode: ADSL2
TPS-TC: ATM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 4.4 5.7
Attn(dB): 46.5 27.8
Pwr(dBm): 0.0 12.8
ADSL2 framing
Bearer 0
MSGc: 39 10
B: 246 46
M: 1 4
T: 1 3
R: 8 6
S: 1.4326 5.9464
L: 1424 261
D: 32 4
Counters
Bearer 0
SF: 499 409
SFErr: 3 0
RS: 22452 4908
RSCorr: 686 0
RSUnCorr: 6 0
Bearer 0
HEC: 1 0
OCD: 0 0
LCD: 0 0
Total Cells: 104211 19051
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 330 0
ES: 2 0
SES: 0 0
UAS: 0 0
AS: 8
Bearer 0
INP: 0.50 0.00
INPRein: 0 0
delay: 11 5
PER: 16.11 17.83
OR: 22.33 7.17
Bitswap: 5/5 0/0
Total time = 8 sec
FEC: 686 0
CRC: 3 0
ES: 2 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 15 minutes time = 8 sec
FEC: 686 0
CRC: 3 0
ES: 2 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day time = 8 sec
FEC: 686 0
CRC: 3 0
ES: 2 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Since Link time = 7 sec
FEC: 686 0
CRC: 3 0
ES: 2 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
#
-
So far since last night after I had to reboot the HG612 to move the PSU my errors are not nearly as high, so it will stay as it is for a while longer.
Eric - since the router reboot the ES averages are now looking fine so if there is a bug I would guess it was to do with the change of router.
Stuart
-
Thanks for that Stuart. I think (hope) that the next release should clear up the last wrinkles in this section of the program.
-
It would be interesting to have a 24 hour report on the HG612 capped c.f. the Zyxel capped. From MDWS it looks like the ES is similar but the CRC noticeably less?
In capped tests I did get the ES rate on the Zyxel tending to converge towards that on the HG612 with the same cap, but it took about twice the cap you have used to get them as close as yours seems to be. No doubt every ones noise spikes and outcomes will differ though.
-
As of about 10:00 this morning I have put the HG635 back using the config which allows me to get stats from it. We'll see how it goes.
Stuart
-
There doesnt seem to be much difference between the Zyxel & the HG612 on broadstairs line when it comes to E/Secs.
I agree that the Zyxel may have given some more CRCs but from the graphs I wouldnt say its a substantial amount certainly not to the point where the DLM is going to be interested. SHINE can produce different burst levels and vary too much to drawn anything conclusive for example look how much the 26ths and 27ths varied whilst still using the HG612. On the 23rd broadstairs line suffered quite a steep peak burst of CRCs but in all fairness who is to say that it couldnt have happened on the HG612.
You may feel Im being defensive about the Zyxel, but I do feel its totally unfair to compare it with the ASUS - theyre not in the same league. The ASUS has big problems in that its causing most people to be DLM'd.. yet the Zyxel has given quite a lot of people much better line conditions. I'll admit that Zyxel could perhaps be more pro-active with f/w releases, but look at Ronski's line is an example. He suffers from lots of noise yet the Zyxel gives him a higher bit rate and more recently he even had interleaving completely removed. OK it didnt last for long because he suffered a really nasty noise burst which made the DLM take action again.. but since being on the Zyxel - and hes been on it for several months now, he certainly seems to have faired better when it comes to the DLM and bitrate.
Ive got a couple of TPlinks here. My line gets loads more errors using the TPlink and it wouldnt even give me an 80/20 now, it doesnt perform anywhere as good as the BCMs. TPlink sent me another router just to check it wasnt a one off hardware issue, but both perform the same.. yet I still class it as stable because it performs along the same lines as the ECI modem and better than the HH5 when on a BTr line. Most people seem to find that the BCM routers do perform better, yet there is still the odd line which does better with the Lantiq chipset.
On the whole so far, I'd still rate the HG612, the Billion and the Zyxel in the top 3. Id certainly rate the ASUS as the worst... and all the others fall somewhere in between.
-
So far the HG635 seems not too bad with ES for the first hour about the same as the HG612 was the previous hour, CRCs dont look bad but I did just get a spike of FECs upstream which had not happened on either the HG612 or ZyXEL. Bear in mind though this is not running capped as the command does not work on the HG635, unless there is another command hidden somewhere to cap speeds. DSLStats is working well with the config I downloaded from here.
I am thinking about getting a Billion 8800nl but having just tried the 5ghz wi-fi on phone and tablet I'd quite like a dual wi-fi band VDSL router ;)
Stuart
-
Firmware 2144 on the ASUS DSL-AC68U has been an improvement however, at least for me and some others on another forum. ASUS haven't abandoned the device yet, which is good. It's just a matter of whether they can truly clear a majority of the errors or whether some of it is either related the chipset or something else such as the switching power supply creating noise. I've ordered myself a pack of 10pcs of clip-on ferrite beads which I'll be attaching to switching power supply cables (e.g. for my cordless phone hub, my switch and finally my two routers).
-
Thanks Ixel. In all fairness ASUS does seem to have been pro-active and do seem to be rolling out - although irrc the last post I read was from someone who said ASUS hadnt answered for a while, so I guess I need to catch up whats been happening more recently.
The problem with a lot of the combined units is that none of them have really been out that long and at first they were far too expensive for most people to be able to afford to buy their own. Its only this year that prices seem to have come down. Ive no idea why the manufacturers were so slow to bringing a unit to the market. Whether it was because they thought BT had it stitched up with the Openreach modems Ive no idea. Whatever the reason, this year several of the main manufacturers have released a model, but unfortunately most of them never appear to have ever been beta tested on Openreach FTTC lines before release.
All models (save the Zyxel SBG3300-N and Billions) seem to have had some form of teething problems that were f/w related and indicative that they'd not been tested properly on a BTline before release. Im not including the HG612 in there, because its modem only... and the fact Ive no doubt it will have undergone the intensive testing with BT before they started using it... so any major problems should have been pre-ironed out.
-
There is the http://www.broadbandbuyer.co.uk/products/20044-billion-bipac-8800axl/ but I suspect you won't be a lot better off than with one your current options. I have found that in general the 63168 chipset devices all seem more SHINE- CRC burst prone than the HG612. I have tried the Xyxel Billion 880NL and HG635. I also bought in one cheap lot an HG630 and HG658 and they are similar in that respect. I am 80% confident that my Xyxel was faulty as it was so much worse and the only one prone to actual disconnects. I say 80% as it may not have been faulty but simply much worse for the type of errors on my particular line.
-
Its a shame les if it was faulty. As you know Ive always been quite pro-active in trying to show my own errors etc in an attempt to get to the bottom of it.
I dont doubt you in that it did perform worse on your own line and I would love to know if it was a fault with the VMG8324 model or if it was a one off, or if for some reason it just didnt like your line conditions. I'm happy to admit that it may produce more CRCs on some lines, but it doesnt seem to affect E/S which are the important ones. Without doubt it does seem to give a higher line rate which may benefit those who want to cap. The only other thought is perhaps in some way it doesnt respond to rate capping as good although I cant suss out how or why that should happen.
Im quite open about the fact that the GUI is buggy and Im not chuffed now that theyve limited the telnet sessions, but on the whole as far as line stability goes Im very happy with mine, and most of its features. They still have work to do on the GUI, but most of it doesnt affect me and Im stable on v4.
Im also well aware that some routers just simply dont like certain types of lines. The worst router Ive ever had on my line was one of the 2Wire 2700's which work brilliantly on long lines, yet they were rubbish for short lines.
-
I would also love to know if it was really faulty or not -- there is no way of really knowing unless you have more than one them. On my line in a four hour period the Xyxel ES rate went over a few thousand causing a week or so interleaved. A lot lot more ES than other modems. I did wonder if it was a one off event while uncapped. Subsequent tries uncapped were less extreme but at least 3-5 times the HG612 ES error rate and most disturbing were actual disconnects. A cap to a sync of 8mb/s below the Hg612 seemed to give me no disconnects and the same ES rate as the 8Mb/s faster Hg612 but still lots more CRC. I am not sure how harmless those CRC are as they gave lots of SES which it seems may be counted in some way. My guess was a duff input stage as digital things seem more yes and no. I sent Zyxel stats showing both the VMG8324 and HG612 -- they agreed it was clearly not right and indeed suggested a replacement rather than firmware. By then I had lost interest in messing with it and I was given the refund instead. My one off experience is definitely not a reason to put others off but I think anyone with SHINE events may wish to just be cautious.
The Billion 8800NL has been so much better for me. Still a bit higher ES and CRC than the HG612 but just a bit and with good wireless and Ethernet throughput and so easy to use as to be boring. The loss of all gigabit is the drawback for some but not a worry for me.
-
@broadstairs It may be time to stop the HG635 test, you seem to be getting some big error spikes with plenty of ES. As I noted I found that the HG635 gave noticeably more errors than the HG612 and you can't cap the speed with the current firmware. I don't think the HG635 is SHINE friendly! I only run it from time to time doing ppoe in conjunction with the HG612 so i don't miss any 1.06t updates that as supposed to happen soon. In that mode you don't need telnet access.
Do you have proper figures re capped Zyxel vs. capped HG612. As Kitz noted the ES look similar and CRC may not matter on their own but it would interesting to compare the SES rates.
-
I decided what the hell let it run and the spikes of ES have gone down again. I might let it got for a few days and see what happens. If I get DLM'd the I might complain to TT ;) I have remote management turned off at the moment so I guess I wont get 1.06 f/w.
Did you know about these hidden pages on the HG635?
http://192.168.1.1/html/advance.html#parent_control
http://192.168.1.1/html/advance.html#qos
http://192.168.1.1/html/advance.html#iptv
http://192.168.1.1/html/advance.html#diagnose_overview
Not sure what use they are though!
Stuart
-
TT won't remove interleaving but it may go away after using a speed cap. I would take out !!
from your tests I would say your best options are:-
1. Zyxel capped -- the simplest choice
2. HG612 capped with Zyxel or Hg635 in ppoe mode. Hg635 if you want 5ghz
With 2. and the HG635 the 01 config file has a fibre modem connection set up for this if you select fibre rather than dsl. You may want to look at that setting but there is no point in using one of my config files while in ppoe mode as you won't need to access the HG635 itself for stats. The HG635 will update as normal in the ppoe mode. I use the Hg635 that way myself. So if you wanted you could retry it on "dsl" with a config file after it has updated
The hidden pages seem to be used by some people but it depends on whether they are useful to you.
-
I have put back the HG612 now capped in conjunction with the HG635 as I quite like 5ghz wi-fi.
I'd love to get a handle on what is causing the errors. There must be something which is doing it but how to find it is the issue.
Stuart
-
Once you eliminate SHINE event sources in your house there is not much that it is possible to do about it. I don't think Openreach will engage such things unless the events are both frequent and severe enough to cause disconnects. I have reduced the impact by using filters and a BT main conditioner but I have only reduced it - it is still an issue.
if you have left my config file in please always do a shields up now and after any setting change. Adding new wan connections or changing the primary IP both seem to be possible causes of port 23 opening. I really do not want to be blamed for causing someone to be hacked.
-
Depending on the source of your noise you may find it is a lot worse at weekends. Sometimes I get very bad Saturdays. Your downstream speed cap may not be quite enough if the TT provisioning DLM setting is only for up to 1440 ES/day on fast path. It is a shame that TT use 40/2 and with 40/10 your long term choice would be easier.
edit Have you done anything else - given the speed cap things are really looking quite a lot worse.
-
given the speed cap things are really looking quite a lot worse.
It looks like things started to rise sharply after about 11am yesterday (from what I can see on the graph) which will be after broadstairs put the HG612 on with the HG635. Yesterday afternoon early/evening there seemed to be a couple of quite bad spats of CRC's - the worst he's had so far. Yet the line is still capped and those Err Secs are continuing to rack up today :(
Edit - Perhaps not.
For a time yesterday the line ran at 70911 which I presume is the HG612 running uncapped.
The last time the line had a spat of CRCs like that was last Fri when the the line was running at 72661 on the Zyxel. I'd said earlier in the thread that the spat last Friday looked like a particularly bad burst which could have happened regardless which router was on the line, so Les may be on to something in the fact they could be worse on certain days.
In general though the Err Secs today are still continuing to rack up despite the cap and the CRCs appear to be worse than when the Zyxel was capped last w/e at the same rate. :/ This could possibly be because the Zyxel gives a slightly better bit rate, and therefore it should have more spare SNR margin to play with as a buffer.
-
OK lets set the record straight. The HG635 was connected on its own until about 10am today when I switched on the HG612 and still use the HG635 via its WAN connection. My ES were not too bad from midnight till 6am this morning with ES/hr less than 20, then from 6am it started to climb 6 to7 was 90 - 7 to 8 was 185 - 8 to 9 was 105 - 9 to 10 was 78 (approx values from DSLStats graph ES/hr). Since putting the HG612 back around 10:15 ish the ES/hr have been around 60 to 90. My CRCs have been very bad today since the HG612 went on starting around 10:58 with several bursts of 700+ and a couple of 1000+ currently DSLStats is suggesting a 24 hour average of 86000 CRCs with an hourly average of 3400 (using the modem uptime averages as the HG612 has only been on for about 6 hours).
So today is looking very bad but nothing significant has changed in the house. I have done a scan of the room where the routers are with my radio scanner tuned to 612 AM band but nothing found unless the aerial is actually within a couple of inches of two PSUs (The HG612 one and the HG635 one!) and then the noise is not loud. Next is to scan the house but as I said everything we are using is what we always use nothing new of different.
Stuart
-
Very annoying for you today. You could try the Zyxel capped just to see if it is better, from the last test it should be much the same as HG612 when capped the same. Noise can also come and go, upsetting comparisons, and slowly or quickly drive you nuts. :'(
-
^ Agreed.
I think as you say its a shame TT dont do an 40/10. If it was me, I'd probably just put the Zyxel on and leave it capped, but since the HG612 is on at the mo, I'd certainly leave it alone for today at least.
SHINE is a PITA and ultimately much harder than REIN to track its source because its so intermittent. I gave up on my parents connection and since they moved ISP anyhow they dont even notice the DLM because they are getting better speeds than previous. I decided its not worth the hassle and they seem happy enough now that they can at least stream properly.
Its up to broadstairs and how much he likes tinkering, but he will at one point have to decide whether he wants to keep the 80/20 capped at 65Mb.. or if he wants to go back to 40/2. In the meantime I prescribe some time for broadstairs to enjoy the speed uplift and go take advantage of it :)
-
I think for now I'll leave the HG612 in place maybe put the ZyXEL back tomorrow. If I do anything today it would be to lower the cap.
Just been round the kitchen with the radio scanner - zilch. The only other thing running right now is the TV in the conservatory but more than my life is worth to go scan that area right now as Mrs Broadstairs is watching a film!
Stuart
PS I like tinkering Kitz ;)
-
Lowering the downstream cap to 60 could be very wise re the DLM. You could leave the upstream at any value you liked as it does not seem to need the cap. You have not changed/swappped PSU's or cables have you? Although days can be different todays just looks so different for you as to be odd.
-
In light of all the ES today about an hour ago I capped it at 55000kbps down and let up go to 19998kbps. There it will stay for now and we'll see what tomorrow brings.
Stuart
-
Not good this morning :( !! I am surprised as you seem to have had 1255 ES/day and below 1440 ES/day. Maybe the exra was provided by a SES count, With some of the CRC peaks you must have had SES.
I did comment that if BT do their own DLM you can more or less be sure it will see a lot more people interleaved - it reduces complaints about drops drop out and resyncs and most people just don't notice. A new DLM may or may not also be an issue.
If the limit still is 1440 and SES were not counted then it is also possible that the time frame is midday to midday or perhaps you had some missing samples during the day. Midday to midday would put you over 1440 and include I think 4 resyncs. I notice that Baldeagle is still OK at ~1100/day but maybe with no or few SES.
-
My ES/hr since I dropped the cap to 55000kbps has been less than 20 and since midnight has been less than 11. However this morning I find I am interleaved so whether that was the ES/hr of CRCs or the re-syncs I dont know. My CRCs are low as well now but my FECs have gone up significantly with peaks over 2000/min, that started around 4am which I guess would be when interleave was turned on. Just had one peak of 7200 FECs/min.
Stuart
-
As I commented above it is a bit a puzzle -- do you have any idea how many SES you had yesterday? I am also with TT and have no trouble with 4 resyncs a day. I try to limit it to that but I am sure i gone to 5 with nothing happening.
edit If you leave it capped at 60 or below with either the Xyxel or the Hg612 it ought to recover fast path. It is also worth seeing if you really notice any impact from interleaving in normal use. If you don't you could just un cap and let the DLM do its job.
-
SES is currently showing 94, I'm assuming this is since router was put back just over 24 hours ago. A previously saved snapshot of the text file showed 373 SES just prior to the HG612 being put back, so that was the HG635 running on its own, therefore the current value is indeed since the HG612 was put back on.
Stuart
-
I am not aware of any info how SES are counted other than that they probably are. Your SES count is high, especially with the HG635, even it was just added to the ES count that might have put you above 1440. There may be a separate counter for SES but I would guess (only a guess) that a multiple of the SES count is added to ES count. On lines without SHINE type events SES are quiet rare. The multiple might be a value like 10 or more as a SES event is certainly much more note worthy than an ES which might just be one CRC.
My condolences, I guess it is not much fun having what other might regard as interesting events.
-
There may be a separate counter for SES but I would guess (only a guess) that a multiple of the SES count is added to ES count.
There is a separate counter for SES & ES that are recorded for the DLM calculation, but the MTBE only uses one parameter when calculating 'Errors'. Based on that info, I too would speculate that a multiple of the SES count is added to the ES as it would seem the most logical way to do it.
Also if theyre only a slight bit out, dont forget it also uses uptime count. Therefore if the day hasnt had a full 86400 seconds of uptime then it will take less errors on the MTBE calculation to trigger the DLM. Broadstairs was swapping routers so there will have been at least some downtime and not a full 86400 seconds.
-
PS @les
Did you notice that the DLM has gone straight to 1167 for the Interleaving depth. Normally we'd see at least 2 steps before going in that hard.
This only appears to have started yesterday and as discussed here (http://forum.kitz.co.uk/index.php?topic=14738.15).
-
Well I'm not going to touch anything for now. My ES and CRC counts are now quite low compared to what I was getting although FECs are high. Any interrupts now will be out of my control. Hopefully it will be quiet enough in a while for it to get me off interleaving. I'll leave the cap at 55000kbps down which now sees about 47500kbps download speed, still faster than I was with 40/2 and loads faster than ADSL2+ at about 7500kbps.
Hope to see TT update my router F/W soon. Also while I'm waiting for all this I will update my laptop wi-fi card as it is only 2.4ghz ;)
Stuart
-
Interleaving depth can vary depending on sync rate, the INP and delay (and possibly another value I've forgotten). I feel that observing the INP and delay have more meaning than the interleaving depth value, but I guess that's personal preference :P.
-
I agree :)
... but Im just working from figures provided from MDWS which doesnt record delay... & why I work with whatever s available ie depth. The highest level Ive seen is normally somewhere around the 1200 mark, theres several other steps another one around 600 but as you say they will vary depending upon sync speed.
-
Currently INP is 3.5 and Delay is 8.
Stuart
-
I agree :)
... but Im just working from figures provided from MDWS which doesnt record delay... & why I work with whatever s available ie depth. The highest level Ive seen is normally somewhere around the 1200 mark, theres several other steps another one around 600 but as you say they will vary depending upon sync speed.
Although there are no graphs, you can get the current values for both INP and Delay in one go from one of the two All User Stats listings.... It would be possible to graph them both (probably on one graph) but would need to index them on the database sometime... There are 145 individual items/columns of data available to play with if one had the time :'(
-
you can get the current values for both INP and Delay in one go from one of the two All User Stats listings
I didnt realise they were in that section so thank you for letting me know.
I dont think it is something that we normally take a too much notice of, its only really this past week with the BT/ASSIA thing and the usual process seeming to have changed a little that we are possibly scrutinising such things more closely.
-
There doesnt seem to be much difference between the Zyxel & the HG612 on broadstairs line when it comes to E/Secs.
I agree that the Zyxel may have given some more CRCs but from the graphs I wouldnt say its a substantial amount certainly not to the point where the DLM is going to be interested. SHINE can produce different burst levels and vary too much to drawn anything conclusive for example look how much the 26ths and 27ths varied whilst still using the HG612. On the 23rd broadstairs line suffered quite a steep peak burst of CRCs but in all fairness who is to say that it couldnt have happened on the HG612.
You may feel Im being defensive about the Zyxel, but I do feel its totally unfair to compare it with the ASUS - theyre not in the same league. The ASUS has big problems in that its causing most people to be DLM'd.. yet the Zyxel has given quite a lot of people much better line conditions. I'll admit that Zyxel could perhaps be more pro-active with f/w releases, but look at Ronski's line is an example. He suffers from lots of noise yet the Zyxel gives him a higher bit rate and more recently he even had interleaving completely removed. OK it didnt last for long because he suffered a really nasty noise burst which made the DLM take action again.. but since being on the Zyxel - and hes been on it for several months now, he certainly seems to have faired better when it comes to the DLM and bitrate.
Ive got a couple of TPlinks here. My line gets loads more errors using the TPlink and it wouldnt even give me an 80/20 now, it doesnt perform anywhere as good as the BCMs. TPlink sent me another router just to check it wasnt a one off hardware issue, but both perform the same.. yet I still class it as stable because it performs along the same lines as the ECI modem and better than the HH5 when on a BTr line. Most people seem to find that the BCM routers do perform better, yet there is still the odd line which does better with the Lantiq chipset.
On the whole so far, I'd still rate the HG612, the Billion and the Zyxel in the top 3. Id certainly rate the ASUS as the worst... and all the others fall somewhere in between.
Agreed, although I think the zyxel has some issues, as you said the issues are not even close to the asus which seems a train wreck of a device.
I love my billion, stable fast firmware, and can even now collect stats using the WAN cable so no 2nd cable needed.
The zyxel syncs higher than the billion but on certian lines may have a higher error rate and some of the firmwares are flaky. Also as a router the zyxel is a better spec than the 8800nl.
The hg612 is the cheapest (or even free if openreach gave you one) and remains a solid choice.
-
Well yesterday I had the f/w update on my HG635 which then had a problem where it lost my manual DHCP DSN server settings. Today I have been put back on Fastpath but this caused a drop and reconnect of my HG635 which again lost my DHCP DNS settings. I did report the problem to TT but as yet have had no response from their Forum. When I get a response I will tell them it is an ongoing issue, trouble is if I update the forum thread now it will go to the bottom of the pile!
Stuart
Just remembered I could edit my post on the TT forum without it changing my place in the queue!
-
If your using the automatically provided DNS from TT? -- it may better to manually configure the DNS in the DHCP settings on the HG635.
-
If your using the automatically provided DNS from TT? -- it may better to manually configure the DNS in the DHCP settings on the HG635.
I have configured my required DNS server settings manually, that is the issue here it is this manual setting of the DNS server which gets deleted the setting is still selected but the server addresses are blank.
Stuart
-
Hmm - not good.
Did you try a full reset as if your only using it a router and not a modem you don't need to have the telnet config file present. There does not seem to have been any update on the dsl side of the firmware so after errors you had in your last full modem +router try, I would recommend, that like me, you hesitate from using it again as modem.
-
Well yesterday I had the f/w update on my HG635 which then had a problem where it lost my manual DHCP DSN server settings. Today I have been put back on Fastpath but this caused a drop and reconnect of my HG635 which again lost my DHCP DNS settings. I did report the problem to TT but as yet have had no response from their Forum. When I get a response I will tell them it is an ongoing issue, trouble is if I update the forum thread now it will go to the bottom of the pile!
Stuart
Just remembered I could edit my post on the TT forum without it changing my place in the queue!
One other tip when using the TT forum is lock your own post. That way it stops any "me too" posting by other users which would then send your post to the bottom of the pile.
-
One other tip when using the TT forum is lock your own post. That way it stops any "me too" posting by other users which would then send your post to the bottom of the pile.
Yes I've done that in the past too. However I've just checked and that option seems to have gone awol!
Stuart
-
From MDWS you look to be running along quite safely re errors at the moment. You could probably run at 60/20 without getting too many more errors. If the TT limit for fast path is 1440ES/day anything around or a bit less than 720ES/day is probably optimum for your line in terms of errors/vs sync speed. However I must admit that without doing speed tests I would find it almost impossible to tell the difference between say 50 and 70 Mb/s.
-
Yes it is looking not bad now. What I might do is to take down both HG635 and HG612 at the same time so I can do the f/w downgrade to 1.04 which seemed , at least for me, not to exhibit the DHCP problem, plus when I re-sync I can up the speed on the HG612.
Stuart