Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Blackeagle on April 05, 2012, 12:42:00 PM
-
So, this is probably the last speedtest I'll be doing on my ADSL2+ line.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F1876755497.png&hash=8362625c674ef7c70404fe4519e1fcb70d47f050) (http://www.speedtest.net)
I'll post a test on VDSL later after the engineer has gone. The appointment slot starts in 30 mins (at 1 o'clock) but could be anytime upto 6.
A couple of ping tests as well.
C:\Users\Blackeagle>ping www.bbc.co.uk
Pinging www.bbc.net.uk [212.58.246.91] with 32 bytes of data:
Reply from 212.58.246.91: bytes=32 time=46ms TTL=53
Reply from 212.58.246.91: bytes=32 time=45ms TTL=53
Reply from 212.58.246.91: bytes=32 time=45ms TTL=53
Reply from 212.58.246.91: bytes=32 time=46ms TTL=53
Ping statistics for 212.58.246.91:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 45ms, Maximum = 46ms, Average = 45ms
C:\Users\Blackeagle>
C:\Users\Blackeagle>ping www.google.com
Pinging www.l.google.com [173.194.67.105] with 32 bytes of data:
Reply from 173.194.67.105: bytes=32 time=50ms TTL=46
Reply from 173.194.67.105: bytes=32 time=49ms TTL=46
Reply from 173.194.67.105: bytes=32 time=49ms TTL=46
Reply from 173.194.67.105: bytes=32 time=49ms TTL=46
Ping statistics for 173.194.67.105:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 49ms, Maximum = 50ms, Average = 49ms
C:\Users\Blackeagle>
My current line stats are (after a powercut the other night)
Link Information
Uptime: 1 day, 7:49:17
DSL Type: ITU-T G.992.5
Bandwidth (Up/Down) [kbps/kbps]: 1.003 / 8.779
Output Power (Up/Down) [dBm]: 13,1 / 0,0
Line Attenuation (Up/Down) [dB]: 19,5 / 37,0
SN Margin (Up/Down) [dB]: 9,0 / 8,8
Vendor ID (Local/Remote): 544D4D42 / 2D2D2D2D
Loss of Framing (Local/Remote): 0 / 2.147.480.000
Loss of Signal (Local/Remote): 0 / 2.147.480.000
Loss of Power (Local/Remote): 0 / 2.147.480.000
Loss of Link (Remote): 2.147.480.000
Error Seconds (Local/Remote): 518 / 2.147.480.000
FEC Errors (Up/Down): 2.342.433 / 4.294.967.264
CRC Errors (Up/Down): 873 / 2.147.480.000
HEC Errors (Up/Down): 0 / 0
Current graphs from my line. These are hosted on my server so will be unavailable during the changeover period.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fblackeagle.no-ip.info%3A81%2Fstuff%2FRx_Noise_margin_%28dB%29.jpg&hash=3f0e618e8a7145981406c1f5d67ff360f3b08c10)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fblackeagle.no-ip.info%3A81%2Fstuff%2FBits.jpg&hash=c887c23b151d29c7ac55dfd17d9cc6a77f2c07d3)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fblackeagle.no-ip.info%3A81%2Fstuff%2FBitswaps.jpg&hash=48eab1bb0ad0e1c99b029f6b7c65f611236c9461)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fblackeagle.no-ip.info%3A81%2Fstuff%2FBitswaps-Time.jpg&hash=45d5f7da55176906c7bad63a68126149562a5eb0)
-
OK, so engineer has been and gone.
First thing, its the damn ECI modem, so no stats there for me :no:
Secondly, the engineer said that there were quite a few RS errors showing on his JDSU and that DLM would already be slowing down the line from his initial connection which synced up at 37Mbps. He tried to do some tests but said that BT's system was unavailable today and that he had been unable to use it all day !! He did however mention that my copper is quite noisy (which I already knew) and told me which CAB I am connected to. I was suprised to find it wasn't the one I thought it would have been, and he said that he was suprised as well, as he had originally gone to the one I thought it would have been. The other cab (that I am connected to) is in totally the opposite direction to the exchange and further away from my house too :'(
Anyways, speedtest from around 15 minutes after initial JDSU connection.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fspeedtest.net%2Fresult%2F1876891125.png&hash=aeb4994c57b64265793cac9f433d497179e6e152)
Original speed estimate was 33Mbps but he said it was more likely that it would settle around 30, judging by his stats. He did show me his JDSU but wouldn't let me photo it.
-
:thumbs: Congratulations.
:fingers: for you. I would get that noisy line seen to - call the "voice" side of BT and complain, not the broadband side.
Colin
-
OK, so engineer has been and gone.
First thing, its the damn ECI modem, so no stats there for me :no:
Once your line has stabilised, perhaps you could source a Huawei HG612 to use whilst you loan your ECI B-FOCuS modem to The Maestro, Asbokid, himself for forensic examination? :-\
-
OK, so engineer has been and gone.
First thing, its the damn ECI modem, so no stats there for me :no:
Oh, that's a shame.
You may be able to pick up a HG612 from ebay at a reasonable price?
Maybe the ECI isn't too far away from being made accessible. A few people appear to be having a dabble with it.
Secondly, the engineer said that there were quite a few RS errors showing on his JDSU and that DLM would already be slowing down the line from his initial connection which synced up at 37Mbps. He tried to do some tests but said that BT's system was unavailable today and that he had been unable to use it all day !! He did however mention that my copper is quite noisy (which I already knew) and told me which CAB I am connected to. I was suprised to find it wasn't the one I thought it would have been, and he said that he was suprised as well, as he had originally gone to the one I thought it would have been. The other cab (that I am connected to) is in totally the opposite direction to the exchange and further away from my house too :'(
Anyways, speedtest from around 15 minutes after initial JDSU connection.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fspeedtest.net%2Fresult%2F1876891125.png&hash=aeb4994c57b64265793cac9f433d497179e6e152)
That's still quite an increase on your previous connection.
Ping looks a little high, but DLM might settle down after a while of (hopefully) connection stability & let you have a bit more speed, maybe also reducing Interleaving/delay etc.
Original speed estimate was 33Mbps but he said it was more likely that it would settle around 30, judging by his stats. He did show me his JDSU but wouldn't let me photo it.
Working your speed test backward & assuming no congestion, 19.24Mb throughput would suggest a sync speed of around 31Mb, so not a million miles off the estimate.
I don't suppose you managed to jot down any of the stats, including line length................?
EDIT:
Of course I meant to type 29.24Mb & not 19.24Mb.
(Damned keyboard)
-
Once you line has stabilised, perhaps you could source a Huawei HG612 to use whilst you loan your ECI B-FOCuS modem to The Maestro, Asbokid, himself for forensic examination? :-\
Indeed. I am watching one currently ;)
That's still quite an increase on your previous connection.
Ping looks a little high, but DLM might settle down after a while of (hopefully) connection stability & let you have a bit more speed, maybe also reducing Interleaving/delay etc.
Working your speed test backward & assuming no congestion, 19.24Mb throughput would suggest a sync speed of around 31Mb, so not a million miles off the estimate.
I don't suppose you managed to jot down any of the stats, including line length................?
No, sadly not although I do remember my downstream SNR was 6.2dB and capacity was at 100%
It is much faster than I have ever had before but obviously one likes these things to be as highly tuned and as fast as possible.
:thumbs: Congratulations.
:fingers: for you. I would get that noisy line seen to - call the "voice" side of BT and complain, not the broadband side.
Colin
Thanks Colin. I don't think there is much point trying to do anything about the noise on the line. Its not evident on the voice part of the spectrum at all as its in the higher frequencies. On my ADSL graphs you could clearly see it above tone 315.
I have to say, after years of monitoring my line, its absolutely frustrating to not even be able to see my sync speed, let alone any other stats. Grrrrr.......
-
I have to say, after years of monitoring my line, its absolutely frustrating to not even be able to see my sync speed, let alone any other stats. Grrrrr.......
Especially for anyone who might get a bit OCD over it.
It's a good job I'm not like that :-[
Do you have a rough idea of the line length to the cab you ended up being connected to?
-
Yeah, 650m give or take 50m either way.
EDIT - Just done this at BT
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs19.postimage.org%2F7h233fs5f%2Fbtspeedtest1.png&hash=d08890dd7a0daa3899fc0aaf1a71c0c1427ad56a) (http://postimage.org/)
Compared to
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F1877606905.png&hash=9c97753690e431d53b821deaa40a9d8af29dd9aa) (http://www.speedtest.net)
-
Yeah, 650m give or take 50m either way.
Hmmm,
Seems like the noise issue (above tone 315 on ADSL) is actually in the D-side part of the line then.
Was it ALWAYS evident, or perhaps only at certain times of day?
-
It was more evident in the evening, especially if I had to re-sync for some reason. This graph shows it quite clearly, and is from this mornings grabs. My router re-synced during the night after we had a powercut a couple of days ago.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs19.postimage.org%2F4crf6nbcz%2FBits.jpg&hash=0f4d9c995174842e83eb535172ca1bb092b2ce40) (http://postimage.org/)
If I had resynced in the morning between say 7-9am, it would have tailed off much more smoothly, instead of suddenly cutting off. I may have a graph still of it like that, I'll have a dig around.
EDIT - Found one. Not brilliant, but better than the first !
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.talktalkmembers.com%2Fforums%2Fattachment.php%3Fattachmentid%3D6758%26amp%3Bd%3D1331930790&hash=e61b3e743965821936d2b3dd7e1cc441c15565dd)
-
I may have a graph still of it like that, I'll have a dig around.
EDIT - Found one. Not brilliant, but better than the first !
What is it with B*Eagles & graphs?
-
What is it with B*Eagles & graphs?
No idea bud !! ;D ;D
-
What is it with B*Eagles & graphs?
<Cough> (Yet another fur-ball!) Could the phrase "bird-brain" be significant? :P
-
I received a Huawei HG612 yesterday from a seller in the a very similar location with exactly the same description and name. Coincidence?
Anyway, the modem was brand new and it works perfectly. If it helps, it has SP10 firmware and it is a 3B hardware revision.
Here is the link to the modem I purchased: http://www.ebay.co.uk/itm/251031496766?ssPageName=STRK:MEWAX:IT&_trksid=p3984.m1423.l2649#ht_500wt_1062
You can see it is almost identical to the modem you are looking at!
-
it has SP10 firmware and it is a 3B hardware revision.
That's good. Now you just need to upgrade the firmware to the Asbo SP10 version and you are ready to monitor your line.
-
Now you just need to upgrade the firmware to the Asbo SP10 version and you are ready to monitor your line.
Already done. I am using it on an ADSL line because the Broadcom 6368 chipset performs well.
Do the stats monitoring scripts work with ADSL?
-
Ah, no, not all of them. :no: Bald_Eagle1's scripts are VDSL2 specific.
Oops. I've just realised we are hijacking BlackEagle's post concerning his FTTC connection. :-X
-
Sorry Blackeagle!
-
Its ok guys :D
-
Hi BE,
How's the connection holding up now you've had chance to thrash it for a while?
Any issues (that you are aware of)?
Cheers,
BE
-
Hi BE,
How's the connection holding up now you've had chance to thrash it for a while?
Any issues (that you are aware of)?
Cheers,
BE
You mean like my speedtests being all over the place, depending on where I do them. Upload is pants etc etc ??
Yeah, all of them !!
Its a lot faster than I had before, and thats very noticable on my wired desktop, but its not blindingly fast or exactly what I was hoping for. Perhaps a better test will be when both my teenage sons are at home on their xboxes and wife is on laptop. We'll see maybe then the benefit of more bandwidth, but currently, Beagle is a little disappointed with his results :-[
Of course, some connection stats would aid that greatly, as I would have something better to go on than a vanilla speedtest !!! >:(
-
Hi BE,
You mean like my speedtests being all over the place, depending on where I do them. Upload is pants etc etc ??
Yeah, all of them !!
Oh dear :(
Personally, I prefer to use speedtest.net as it appears to be the most consistent & it stores results (& has its own graphs) without the need to register.
Can you still run the BT speed test that reports IP Profiles?
Its a lot faster than I had before, and thats very noticable on my wired desktop, but its not blindingly fast or exactly what I was hoping for. Perhaps a better test will be when both my teenage sons are at home on their xboxes and wife is on laptop. We'll see maybe then the benefit of more bandwidth, but currently, Beagle is a little disappointed with his results :-[
Hopefully you will, especially if any of them or you regularly dowload large files/films etc.
Of course, some connection stats would aid that greatly, as I would have something better to go on than a vanilla speedtest !!! >:(
No joy with obtaining a HG612 at the moment then?
Cheers,
BE
-
Not to try and advertise, but I have an HG612 that was bought for an ADSL connection, but I no longer need it and it is obviously completely compatible with fibre. It includes the original box, with all the cables, it was running the SP10 firmware and I have unlocked it.
I have only had it a few days so if you would like it, I would be happy to put it on eBay as a buy it now offer for £22 plus £4.99 postage?
Let me know if you are interested.
-
Not to try and advertise, but I have an HG612 that was bought for an ADSL connection, but I no longer need it and it is obviously completely compatible with fibre. It includes the original box, with all the cables, it was running the SP10 firmware and I have unlocked it.
I have only had it a few days so if you would like it, I would be happy to put it on eBay as a buy it now offer for £22 plus £4.99 postage?
Let me know if you are interested.
Surely you and Blackeagle could perform the transaction without the use of eBay? You just need to start with a PMs to introduce yourselves to each other, etc.
-
Oooh errrr, so many replies :o
@arobertson545, yeah I would be interested in that, PM me and we'll go from there mate ;)
@BE1, I'm registered on speedtest.net and have done quite a few tests on there (and speed.io and TT and BT). Sadly I can only use the beta test on BT which doesn't give any IP profile info, but does give a similar speed to the TT tester. Speedtest.net I feel is more 'real world' and consistently gives me results about 8meg below the BT/TT tests.
Stats are the thing lacking here obviously. If my speedtests are 90% of sync then great, although I'd be looking to SNRM & Attn figures to explain why they are what they are. Obviously, its hard to judge without something definitive to go on, but my early speedtests were much better than now (10meg difference). This may just be DLM, but its hard to say ATM.
Going from a connection where I could monitor everything to one where I have no idea what is going on has been a major shock to me.
As an aside, I have noted from my router logs that ACS is changing things each day. I have asked on the TT forum for details of what it may be doing. TR-069 was never enabled on my ADSL line.
-
As an aside, I have noted from my router logs that ACS is changing things each day. I have asked on the TT forum for details of what it may be doing. TR-069 was never enabled on my ADSL line.
Please post a snippet of your router log that shows some of the typical ACS activity.
Why not look into you router's settings and configure exactly what you want? :-X
-
Please post a snippet of your router log that shows some of the typical ACS activity.
Why not look into you router's settings and configure exactly what you want? :-X
My router is configured how I want it, I just want to know what TT ACS feels it needs to change !! As yet, I have had no reply as to what it may be doing, and whilst I disabled it on all my ADSL routers, currently I have left it enabled on my fibre connection.....for the time being anyway.
Log excerpt.
2012-4-11 20:19:51 Notice 0 admin login
2012-4-11 19:33:56 Notice 0 admin login
2012-4-11 16:59:34 Info 104054 acs information have been modified!
2012-4-11 16:59:34 Info 104054 acs information have been modified!
2012-4-11 16:59:34 Info 104054 acs information have been modified!
2012-4-11 16:59:33 Info 104054 acs information have been modified!
2012-4-11 16:59:33 Info 104054 acs information have been modified!
2000-1-1 0:0:38 Info 104054 acs information have been modified!
2000-1-1 0:0:38 Info 104054 acs information have been modified!
2000-1-1 0:0:38 Info 104054 acs information have been modified!
2000-1-1 0:0:36 Info 104054 acs information have been modified!
2000-1-1 0:0:36 Info 104054 acs information have been modified!
2000-1-1 0:0:27 Notice 104500 DSL activate succeed
2000-1-1 0:0:26 Notice 1 System up
2012-4-10 15:19:9 Info 104054 acs information have been modified!
2012-4-10 15:19:9 Info 104054 acs information have been modified!
2012-4-10 15:19:9 Info 104054 acs information have been modified!
2012-4-10 15:19:8 Info 104054 acs information have been modified!
2012-4-10 15:19:8 Info 104054 acs information have been modified!
2000-1-1 0:0:27 Notice 104500 DSL activate succeed
2000-1-1 0:0:26 Notice 1 System up
2012-4-9 19:8:22 Notice 0 admin login
2012-4-9 16:53:24 Notice 0 admin login
2012-4-9 16:15:52 Notice 0 admin login
2012-4-9 16:15:28 Info 104054 acs information have been modified!
2012-4-9 16:15:28 Info 104054 acs information have been modified!
2012-4-9 16:15:28 Info 104054 acs information have been modified!
2012-4-9 16:15:27 Info 104054 acs information have been modified!
2012-4-9 16:15:27 Info 104054 acs information have been modified!
2000-1-1 0:0:38 Info 104054 acs information have been modified!
2000-1-1 0:0:38 Info 104054 acs information have been modified!
2000-1-1 0:0:38 Info 104054 acs information have been modified!
2000-1-1 0:0:37 Info 104054 acs information have been modified!
2000-1-1 0:0:37 Info 104054 acs information have been modified!
2000-1-1 0:0:28 Notice 104500 DSL activate succeed
2000-1-1 0:0:26 Notice 1 System up
Currently it seems to change things when a reboot of the router is carried out. This is unfortunately needed every 24hrs currently as wireless connectivity is lost, followed shortly by ethernet. Even the routers GUI is inaccessible. TT have trialled some new firmware which apparently cures this...BE waits impatiently for its release !!
I have done a "diff" of two config files that I have, one from two days ago and one from this evening after my wife rebooted the router due to lost connectivity.
Two differences are apparent, although the second is the current date and time. So, whats changed ??
Old config
<X_ATP_SyslogConfig Enable="1" Level="debug" DisplayLevel="debug" MainServerPort="514" MinorServerPort="514" LogServerEnable="0" MainServer="" MinorServer="" Clear="0"/>
Current Config
<X_ATP_SyslogConfig Enable="1" Level="debug" DisplayLevel="info" MainServerPort="514" MinorServerPort="514" LogServerEnable="0" MainServer="" MinorServer="" Clear="0"/>
The ACS server has, for some reason, changed the display level of the syslog. Curious, I can think of no reason to do so other than the fact that it hides the follwing lines in the log, which occur when the router loses connectivity.
2012-4-9 16:16:25 Debug 0 File:wuconfig.c, Line:1981 Get status failed.
2012-4-9 16:16:25 Debug 0 File:wuconfig.c, Line:1981 Get status failed.
2012-4-9 16:16:25 Debug 0 File:wuconfig.c, Line:2126 Get status failed
-
Interesting. I would be tempted to see what the wuconfig.c file is supposed to do. :-\
-
It is interesting. Which router is this, Blackeagle?
-
It is interesting. Which router is this, Blackeagle?
Its the Huawei Echolife HG532, firmware 2.02t
-
It is interesting. Which router is this, Blackeagle?
Its the Huawei Echolife HG532, firmware 2.02t
Ahh.. another one, like the DLink DSL2680TT, based on the Trend TC3162 chipset?
If it's running MIPS Linux then it's eminently hackable, not so if it's running ZyNOS.
Have you port scanned it? Is telnet open? Any clues on the type of HTTP server? There should be some info in the HTTP headers.
'Stokie' has taken some good PCB shots of the HG532 B1. Stokie reports obtaining two UART ports on the board.
http://stokie-ant.no-ip.org/other-routers
cheers, a
-
Its running Linux and I can get to a busybox prompt (thanks to a blog written by your good self Asbo !!)
Welcome Visiting Huawei Home Gateway
Copyright by Huawei Technologies Co., Ltd.
Login:admin
Password:
ATP>shell
BusyBox v1.9.1 (2010-11-09 16:31:44 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
# help
Built-in commands:
-------------------
. : alias break cd chdir command continue eval exec exit export
false getopts hash help let local pwd read readonly return set
shift source times trap true type ulimit umask unalias unset
wait
#
I only have a smattering of Linux though, not enough to do anything useful really :-[
-
Hopefully your new modem will turn up today and you can get some stats off of it!
-
Hopefully your new modem will turn up today and you can get some stats off of it!
Once Blackeagle has his Huawei HG612 operating satisfactorily, I know of someone who would like to borrow an ECI B-FOCuS! ;)
-
If you're brave enough to solder the UART port on the ECI then I think I know what commands to run to get stats, I think :)
-
Hopefully your new modem will turn up today and you can get some stats off of it!
Once Blackeagle has his Huawei HG612 operating satisfactorily, I know of someone who would like to borrow an ECI B-FOCuS! ;)
Indeed !! ;D
Attainable rate (kbit/s) 41212 9261
SNR margin (dB) 6 14.7
Line attenuation (dB) 0 0
Output power (dBmV) 9.8 4.7
Path 0 Path 1
Downstream Upstream Downstream Upstream
Line rate (kbit/s) 32123 2000 0 0
CRC errors 0 0 0 0
FEC errors 0 0 0 0
HEC errors 0 0 0 0
Graphs to follow shortly ;)
-
Good luck with your new modem and I'm glad it got to you successfully.
-
Good luck with your new modem and I'm glad it got to you successfully.
Yep, it arrived this morning while I was at work, so wife took delivery ;D
OK, some graphs, although I think I might need a bit of help interpreting them.
-
Hi BE,
You'll sleep better tonight, now that you can knock out a few graphs ;)
I see that while I had been playing about with the scripts, I had increased the resolution of the SNR graph.
It is now so large that the montage (including --pbParams & --show) can't be attached.
I have attached an amended GRAPH6.BAT, that keeps the file sizes down a bit, so that if required, you could actually attach the montage.
I have renamed it to GRAPH6.txt
Just rename it back to GRAPH6.BAT & replace your original (if you wish to generate smaller files).
-
OK, some graphs, although I think I might need a bit of help interpreting them.
Right,
Firstly the big red 'V' shape in your bit-loading & SNR graphs for the downstream D1 band looks very unusual.
It would be interesting to see the Attenuation & SNR values from --pbParams.
From the snippet you posted earlier, your Output power levels look a little low.
From that same snippet, your US SNRM level looks O.K. for the actual sync speed capped at 2000 k v the Attainable rate of 9261 k.
However, DS SNRM looks low for a sync speed of 32123 k v the Attainable rate of 41212 k.
On the rare occasions that my connection syncs as high as 32Mb, the Attainable rate is usually only around 33Mb.
It would appear that some noise somewhere is lowering your overall SNR & SNRM levels, thus keeping your DS sync speed down.
As DS band D1 uses lower frequencies (ADSL frequencies plus a bit), I wonder if cross-talk from nearby ADSL signals is the cause?
Also, your attenuation from the Hlog graph looks too high to achieve anything from the highest DS D3 band.
Bit-loading ceases at just over 70dB attenuation
-
Thanks BE !!
Yeah, I sort of suspected there to be noise on the line. There was on ADSL2+, particularly evident at night. However, since I have now discovered the full route of my line and found it runs past four pubs and two restaurants this doesn't suprise me.
Attached is pbParams for your perusal.
On a slightly different subject (but its my thread so I can :lol:), I have had to set my network up in a peculiar way to get to this stuff. I.E. I have had to move the router IP to 192.168.1.10 to allow me to access the modem on 192.168.1.1 but I have had to set up everything with static IP's as when left at 'auto' they were picking up two gateways, one at 1.10 and one at 1.1 Suggestions would be welcome as I have only configured a few of the devices and will be getting moaned at when I haven't set the other kit up :o
-
Well,
My modem is still set as 192.168.1.1
My router is still set as 192.168.1.254
Any PCs I connect to the router (wireless or ethernet) are just set to obtain an IP address automatically.
HTH.
-
Hmmmm, OK. Perhaps its to do with the fact that both LAN1 & LAN2 are connected to the router. I definitely get double gateways with this config and so nothing knows what to use if I leave it at auto config. Currently a few things are online (including the wife on FB) so can't mess around at the minute, but think I'm gonna set up DHCP on the modem and turn it off on the router. That should sort it I think.
In the meantime, DLM has changed my sync speed and it is now 34999 with a currently max attainable rate of 42252 with an SNRM of 6.3dB.
-
That's strange.
All the modem needs to do is present an ethernet connection to the router & then the router should sort it out from there.
The speeds look alittle better. Let's hope that nasty DLM doesn't want them back again.
Where did you manage to get the US QLN data from?
All other connections I have seen (& your first Plink log) show values of -160.00 for the US tones.
-
That's strange.
All the modem needs to do is present an ethernet connection to the router & then the router should sort it out from there.
The speeds look alittle better. Let's hope that nasty DLM doesn't want them back again.
Where did you manage to get the US QLN data from?
All other connections I have seen (& your first Plink log) show values of -160.00 for the US tones.
My fault !!! Misconfigured the router slightly when I changed its IP address.
All data is supplied by your scripts so I dunno ? :-\
-
Hi BE,
Any chance of sending me the Plink log for those particular graphs?
You may have discovered a "glitch" in the scripts.
-
Emailed to you Paul.
-
Thanks for that BE.
It looks as though "something" has corrupted your Plink log timestamped 20120415-1351.
It contains data where it shouldn't & in some areas looks completely different to your Plink log from 20120413-2205.
Also when graphing it a Hlog data error is displayed (unlike when graphing your first Plink log).
Have you obtained the snapshot data since & if so, do the graphs look more "normal" (like your original set) i.e. only the 3 DS band plans shown for QLN?
Cheers,
Paul.
-
Hmmm, that is strange then as I graphed it before I emailed it to you and I didn't notice any errors. However, grabbing my current stats I got
Gathering statistics from the modem
Please wait a few seconds.........................
LOGDATE =2012.04.16
LOGTIME =19:00:44
FILEDATE =20120416-1900
MAIN_FOLDER =C:\HG612_Modem_Stats
C:\HG612_Modem_Stats DOES exist
SUBFOLDER = C:\HG612_Modem_Stats\Current_Stats\Current_Stats_20120416-1900
SUBFOLDER does not exist, so creating it
=~=~=~=~=~=~=~=~=~=~=~= Plink log 2012.04.16 19:00:44 =~=~=~=~=~=~=~=~=~=~=~=
*1
**2
***3
****4
*****5
******6
*******7
********8
********8a
*********9
**********10
***********11
All done!
****************************************************************************
****************************************************************************
Creating Huawei HG612 Connection Statistics Graphs.
Using Data from C:\HG612_Modem_Stats\Current_Stats\Current_Stats_20120416-1900
\Plink_20120416-1900.log - Obtained 16/04/12 19:00
****************************************************************************
Discovery Phase (Initial) Band Plan = US: (0,95) (880,1195) (1984,2771)
Discovery Phase (Initial) Band Plan = DS: (32,859) (1216,1959) (2792,4083)
Medley Phase (Final) Band Plan = US: (0,95) (880,1195) (1984,2771)
Medley Phase (Final) Band Plan = DS: (32,859) (1216,1959)
Attainable Rates: Downstream = 41672 k, Upstream = 9140 k
Sync Speeds: Downstream = 34999 k, Upstream = 2000 k
****************************************************************************
Producing graphs for VDSL2 profile 17a
*
**
***
****
*****
Creating Bits-20120416-1900.png
Creating SNR-20120416-1900.png
Creating QLN-20120416-1900.png
Creating Hlog-20120416-1900.png
multiplot> plot 'Data_Hlog.txt' using 1:($4>-95.999 && $4<0 ? $4 : 1/0) lw 1 lc
1 notitle w lines
^
line 0: warning: Skipping data file with no valid points
Converting Pbparams data to Pbparams-20120416-1900.jpg
Converting profile data to profile-20120416-1900.jpg
Creating Montage of:-
pbparams-20120416-1900.jpg
profile-20120416-1900.jpg
Bits-20120416-1900.png
QLN-20120416-1900.png
SNR-20120416-1900.png
Hlog-20120416-1900.png
Press any key to continue . . .
-
Hmmm,
The first Plink log you graphed & also sent to me looked as expected.
i.e. all US tones in the QLN data have a value of -160.00 & all US tones in the Hlog data have a value of -96.00.
Your more recent Plink logs contain different data values for US tones, hence the 'Data_Hlog.txt' error & the unusal appearance of your QLN graph.
I can only think that re-configuring your router setup has somehow introduced these discrepancies, error message & unusual looking graph.
Otherwise, your first set of graphs & the first Plink log would have also contained the same discrepancies etc.
For curiosity, how were the modem, router & PC(s) set up when your Plink log & graphs looked correct/normal?
Others using the HG612 on an ECI DSLAM don't appear to see these "glitches", but I'm not sure which routers they are using or how they have them set up.
-
It was just a misconfigured DNS server entry thats all, can't see how it could affect any data supplied by the modem.
Attached is a PuTTY log of a telnet session to the modem. It contains the edited (for size) result of xdslcmd info --linediag. Hlog & QLN data is present.
-
From that putty log, I obtain the following two graphs --
-
It was just a misconfigured DNS server entry thats all, can't see how it could affect any data supplied by the modem.
I don't know, BE.
Something has changed bewteen your Plink log of 13th & your more recent log.
Attached is a PuTTY log of a telnet session to the modem. It contains the edited (for size) result of xdslcmd info --linediag. Hlog & QLN data is present.
Even that looks just as strange as the more recent Plink log.
US isn't supposed to be reported for QLN & Hlog (as per the first log with values of -160.00 & -96.00 all the way trhough the US tones (& a little beyond)
-
What can I tell you BE ??
This is the data coming back from the Huawei. I have attached the last graph I have of QLN as you would have expected it, and then one showing US data. This is well before I changed my network config. I wonder if BTAgent or TR-069 has altered something.
Welcome Visiting Huawei Home Gateway
Copyright by Huawei Technologies Co., Ltd.
Login:admin
Password:
ATP>sh
BusyBox v1.9.1 (2010-10-15 17:59:06 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
# xdslcmd --version
xdslcmd version 1.0
DSL PHY: AnnexA version - A2pv6C030b.d22g
******* Pass *********
#
Perhaps you get a different version ?? :shrug2:
-
Perhaps you get a different version ?? :shrug2:
No, identical version.
The only other difference is that you are connected to an ECI DSLAM & most of us are connected to Huawei DSLAMS.
That still doesn't explain why your first logs & graphs looked "normal" though.
-
As far as I understand it, Hlog is not dynamic but produces its data during the training phase, as does QLN. Therefore I assume that this data was measured when my (currently only) re-sync occurred. This was at 5:35 AM 15/04 This is further bourne out by the last graph of QLN I have before this time, a graph from later that same day, and a graph from this evening which is exactly the same as the graph from sunday.
Now, I do not have a logical explanation for the lack of upstream data versus it suddenly being reported, but it clearly is. This may be yet another bug with the Huawei modem but I'm not yet tempted to drop the line to see :no: :D
The Huawei/ECI combination is an interesting one as OR have supplied matched equipment, no doubt for improved throughput and sync as matching chipsets should perform best together. I have noted since using the Huawei that my throughput speeds do not appear to be good versus my sync speed. Indeed using the ECI, I have not had a speedtest less than 29.46 Mbps yet with the Huawei, my fastest test has been 27.86 Mbps. Sync on the Huawei at the time was 34999Kbps. All tests have been carried out on the same speedtest although times have varied and obviously, I have no idea of the sync speed on the ECI.......yet !!
If my connection stays steady for a few more days, I think a change of modem may be in order to see if the speed changes much.
-
Now, I do not have a logical explanation for the lack of upstream data versus it suddenly being reported, but it clearly is. This may be yet another bug with the Huawei modem but I'm not yet tempted to drop the line to see :no: :D
Another one of FTTC's mysteries/secrets.
Have you any interesting graphs from the ongoing log to show us?
-
I don't know if it is the same on vDSL, but with the Huawei on ADSL it reported the errors incorrectly in the web interface.
-
Yes,
They are also mixed up in it's GUI on VDSL2, incorrectly showing FEC errors when Interleaving is OFF etc.
-
This is currently the total amount of data I have so far. Note the big downstream SNR drop recently tonight :o
Connection is still up though. I wonder just how far that downstream SNR can drop before a re-sync is required. I've seen it at 2.8dB tonight, which would have had most ADSL routers dropping like flies.
-
I have to say that's one of the worst connections I have seen to date (apart from my own that I see every day).
Can you pinpoint any of the drops/jumps in SNRM to any equipment being switched on/off, maybe even dialling or receiving a telephone call?
I am currently experiencing the phone call issue.
It is occasionally that bad that SNRM drops to a few dB below zero & causes an immediate re-sync (almost always at a lower speed).
Sometimes receiving a call causes SNRM & attainable rate to increase.
Not recently, but I have occasionally seen my connection hang on to about 0.5dB SNRM for 1 or 2 hours (not using the phone) before picking up again (without a re-sync).
-
Well mate, thanks for that lol, its nice to have friends !!
Sadly no, I have never been able to pinpoint my SNR drops to any devices or local interference.
I do know that the installing engineer was concerned about the amount of RS errors he was seeing on his JDSU. It isn't bad enough though for OR to do anything about it, and it wasn't on ADSL2+ either. The fact that my line goes for 650m in the opposite direction to the exchange didn't help on ADSL either.
B'eagle just lives with his line and accepts there is nothing anyone will do :cry2:
-
Well mate, thanks for that lol, its nice to have friends !!
:lol: :lol: Join the club!
B'eagle just lives with his line and accepts there is nothing anyone will do :cry2:
If this B'eagle had any sense, he'd do the same :'(
-
:lol: :lol: Join the club!
The "Defective Line Eagle Club"? ::)
Remember that actual VDSL2 experience is only now being obtained, thus those of you who have the practical ability to gather meaningful data (albeit from poorly performing lines) are assisting Openreach (and thus the Beatie Group) in its learning process.
The current data set regarding VDSL2 performance, as provisioned for U.K. usage by Openreach, is just the theoretical and experimental results from the wizards at Grimbledon Down (a.k.a. Martlesham Heath).
Assuming you both have your ISPs "on board", I suspect that Openreach will ultimately try their best to resolve the real-world issues that you both have highlighted.
-
If my connection stays steady for a few more days, I think a change of modem may be in order to see if the speed changes much.
If/when you do decide to change modems back to the ECI, it might provide interesting/useful research information if you would firstly be prepared to power off the HG612, leave it a few minutes, power it back on, leave it a few minutes & gather its stats again - just to see if the HG612/ECI DSLAM combination still populates US QLN & Hlog tones.
To ensure DLM wouldn't see it as instability, then maybe wait for up to 1 hour before switching to the ECI modem.
-
I haven't power cycled it yet, but it has re-synced and the stats still show QLN data. Horrible burst of noise last night, as evidenced over several graphs.
-
An update ;D
A power cycle is imminent, so a montage of my current stats is attached, followed by stats immediately afterwards.
@BE, no QLN data anymore !!
-
@BE, no QLN data anymore !!
That now looks more like we would expect.
I also guess you didn't see the Hlog data error as the script was working?
I see DS SNRM increased following the power cycle, as did your attainable rate.
However, sync speed remained at 32399 k, which suggests that DLM has now capped your sync speed, no doubt due to the "messiness" displayed in your Ongoing graphs, even though Interleaving depth has dropped to a more respectable level.
I imagine INP & delay have also reduced slightly.
How long your sync speed will remain capped is anyone's guess.
On occasions mine had remained capped for a couple of weeks at a time, requiring an engineer's visit to get it reset.
Looking at the "messiness", there would not appear to be much point in using up all your "DLM resets lives" until which time a cause of the messiness can be determined & some engineering repair work has been carried out.
My suspicion is that your line is somewhat defective, rather than this simply being a noise issue.
Maybe a few weeks of monitoring your Ongoing graphs will highlight a pattern to the SNRM drops, sudden large increases error counts and/or re-syncs.
If it is truly intermittent, like my connection, it must surely point to a repairable D-Side fault "somewhere".
Getting your ISP & BT to accept your line needs "fully" testing is another matter though as your connection will no doubt be "performing within acceptable limits".
If your ISP appears receptive, it MIGHT be worth providing them with a few graphs of your connection over say a 1 month period.
Even if you manage to get the line tested, it might happen that it is tested when things are intermittently "good".
That seems to be the case with my connection as it takes that long to arrange an engineer's visit that the fault has intermittently disappeared by the time they turn up.
On the other hand, for a quiet & sane life, you may decide to accept that 32.4Mb ain't too bad anyway, as long as it doesn't deteriorate much further ;)
-
32.4meg ain't bad really, but the fact that the installing engineer was suprised at the speed RS errors were racking up on his JDSU, coupled with the (admittedly short) data that I have harvested already, does point to a 'D' side issue. Its such a shame that the OR testing suite was unavailable that day. He did try several times, and also commented that it had been unavailable all day so far (this was around 2PM).
As you so rightly say, pursuading the powers that be that there is an issue is another matter altogether. I am not so worried about pure sync speed although obviously I would like it to be as high as it can be, but am more concerned that the high error rate is impacting throughput speed. For example, the very first test I did on speedtest.net with VDSL2.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fspeedtest.net%2Fresult%2F1876891125.png&hash=aeb4994c57b64265793cac9f433d497179e6e152)
Contrast this with
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fspeedtest.net%2Fresult%2F1897599148.png&hash=59b3f7d509064ae378b50255cadedc04310fcea8)
Which was done at my higher sync speed of 35000Kbps
Now, either my throughput really is pants or speedtest.net isn't accurate.
I do wonder if the higher test results were because of the ECI/ECI combination though. I will have to change back shortly to find out !!
-
I ALWAYS use speedtest.net as I have found it to be the most consistent.
I usually see throughput of around 97% of IP Profile, which is 96.79% of sync speed.
e.g. sync speed 29061 k = 28128 k IP Profile = 27284 k throughput, so for me, speedtest.net seems pretty accurate:-
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fspeedtest.net%2Fresult%2F1903777334.png&hash=4ccdc14b42b1c36d68b15956781ef636efd523dd)
My ping time looks pretty good too, not that it matters as I'm not a gamer.
I can't understand why Interleaving has been OFF for my connection for the last few weeks though as I certainly see plenty of errors.
DS Interleaving was always on (LOW) with ping times of around 26-30ms until recently (apart from when throughput was 33Mb & ping times were 5ms for the first month).
How will you manage to sleep at night when you have no stats & graphs to lovingly stare at? :lol:
I could always send some of mine to you - I have thousands of them & just to rub salt in the wound I have quite a few from other users' really fast & stable connections :(
-
No, thats fine Paul, I think I'll just stick with my graphs thanks !!
Anyways, I have this evening, after much deliberation, decided to post on TTFM regarding the state of my line, so we will see what the OCE have to say and whether or not talktalk will take up the issue and instigate an OR investigation.
-
:hmm: Hmm . . . Would this (http://www.talktalkmembers.com/forums/showthread.php?t=79418) be your thread?
If so, I'll watch it with interest. ;)
-
:hmm: Hmm . . . Would this (http://www.talktalkmembers.com/forums/showthread.php?t=79418) be your thread?
If so, I'll watch it with interest. ;)
Thats the one my feline friend ;)
-
Aha.....Action ;D
My issue is getting escalated to Networks based mainly I think, on the good graph/bad graph comparisons I have posted and the enormous amount of errors I'm getting. Hopefully they will bounce it straight to OR.
-
UPDATE
Something happened at around 4.30-5.00pm last night (saturday). SNR began to rise quite substantially and errors appear to decrease at the same time.
-
Hi BE,
That upward DS SNRM line looks far too straight.
Were the stats actually being logged during that period, or did logging recommence at around 08:00 the next day?
I would guess the connection had also resynced during that period?
-
My critical eye tells me that no valid data was recorded between the hours of 17:00 on 05/05/12 and 08:00 on 06/05/12 . . . :-\
-
Update
TT have passed this to OR who have accepted it as an FTTC1. Apparently I don't need a visit for this but OR will do some remote testing. Progress in the right direction then I hope.
Last ten days graphs attached.
-
Hopefully . . . :thumbs:
-
How's the Huawei working for you? Hope it's okay.
-
How's the Huawei working for you? Hope it's okay.
Yeah its working fine thanks and producing lots of lovely stats. Well, they would be lovely if they looked better !!
Keep being tempted to put the ECI back on to see if it makes any difference, but I really don't want to lose access to those stats :shrug2:
-
OK, the most helpful BTOR engineer I have ever met has just left.
I now know that my line is 642m from my socket to the FTTC DSLAM. I also know its ALUMINIUM for its entire length :cry2:
Interestingly though, when the engineer arrived, I was in sync at 25meg so he went to the cabinet and got 25meg sync there as well. On speaking to the help desk they told him that DLM had capped the line after it saw major error rates on Thursday the 10th. My graphs bear this out. Help desk said they could temporarily override this and set the profile to 35meg. Engineer got 35meg sync at DSLAM and on returning tried to get his JDSU to sync up but the battery went flat. He did however do a remote test using his phone (GEA something or other) and it returned 35meg sync at the modem. Speed tests at this time were consistent with that sync rate, although he had swapped out my HG612 for an ECI before I arrived home from work. This is a bit of a result though as he said I could keep it, thus I have two ECI's so will be unlocking one of them now !!! 8)
Anyway, the tests we have done between us have proved that although my line is ally, there is virtually no loss of speed over it from the DSLAM to the modem. Unfortunately though, the ally makes the downstream SNR bounce around a lot and DLM doesn't like it one little bit, hence the cap at 25meg.
The engineer also mentioned something about a Brandenberg test (I think) which was apparently showing a wet joint but he said he thought this most unlikely, given the path of the cable. Annoyingly, the pole next door but two, which is where the dropwire to my house comes from, is the last one on the run from that cabinet and therefore if I lived but one house to the left, I would be on a different cabinet, the D side of which is entirely copper :'(
Ah well, at least I know now why my ADSL2+ max speed was 9 meg and why my fibre isn't performing as well as it should, although I have to say its better than I would have expected on ally.
-
Anyway, the tests we have done between us have proved that although my line is ally, there is virtually no loss of speed over it from the DSLAM to the modem. Unfortunately though, the ally makes the downstream SNR bounce around a lot and DLM doesn't like it one little bit, hence the cap at 25meg.
Hmmm.
Doesn't ally just attenuate the signal a little more than copper?
I have seen reports of other supposedly 100% ally lines where stability has not been an issue & speeds have been relatively high.
The engineer also mentioned something about a Brandenberg test (I think) which was apparently showing a wet joint but he said he thought this most unlikely, given the path of the cable.
Oh dear. Something else we will have to read about!
A proper bloke would post a link for us ;)
Ah well, at least I know now why my ADSL2+ max speed was 9 meg and why my fibre isn't performing as well as it should, although I have to say its better than I would have expected on ally.
A few positives in there then.
I would say the various errors have caused the quite low DLM speed caps, but I'm not convinced that ally cabling is the whole cause of the errors.
It may just be that trying to provide up to 40Mb down a line that can only deliver say 30Mb is the cause of the errors.
Once over, Plusnet experimented with capping my THROUGHPUT profile to 32Mb to reduce packet loss/uncorrected errors etc.
It did appear to induce some stability & I was able to maintain higher sync speeds than DLM's agressive capping mechanism for a while (until the "other" intermittent connection dropping when using the phone issues resurfaced).
-
When OR over-rode the DLM cap and put the profile to 35meg at the DSLAM, the modem was in sync at 35meg also, which suprised the engineer a little bit as there was no loss of speed over the loop. This is quite obviously the case as when he arrived the modem was in sync at 25meg (actually 24998 kbps) and he got the exact same figure at the DSLAM when he plugged his JDSU into it. So the issue isn't loss of signal over the ally, its the wavy SNR (engineer said).
-
A further update.
Today OR came out again. I was at work and neither my wife or I were expecting them. Apparently, having fed back to TT networks the results of Monday, networks told OR that my speed was still slow and that they wanted the line re-profiled. Engineer turns up at house to check if this has been done. No. looks at his JDSU for a bit, mutters something to my wife (who has no clue at all about bb) that 'something isn't quite right' and that he's going to the cab to have a look at things. Off he goes, and thats the last she sees of him as he doesn't return. This is, I should mention, all pre-noon.
This afternoon at 14:15, my line re-syncs at 39997/2000 <- woohoo, top speed :D
I check my graphs when I come in from work and find that where the RS graph had previously being going crazy, it is now empty....Hmmm, I suspect something has happened with the logging so I check again. No, all the logging is fine, the graph suddenly stops when the line re-synced. Also, interleaving is now off, where it was on before (and quite high too).
Now I have no idea what this OR engineer did exactly, but something has quite definitely changed as evidenced by the attached graphs of the last 24hrs.
I am now waiting with some trepidation to see what DLM does :no:
-
Things seem to be looking good! Now just like I said to Snadge, previously: "No fiddling!" :P
:thumbs: :dance: :silly: :congrats:
-
Hi BE,
How's the connection holding up these days?
A montage of the latest 30 days or so would be good for us to view ;)
Mine's been stable since the latest engineer visit of Saturday 26th May, apart from 2 DLM induced re-syncs (to turn Interleavibg back on at a fairly lowish level).
Any other connection drops have been caused by me to run "tests", try out a dangly filter in the test as a comparison against the replacement SSFP etc. (the dangly filter actually caused SNRM to reduce)
An unsorted montage of the latest 30 days of my connection is attached.
Recent sudden increases in US attenuation are "interesting".
There are now 25 graphs in total that can be plotted.
An updated set of batch files is imminent for release, probably within the next 2 weeks.
Let me know if you would like to test them out on your connection.
EDIT:
Just replacing the existing batch files will start adding the extra data to modem_stats.log without losing any previous data, so ongoing records are maintained intact (in theory).
-
Haha Paul, I would be more than interested in your new bat files ;)
As to how its holding up, it was doing really well until a day or so ago, when the connection dropped for the first time since OR had sorted things out, and its come back with much higher interleaving and a lower sync. Its still not bad however, considering its an aluminium line and is 648m long !
You will see from the attached montgae that there is some data missing for a few days. BE confesses he was messing with the scripts to try to log & graph more data but apparently stuffed it up !!! :-[ Hence my great interest in your new ones ;D
-
You will see from the attached montgae that there is some data missing for a few days. BE confesses he was messing with the scripts to try to log & graph more data but apparently stuffed it up !!! :-[ Hence my great interest in your new ones ;D
Oops!
Email with attachment sent accordingly.
-
Thanks Paul, will email you if any issues ;D
-
You will see from the attached montgae that there is some data missing for a few days. BE confesses he was messing with the scripts to try to log & graph more data but apparently stuffed it up !!! :-[ Hence my great interest in your new ones ;D
Oops!
Typical of Eagles! :P :crazy: :oldman:
-
Thanks Paul, will email you if any issues ;D
Have you had a dabble with the updated scripts yet?
I'm still not 100% happy with the data harvesting error checking/correction yet.
I think I have an issue at around 05:00 am, where a few minutes of harvested data are "missing" (only some mornings though), possibly when AVG is either virus checking or updating its database.
This does seem to be a Windows 7 issue only, but I haven't yet sussed whether AVG, Windows 7, the scripts, or "something else" is/are to blame.
-
Ha, yes I have. Attached is a montage ;D
I note with interest that early this morning, DLM resynced the line with a higher downstream sync, this after 72 hrs of stability. It'll likely go back down again, but at least DLM is moving it up now, whereas before BTOR reset it, it was only going in a downward direction.
The only data missing from the graphs AFAIK is a slightly greater than 2hr period yesterday evening, when due to a technical issue, windows would not boot :-[ :lol:
-=EDIT=-
Although the downstream errored seconds graph reports a figure in the heading, this does not seem to be graphed against time ?? ???
-
-=EDIT=-
Although the downstream errored seconds graph reports a figure in the heading, this does not seem to be graphed against time ?? ???
Ah, I see you have also spotted that "glitch".
I have already emailed you to mention it & to request some log files for me to investigate this.
At any given time, the error count plots should show 60 seconds or less & the total Error Seconds in the graphed period should be only the number of error seconds during whatever period you choose to plot in days, hours or minutes.
The Y axis adjusts itself to the maximum No. of error seconds seen in any 1 minute period.
It should usually max out at only a few, as per my 24 hour example attached - 96 DS error seconds within the 24 hour period.
EDIT:
Also, the US Error Seconds Y axis should grow or shrink to match, just to keep them equal for quick/easy comparison purposes.
The Y axis for the DS & US Interleaving graphs should not match each other though.
This is because some connections have DS Interleaving depths in the thousands, yet US Interleaving can be 1 (OFF) or some other very low value.
-
The Full Monty montage is not ordered & is put together with this command:-
montage *.png -quality 100 -geometry 640x -border 5 -tile 3x line_stats_FULL_MONTY_P-%FILEDATE%.png
To create the montage with a bit of order to it, you could replace that with:-
montage snrm.png CRC_errors.png FEC_errors.png sync.png DS_RSUnCorr.png^
OHFErr.png attainable_rate.png HEC_errors.png DS_RSCorr.png power.png DS_RS.png US_RS.png DSL_UP_TIME.png DS_INTERLEAVING.png US_INTERLEAVING.png^
DS_ES.png US_ES.png DS_OHF.png DS_line_atten.png US_line_atten.png US_OHF.png DS_signal_atten.png US_signal_atten.png^
US_RSCorr.png US_RSUnCorr.png^
-quality 100 -geometry 640x -border 5 -tile 3x line_stats__FULL_MONTY_P-%FILEDATE%.png
-
OK, I have edited graphpd.bat to update the full monty montage and have attached two examples.
The first is a 24 hr period (covering the last 24 hours) and shows everything correctly, the second is a two day period (which includes the broken data and covers the last 48 hrs) which has the same US/DS error errors ?!? as we have already discussed !! ???
I presume as long as I do not include that iffy data that everything will continue to graph correctly ?
BTW, I do like the improved folder naming where it specifies the range covered. Nice touch Paul ;D
-
OK, I have edited graphpd.bat to update the full monty montage and have attached two examples.
I presume as long as I do not include that iffy data that everything will continue to graph correctly ?
Yes, it only does that when it plays catch up from either a fresh start of the logging, or when there has been a pause in logging.
You could just delete the "offending" row(s) for it to be correct again.
BTW, I do like the improved folder naming where it specifies the range covered. Nice touch Paul ;D
Ah yes, I got tired of manually adding the graphed range to the folder name for archive purposes & sometimes forgetting which made it difficult to trawl back to relevant graphs when needed.
-
[/quote]
Right,
Firstly the big red 'V' shape in your bit-loading & SNR graphs for the downstream D1 band looks very unusual.
It would be interesting to see the Attenuation & SNR values from --pbParams.
[/quote]
I know this is going back in time quite a bit but I think I have solved the mystery of the V shape in the graph.
It appears that for VDSL this IS normal. It is a deliberate filter applied to these frequency bands to avoid interference with ADSL connections in the ducts/cabinets.
There is more information here : http://www.openreach.co.uk/orpg/home/products/industryforums/superfastfibreaccess/downloads/FTTC_TWG_slide_deck_19th_Mar_2009_v4.pdf (http://www.openreach.co.uk/orpg/home/products/industryforums/superfastfibreaccess/downloads/FTTC_TWG_slide_deck_19th_Mar_2009_v4.pdf)
In pages 29-32
HTH..
-
There is more information here : http://www.openreach.co.uk/orpg/home/products/industryforums/superfastfibreaccess/downloads/FTTC_TWG_slide_deck_19th_Mar_2009_v4.pdf (http://www.openreach.co.uk/orpg/home/products/industryforums/superfastfibreaccess/downloads/FTTC_TWG_slide_deck_19th_Mar_2009_v4.pdf)
In pages 29-32
HTH..
I'm afraid that link appears to be broken, causing a runtime error at my end.
I would mention though that from our limited data, such a pronounced 'V' does now appear to be more prevalent on connections to ECI cabinet DSLAMS than to Huawei cabinet DSLAMS.
-
I just tried the link, still working here, must be a problem launching embeded Acrobat reader in your browser.
Try right-clicking the link, save as then run the file outside of the browser.
There are graphs on it showing the filtering applied and these very much mirror the frequency ranges of the V notch in the traces given.
-
It was an AVG Toolbar issue.
I have disabled it & hey presto, problem gone.
I will study the document later.
FWIW, my graphs look like the attached (Huawei modem on Huawei DSLAM).
-
How is the connection now?
-
It was an AVG Toolbar issue.
I have disabled it & hey presto, problem gone.
I will study the document later.
FWIW, my graphs look like the attached (Huawei modem on Huawei DSLAM).
Hello BE1 I have noticed your download & upload sync has gone up since june
How did you get the increase ?
My stats seem to be steady :-\
-
Hello BE1 I have noticed your download & upload sync has gone up since june
How did you get the increase ?
That was immediately following a DLM reset (didn't last though).
My connection is now completely stable, but at lower speeds with Interleaving on.
-
Well at least you were able to try a DLM reset ;)
It looks like I am not going to get anymore out of my line, but still I am happy with the 27.5 Meg Down & 5.5 Meg Up from my 700-850 meters line length !
-
How's the line now?
-
Smucat is smiling. ;D FTTC Infinity 2 upgraded from ADSL 8M today. Huawei cab, ECI 1B modem and Toady HH3.0 type B.
Approx 400 metres from cab, as the cat crawls. Download speed test varying from 25 Mbps to 47 Mbps. Upload between 6 and 8 Mbps. Early days, but seems great.
-
Smucat is smiling. ;D FTTC Infinity 2 upgraded from ADSL 8M today. Huawei cab, ECI 1B modem and Toady HH3.0 type B.
Approx 400 metres from cab, as the cat crawls. Download speed test varying from 25 Mbps to 47 Mbps. Upload between 6 and 8 Mbps. Early days, but seems great.
the best way to find Max FTTC speed is to use the estimated guide first https://www.dslchecker.bt.com/pls/adsl/adslchecker.welcome (BT) and use this as the Base and if it's way off the estimated guide 4 - 5 megs difference is fine but 10-20 megs then it sure to a line fault or internal wireing issues.
-
Thanks for the link, NewtronStar. It even gives the cab number, although not all cabs have visible numbering. Quote is 57 Mbps, but max on day 2 is still 47 Mbps. Linebox is on end of dropwire. I don't think anyone will want to replace the wiring to the cab, for the sake of 10 Mbps!!
-
Download speed test varying from 25 Mbps to 47 Mbps. Upload between 6 and 8 Mbps.
I am surprised that you are seeing a variation of up to 22 Mbps in the DS. I presume (as you have an ECI active CPE) that the figures you quote are throughput speed-tests? Perhaps you might consider, after leaving things for a fortnight (say) to 'settle down', swapping the ECI B-FOCuS modem for a Huawei HG612 and then using Bald_Eagle1's utility to harvest data and produce graphs, etc?
-
@ NewtronStar et al,
Whilst the Wholesale DSL Checker often provides reasonable estimates on shorter lines we have found, by bitter experience on many longer D side lines - this time around 2.5 km, that the enthusiastic marketing mechanism can be wildly optimistic. One such line from a cluster of 10 all suggest a preposterous figure of 19 Mbps but reality dawns as you'll see below. After two months of investigation without progress, the checker has woken up saying that line only might provide "Up to 2.2 Mbps down & 0.4 Mbps up", leaving all the others still on 19 Mbps.
Just imagine what I said when I discovered that BT sales staff, in their usual splendid "twinkling meteors" style, had cold-called the hapless family and had actually convinced them to change a second line** to Infinity !!!!
VERY fortunately I arrived before they had attempted to get a MAC.
** That second line on ADSL obtains a sync rate of 1.33 Mbps.
Kind regards,
Walter
-
To clarify how the 'Checker/Estimator' operates. It only gives the approximate speed based on distance to the DP (The main pole, or underground joint if you like). The premises could then be fed via any number of 'Carrier Poles' or long underground cable runs.
As always, folk tend to pick up on the extremely rare cases BT's estimate get it wrong, for all intents and purposes, and from genuine first hand experience on a daily basis, the EU gets more than the estimate given.
-
HI BS and thanks for the explanation.
I know of two very poor performers from the DP which I'd guess is around 1.75 km D side distance.
Do you know what triggers the change in estimate to more realistic figures after umpteen SFIs and why all the others fed from the distant DP are not adjusted at all ?
Kind regards,
Walter
-
@ NewtronStar et al,
Whilst the Wholesale DSL Checker often provides reasonable estimates on shorter lines we have found, by bitter experience on many longer D side lines - this time around 2.5 km,
Thanks for your findings, it always was my thinking that FTTC should not be provided to customers with copper wire exceeding 1500 meters (1.5KM) ;)
http://www.thinkbroadband.com/guide/fibre-broadband.html
unless its the faster Broadband service sub 15mbps.
-
@ NewtronStar,
If you were one of the unfortunates on sub 1 Mbps ADSL, experience shows that the poor blighters are relieved just to see any improvement.
@ BS I agree for all those around the 1 km D side length unless they have suffered from sub-standard subcontract VDSL installations. Those above 1 km are more variable which is perhaps understandable. The one I quoted above has a sync speed of 1.88 Mbps and is now estimated at "Up to 2.2" Mbps. Some of the longer lines with multiple DPs have higher estimates as the estimator (Only sometimes) doesn't seem to know about the unexpected drop after a particular joint feeding a DP.
We have also noted that on noisy lines even down to 1 km there is often a drop of anything up to 5 Mbps after a few days once DLM has applied interleaving. The advantage is probably that with less retransmissions and more FEC corrections, the actual throughput is more stable and sometimes just a bit faster.
Kind regards,
Walter
-
I don't wish to open old wounds (ie old posts I've made about this before on other threads and got my ears burned), but my experience with BT's speed estimates has been uniformly negative.
Using the BT DSL checker mentioned in previous posts, I should expect circa 55DS/18US. This was also the estimate provided by BT as part of their marketing puff to entice me to upgrade from the old Infinity service to the (then) newly released 80/20 Infinity option.
In practice my line actually achieved 48DS/9US when initially upgraded. Recently it has averaged 47/11 - the DS has decreased but the US has improved. However - and this is very important in my case - the connection is solid (touch wood!!!) and the speed consistent. So I'm quite willing to accept the situation and have not made an issue of it with BT (particularly as the upgrade was free).
But if I had signed up as a new 80/20 customer I would not be very impressed as I can almost see the FTTC as I type this. I've never understood why on such a short run between the FTTC and my house the speed is so slow. (BTW: its nothing to do with wiring at my premises - I had a retired BT engineer in to check/fix the internal wiring after experiencing disconnection and interference problems in the old ADSL days with Virgin as the ISP - and which eventually turned out to to be a BT network problem anyway).
So from my experience I regard BT's speed estimates with some scepticism.
-
Hi BBN,
It might just be worth checking the latest BT Wholesale checker which confirms which PCP you are connected to.
Much will depend upon how your line is actually routed.
It certainly sounds as if you are several hundreds of metres away from the actual PCP and FTTC.
I know of a group of older houses which were connected to one of the very first PCPs in Cranleigh.
Since then there has been substantial infill and TWO more PCPs added en route BUT the original (now noisy) wiring has been left in situ.
In this case the D side length is over a km bypassing the two newer PCPs and consequently Superfast sync speed only just achieves a miserable 26 Mbps downstream.
In my experience I've only ever managed to order one new line where BT Openreach were prepared to change the original wiring to a more appropriate PCP.
Kind regards,
Walter
-
The old saying, 'Damned if they don't, damned if they do', springs to mind ........ in a friendly way of course. :)
Would EU's rather there was no estimate whatsoever ?? Also, my experience in these matters allow me to make the statement I made above ....... most EU's will achieve more speed than the 'Guesstimator' dictates, but above all, it is just an ESTIMATE, and it doesn't hide the fact that it is.
The eMLC (Managed Line Characteristics) uses Network Records and 3 other systems to calculate the line loss to THE DP. This, combined with the Cabinet CAL value (Cabinet Assigned Loss), and a model of future Crosstalk gives an indication of the long-term line rate estimation.
There are unknowns in this, such as the final drop which can sometimes be very long, the ACTUAL level of Crosstalk, or the presence of any line fault that may be there ?
Further to Walts question above, work is underway to see if development of the eMLC can be achieved to use actual measured losses of existing FTTC lines.
-
Thanks BS,
If I may second BS's thoughts on the estimator; it does state quite clearly that line speeds may drop. We have observed this too; either due to noisy lines applying interleaving at various levels or due to cross talk when more twisted pairs in the same cable obtain a VDSL service, the power is reduced so as to maintain reasonable speeds for everyone including those who have retained their older and weaker ADSL services. Another reason for lower speeds can be the banded profile purchased. E.g. Zen's cheapest VDSL service is limited to 2 Mbps upload even if the line is capable of higher speeds.
The estimator is helpful for those who would like to order the fastest possible service but would be wasting their money if the estimator is only offering say 30 or 40 Mbps. I expect in most places a small increase over the estimated speed just wouldn't be worth it - especially as the estimator is, I believe, providing sync speeds and not throughput speeds
I have one small improvement in the estimator I would like to see. That is a clear statement that an EU's cabinet has been enabled but the quality and / or length of the line prevents BT Openreach from offering any VDSL service. Currently the estimator doesn't mention VDSL at all in these cases. This idea would assist the EU as at least they would know immediately that another solution must be found if existing services are inadequate. We have one such notorious line where around 40 EUs are NOT offered any VDSL service, even though the cabinet is enabled.
Kind regards,
Walter