Kitz Forum
Broadband Related => ADSL Issues => Topic started by: Weaver on August 30, 2018, 11:20:13 PM
-
I don't suppose there is any way I can get the upstream target SNRM back down again, to 6dB? The actual upstream SNRM is currently 8.2dB as mentioned in another thread and this is a real nuisance as it has chopped over 25% off the upstream speed of that link.
-
It is impossible to "tweak" at the transmitting end of a link. A "tweak" can only be applied at the receiving end.
If someone could apply such a configuration modification to the four DSLAM ports then all would be good.
-
Does an ISP's SNR reset affect upstream similarly to downstream?
-
It should do . . . unless I'm not thinking straight. Now that you've mentioned it, don't you have access to the controls via the A&A interface? :-\
-
Indeed, I hit the SNR reset button on AA's clueless server but the upstream SNRM is still stuck up at 8.2 dB. I suppose I could ask them if they have any more magic tricks?
-
I asked them about this, far too early for a reply, of course, as I sent it way too late.
By the way, I see Openreach is advertising their Broadband Boost service. Line #3 ( cwcc@a.3 BBEU20700055 ) had a fault a couple of weeks back at the same time as the new line was being installed. It has always, since the very beginning of time, been slightly under par. The line 3 downstream sync rate is about 200k lower than the other pair in the same drop cable. Line 3 is at 2737kbps downstream sync, as opposed to line 4 BBEU20709519 (the other pair in that drop cable) which is at 2924kbps.
Whilst line #1 (BBEU20700042) enjoys a downstream sync rate of 3037kbps - so, what, around 10% worse downstream? Also the line #3 upstream is not great compared to line #1, only 85% of line 1’s upstream sync iirc at 440k as opposed to 515k.
I wonder if Openreach could improve it by 10% by inspecting and tweaking some joints?
I wonder
-
This morning, I did an AA speed test, got 1.52 Mbps upstream (am guessing that means TCP payload, but it could be a derived IP PDU rate which it should be but that would require an arithmetic tweak). So that is very good indeed, especially given that line 3 is still well under what it should be.
l also got 10.01 Mbps downstream.
The calculated sum of effective IP rates is 1.492 Mbps, so I think a tiny little bit of exaggeration by AA.
-
Ookla speedtester 9.76 / 1.32 using the test server at CoreIX in London and 9.74 / 1.34 at Wimbledon Lawn Tennis Club servers. They are of course a lot further away. So I won't accuse AA of exaggeration on that basis. For real serious exaggeration, the SpeedSmart server is happy to quote figures such as 1.7 Mbps or higher for the upstream.
SpeedOf.me quotes 10.7 / 1.35.
-
Talked to AA, who did another SNRM reset.
Suggested a few things to try. Swapping modems - carefully, to avoid DLM's wrath. And leaving modem off for at least 10mins.
-
I have always found that SpeedOf.Me exaggerates the results. And having "done the rounds" of all the available throughput speed checkers, I just default to the TBB version. (Even though the presented results are meaningless! There is no scale on the X-axis, so those squiggles mean absolutely nothing. There is no legend to describe the meaning of the different coloured squiggles.)
-
Does the colour of the labels "Download" and "X6 Download" not give you a clue as to the significance of the colours? (that's when looking at shared results)
(https://www.thinkbroadband.com/_assets/speedtest/button/1535819622209130555.png) (https://www.thinkbroadband.com/speedtest/results.html?test=1535819622209130555)
-
I don't see that screen. I was referring to the result screen, with which one is presented, at the end of a test.
-
Click "Results page" in the bottom left hand corner.
-
Are you logged in to the main TBB site when you run speed tests? If so clicking any of the results from https://www.thinkbroadband.com/my-profile#speedtestresults will show those graphs.
-
Not wishing to hijack this thread with irrelevances, I'll just briefly say that if I use the TBB speedtest utility (yes, logged into the main site) I expect it to give me the result, sensibly, and not be expected to left-click anywhere else.
-
I do hate that large distracting advert, which is really a nuisance.
-
How
Not wishing to hijack this thread with irrelevances, I'll just briefly say that if I use the TBB speedtest utility (yes, logged into the main site) I expect it to give me the result, sensibly, and not be expected to left-click anywhere else.
don't disagree with that!
http://forums.thinkbroadband.com/newsite/t/4599794-speedtest-results-graph-key.html (http://forums.thinkbroadband.com/newsite/t/4599794-speedtest-results-graph-key.html)
-
After some sort of funny error episode and a resync, the upstream on line 2 the new line has jumped from 440k to 555kbps. However, no matter what I do with slight rate tweaks, the upstream figure given by the AA speedtester is down at 1.12Mbps.
-
And more oddities. Janet turned modem #2 off for a good long while, and the downstream sync went up by well over a 110 kbps, but aside from that the upstream as reported by the AA speed-tester went up from 1.12 to 1.42 Mbps. I have no idea what that is all about.
-
Now fixed.
After the earlier mistake, Janet turned off the correct modem #3 and left it off for a couple of hours. And this cured the upstream: - #3 upstream went from 318k to 435k sync at 59.dB.
This was AA’s suggestion - one to remember - turning it off for ages really works.
-
That is good to know. :)
Perhaps, as a conclusion of this thread, you would post the aggregate DS & US throughput speeds you now achieve with your four line set-up, please?
-
line #1 downstream sync 3037kbps, AA TX rate d/s 2536323
line #2 downstream sync 2880kbps, AA TX rate d/s 2405610
line #3 downstream sync 2891kbps, AA TX rate d/s 2414827
line #4 downstream sync 2924kbps, AA TX rate d/s 2442478
line #1 u/s sync 515kbps [Firebrick rate set to 97%]
line #2 u/s sync 551kbps [Firebrick rate set to 97%]
line #3 u/s sync 435kbps [Firebrick rate set to 97%]
line #4 u/s sync 452kbps [Firebrick rate set to 97%]
-
This upstream problem is back again. It is line #3, again. The upstream sync rate was 442k, not very good compared with the others.
(Janet had got two of the modems (not links) mixed up, in the sense that each has a label on it and has a configuration with a unique, non-clashing admin interface IP address, and the units on links #2 (mux switch port 2, VLAN 102, line #2) and #3 (mux switch port #3, VLAN 103, line #3) were swapped, so that the FireBrick was trying to talk to a modem at 192.168.2.1 and that modem was listening to 192.168.3.1, thinking ‘I am modem #3’, and the reverse for the modem on link #3. So I asked her to switch them over.)
This involved powering them down, as I always think that is safer from the point of view of DLM. When powered back up, modem on link #3 had now dropped its upstream sync speed from 442k to 347k. So remembering the previous fix, left modem off for 45 mins, back on, no good, now the upstream sync was down to 338kbps.
Last time, I left a modem on this line turned off for several hours. I will try that again at some point. But I still wonder what on earth is going on. Why does this line lose 24% of its upstream sync rate ? And if turning it off for ages works, how long is an age, and why does some particular, greater length of time work?
—
Another matter - another modem: Much earlier this morning, I did a target SNRM reset on line #2. Unfortunately this dropped the upstream sync rate from 568kbps to 496kbps on this modem too. (But its downstream sync did go up by 67k, so not all bad.) So a total loss of 176k of upstream, which is over 10%, so not a good day for upstream, whilst downstream rates improved. Why is it that I can just lose a fair sized chunk of upstream on these modems ?
—
AA staff noticed that the upstream side loop loss has increased by 0.3dB on that line. There has been a massive amount of rain, but it is not raining right this minute. Makes me wonder if the line is lying in a lot of water - wonder if that could make a difference at lower frequencies?
-
Not sure how closely you monitor the SNRM of your lines over time Weaver, but I cant help thinking an overview of how it changes over the course of the day might help clear up the reasons for these differences in rates after a resync.
You may remember I was fiddling with a simple server running on VMG1312/8x24s to serve data and some javascript to make it into graphs client side. I finally got around to making the time series data work acceptably today so if you felt like being a guinea pig with one of your modems you could try the simplest possible version that just logs SNRM over a 24 hour period and graphs it. I have it doing more things but am not confident the range detection will work with lines other than VDSL2, its hard to test without a live ADSL/ADSL2+ line, so rather than offer something that might not work I can make one that just has the SNRM logging and graphing.
No problem at all if you don't like the idea of another http server running on your modems or wouldn't be up for the hassle of flashing, testing etc, but let me know if you would.
For example, a resync at half 11 this evening would have probably resulted in suboptimal speed:
(https://i.imgur.com/XofeQcP.jpg)
-
That’s a very thoughtful and generous offer. You really are a star! A lot of pain, burning and confusion today, so I can’t do much. I will have to return to this when I am rather better.
So to recap, need to get a picture of when is the good / bad time for a resync?
I don’t have any kit that is capable of being set up for monitoring, so your solution would be perfect.
I can however, ask the ISP to tell me some of the basic line stats, and they query the DSLAM etc remotely, reporting back with a current snapshot of the SNRM, sync rate and loop loss etc in both directions. Of course the other way is for me to query the modem directly: using a web browser doesn’t work well because the stupid web UI has Safari-related problems with info being off-screen and scrolling not working. The command line is of course far better.
I can telnet but not SSH for some reason, which might be to do with NATing to the modems through the router (a Firebrick) which rewrites src IP addresses. If I could get SSH to work, I have a tool (in the iOS12 ’Shortcuts’ app) that can launch remote shell commands via SSH and get the response back programmatically so I could hopefully write something nice to query all kinds of status info and handle it in an iPad ’Shortcuts’ program. (Doing the same kind of thing by web ‘scraping’ the modem’s status info web page would be really nasty, having to deal with html tag soup, ugh, and having to work out how to log in, what the right URLs are, all a pain doing it via http meant for humans.)
-
So to recap, need to get a picture of when is the good / bad time for a resync?
I cant speak for your ADSL2+ line, but on my noisy VDSL line the choice of time to resync can cause several mbps of difference in downstream, so a little under 10% on my ~25mbit/s connection. Maybe SNRM doesnt have the same influence on yours, but it seems like something sensible to rule out.
I can telnet but not SSH for some reason, which might be to do with NATing to the modems through the router (a Firebrick) which rewrites src IP addresses. If I could get SSH to work, I have a tool (in the iOS12 ’Shortcuts’ app) that can launch remote shell commands via SSH and get the response back programmatically so I could hopefully write something nice to query all kinds of status info and handle it in an iPad ’Shortcuts’ program. (Doing the same kind of thing by web ‘scraping’ the modem’s status info web page would be really nasty, having to deal with html tag soup, ugh, and having to work out how to log in, what the right URLs are, all a pain doing it via http meant for humans.)
The mongoose server (written in C and very small ~ 300K) is super basic and as it is just serves files produced by running a shell script on the modem. One GET request to the /getdata URI and the script is run to invoke xdslcmd etc to create files with SNR/bitloading/whathaveyou, then you can fetch them with similarly simple GET requests /SNR /Bits /Hlog etc. So its easy to fetch the data from javascript running on any tablet PC etc and draw graphs, but could be equally simple to summon it using Workflow and the returned files are just plain text which should be easy to parse, no tag soup etc. Also doesn't need any authentication... this may seem worrying, but with no commands passed and interpreted or important things done it doesn't seem like a big deal and simplifies things a lot.
I'l make a VMG1312 firmware with the most basic setup and a more detailed explanation later.
Hope you feel better soon! :)
-
You’re right about authentication. I can firewall off the modems from inappropriate LAN access anyway.
-
Have made a firmware if you feel like testing on one of your modems Weaver:
https://forum.kitz.co.uk/index.php/topic,21685.msg384925.html#msg384925
Again, absolutely no worries if it isn't for you. ;D
-
Wow. That is incredibly generous. ;D Would anyone reading this give Kitz a donation (https://kitz.co.uk/sites/support.htm) as a thank you to Johnson, if they are able?