Page 2 of 2
Re: Can I avoid QoS throttling my bandwidth when it's not in
Posted: Sat Mar 30, 2013 4:25 pm
by pbix
According to your modem's web page the line speed is 26900kbps so there is simply no way to go faster than that. And it appears that the QoS is breaking down right around 26000kbps.
Now as to why the ACC does not find the limit well that is because the ping times are not changing. The ACC is pinging the WAN gateway device. You can see that this ping rate never changes regardless of the data rate. This means the pings are not going through the queue of interest.
What do you know about your ISP and the location of your WAN gateway? These are some pretty high speeds for DSL.
The reason your QoS is breaking down is because someone upstream of you is dropping packets. Apparently that someone is not between you and the WAN qateway which is the default ping target. We need to bracket that someone between you and the ping target.
Try manually selecting another ping target. Start with your DNS server. Do you know any other servers your ISP maintains like SMTP or IMAP? These are also potential targets. We can also go deep into the internet to one of the google servers for example. That should certainly bracket the queue we are looking for.
In the future you only need to show me the QoS not working situation. I will be looking for the filtered ping time to increase as the download speed increases. It should reach the ping limit causing the ACC to react.
Re: Can I avoid QoS throttling my bandwidth when it's not in
Posted: Sat Mar 30, 2013 4:33 pm
by rtlx
I see on my modem WebUI
Downstream actual net data rate (kbit/s) is
24127 and
Downstream attainable data rate(kbit/s) is
26968. Isn't the former value the one that should be used in the
Total Download Bandwidth field?
I already tried to set ping target to 8.8.8.8 (Google DNS) in my previous attempts to no avail. Perhaps ping limit needs to change, because automatic is set to react at around 200ms which really rarely happen unless upload is utlized.
I know IMAP, POP3 and SMTP addresses of my ISP. I'll try them and post back.
Regarding to what internet I have, it's VDSL by O2 (advertised up to 20Mbps / 2Mbps). Regarding the physical location of my ISP's gateway, I have no idea. I don't know if that helps, but here is the traceroute of the WAN gateway:
Code: Select all
traceroute to 88.103.200.9 (88.103.200.9), 30 hops max, 38 byte packets
1 88.103.200.9 (88.103.200.9) 24.989 ms 22.986 ms 23.441 ms
2 88.103.203.33 (88.103.203.33) 29.106 ms 27.808 ms 27.359 ms
3 194.228.190.205 (194.228.190.205) 29.404 ms 30.536 ms 30.638 ms
4 194.228.190.206 (194.228.190.206) 33.301 ms 29.897 ms 31.606 ms
5 88.103.200.9 (88.103.200.9) 29.882 ms 28.823 ms 30.902 ms
Re: Can I avoid QoS throttling my bandwidth when it's not in
Posted: Sat Mar 30, 2013 4:54 pm
by pbix
Was that traceroute made while the downlink was saturated?
Try a traceroute to other possible targets while saturating your downlink. Try
www.google.com. There has to be a queue out there somewhere in order to maintain such a high download speed.
Not sure what else to say. Packets (except strangely ping packets) are being dropped somewhere and this is only happening above 26000kbps.
How about the Modem's CPU? Perhaps you are maxing it out causing random packets to be dropped there.
In the worst case you can just set your limit to 26000kbps and make do.
Re: Can I avoid QoS throttling my bandwidth when it's not in
Posted: Sat Mar 30, 2013 5:03 pm
by rtlx
No that traceroute to WAN gateway was done when link wasn't saturated.
I tried to set ping target to the same host from where I download these test files. But sadly it didn't work. Here's a ping results of
NOT saturated link:
Code: Select all
PING ipv4.download.thinkbroadband.com (80.249.99.148): 56 data bytes
64 bytes from 80.249.99.148: seq=0 ttl=53 time=49.495 ms
64 bytes from 80.249.99.148: seq=1 ttl=54 time=50.577 ms
64 bytes from 80.249.99.148: seq=2 ttl=53 time=50.341 ms
64 bytes from 80.249.99.148: seq=3 ttl=54 time=53.570 ms
64 bytes from 80.249.99.148: seq=4 ttl=54 time=50.859 ms
64 bytes from 80.249.99.148: seq=5 ttl=54 time=49.586 ms
64 bytes from 80.249.99.148: seq=6 ttl=54 time=50.317 ms
64 bytes from 80.249.99.148: seq=7 ttl=53 time=49.343 ms
64 bytes from 80.249.99.148: seq=8 ttl=54 time=51.033 ms
64 bytes from 80.249.99.148: seq=9 ttl=54 time=54.037 ms
64 bytes from 80.249.99.148: seq=10 ttl=54 time=54.292 ms
64 bytes from 80.249.99.148: seq=11 ttl=53 time=50.308 ms
64 bytes from 80.249.99.148: seq=12 ttl=54 time=48.839 ms
64 bytes from 80.249.99.148: seq=13 ttl=54 time=51.040 ms
64 bytes from 80.249.99.148: seq=14 ttl=54 time=53.837 ms
64 bytes from 80.249.99.148: seq=15 ttl=54 time=50.813 ms
64 bytes from 80.249.99.148: seq=16 ttl=54 time=51.569 ms
^C
--- ipv4.download.thinkbroadband.com ping statistics ---
17 packets transmitted, 17 packets received, 0% packet loss
round-trip min/avg/max = 48.839/51.168/54.292 ms
Here is a result of saturated link:
Code: Select all
PING ipv4.download.thinkbroadband.com (80.249.99.148): 56 data bytes
64 bytes from 80.249.99.148: seq=0 ttl=54 time=59.664 ms
64 bytes from 80.249.99.148: seq=1 ttl=54 time=62.288 ms
64 bytes from 80.249.99.148: seq=2 ttl=54 time=62.798 ms
64 bytes from 80.249.99.148: seq=3 ttl=54 time=85.306 ms
64 bytes from 80.249.99.148: seq=4 ttl=53 time=55.709 ms
64 bytes from 80.249.99.148: seq=5 ttl=53 time=67.752 ms
64 bytes from 80.249.99.148: seq=6 ttl=54 time=66.527 ms
64 bytes from 80.249.99.148: seq=7 ttl=54 time=84.565 ms
64 bytes from 80.249.99.148: seq=8 ttl=53 time=65.108 ms
64 bytes from 80.249.99.148: seq=9 ttl=54 time=64.971 ms
64 bytes from 80.249.99.148: seq=10 ttl=54 time=62.889 ms
64 bytes from 80.249.99.148: seq=11 ttl=54 time=117.460 ms
64 bytes from 80.249.99.148: seq=12 ttl=53 time=56.021 ms
64 bytes from 80.249.99.148: seq=13 ttl=54 time=71.289 ms
64 bytes from 80.249.99.148: seq=14 ttl=54 time=63.600 ms
64 bytes from 80.249.99.148: seq=15 ttl=54 time=130.656 ms
64 bytes from 80.249.99.148: seq=16 ttl=54 time=65.685 ms
64 bytes from 80.249.99.148: seq=17 ttl=53 time=61.203 ms
64 bytes from 80.249.99.148: seq=18 ttl=54 time=65.735 ms
64 bytes from 80.249.99.148: seq=19 ttl=54 time=149.220 ms
64 bytes from 80.249.99.148: seq=20 ttl=54 time=57.076 ms
64 bytes from 80.249.99.148: seq=21 ttl=53 time=68.396 ms
^C
--- ipv4.download.thinkbroadband.com ping statistics ---
22 packets transmitted, 22 packets received, 0% packet loss
round-trip min/avg/max = 55.709/74.723/149.220 ms
Ping to Google.com when link is saturated:
Code: Select all
PING google.com (173.194.70.139): 56 data bytes
64 bytes from 173.194.70.139: seq=0 ttl=47 time=47.575 ms
64 bytes from 173.194.70.139: seq=1 ttl=47 time=60.256 ms
64 bytes from 173.194.70.139: seq=2 ttl=47 time=59.757 ms
64 bytes from 173.194.70.139: seq=3 ttl=47 time=58.676 ms
64 bytes from 173.194.70.139: seq=4 ttl=47 time=54.464 ms
64 bytes from 173.194.70.139: seq=5 ttl=47 time=53.539 ms
64 bytes from 173.194.70.139: seq=6 ttl=47 time=50.478 ms
64 bytes from 173.194.70.139: seq=7 ttl=47 time=59.433 ms
64 bytes from 173.194.70.139: seq=8 ttl=47 time=39.400 ms
64 bytes from 173.194.70.139: seq=9 ttl=47 time=47.302 ms
64 bytes from 173.194.70.139: seq=10 ttl=47 time=54.585 ms
64 bytes from 173.194.70.139: seq=11 ttl=47 time=49.812 ms
64 bytes from 173.194.70.139: seq=12 ttl=47 time=43.498 ms
64 bytes from 173.194.70.139: seq=13 ttl=47 time=59.851 ms
64 bytes from 173.194.70.139: seq=14 ttl=47 time=44.003 ms
64 bytes from 173.194.70.139: seq=15 ttl=47 time=58.954 ms
64 bytes from 173.194.70.139: seq=16 ttl=47 time=48.352 ms
64 bytes from 173.194.70.139: seq=17 ttl=47 time=57.041 ms
64 bytes from 173.194.70.139: seq=18 ttl=47 time=41.304 ms
64 bytes from 173.194.70.139: seq=19 ttl=47 time=63.287 ms
64 bytes from 173.194.70.139: seq=20 ttl=47 time=56.934 ms
64 bytes from 173.194.70.139: seq=21 ttl=47 time=50.035 ms
64 bytes from 173.194.70.139: seq=22 ttl=47 time=52.906 ms
64 bytes from 173.194.70.139: seq=23 ttl=47 time=53.624 ms
64 bytes from 173.194.70.139: seq=24 ttl=47 time=49.110 ms
^C
--- google.com ping statistics ---
25 packets transmitted, 25 packets received, 0% packet loss
round-trip min/avg/max = 39.400/52.567/63.287 ms
CPU seems fine (if the values on Overview page and top command are to belived)...
Here's /proc/cpuinfo
Code: Select all
cat /proc/cpuinfo
system type : Atheros AR9330 rev 1
machine : TP-LINK TL-WR741ND v4
processor : 0
cpu model : MIPS 24Kc V7.4
BogoMIPS : 265.42
wait instruction : yes
microsecond timers : yes
tlb_entries : 16
extra interrupt vector : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
ASEs implemented : mips16
shadow register sets : 1
kscratch registers : 0
core : 0
VCED exceptions : not available
VCEI exceptions : not available
On a side note one thing that boggles my mind is why can't I set expected speed of WAN port and let router distribute the bandwidth according the rules. But that's probably because I don't understand the inner workings of the QoS...
Re: Can I avoid QoS throttling my bandwidth when it's not in
Posted: Sat Mar 30, 2013 5:34 pm
by pbix
rtlx wrote:N
On a side note one thing that boggles my mind is why can't I set expected speed of WAN port and let router distribute the bandwidth according the rules. But that's probably because I don't understand the inner workings of the QoS...
Well if you don't set it too high you can do exactly that which is what you have been doing.
I can see that the ping times do increase a little as we increase speeds.
Looks to me like if you used the default as your ping target and set a custom ping limit of 35ms you will get ACC operation and an automatic speed limit. That seems to be the best we can do in your situation using the ACC.
The advantage of using the ACC is that if the download slows down say on a busy day when your ISP is overloaded it get taken care of automatically.
Re: Can I avoid QoS throttling my bandwidth when it's not in
Posted: Sat Mar 30, 2013 7:00 pm
by rtlx
Well, problem of ACC in my situation is that my download speed is quite stable. BUt once I'd start uploading anything ping goes skyhigh up to 200ms or so. ACC would then immediately drop download speed but not fix high ping times. So in my situation it'd be better if ACC adjusted upload speed instead of download speed.
Anyway I'm trying it now with ping limit of 35 and so far it looks like it's working, but as a result it set my link speed to around 24800Kbps.
Re: Can I avoid QoS throttling my bandwidth when it's not in
Posted: Sun Mar 31, 2013 8:56 am
by pbix
You can increase the ping target until you see that QoS no longer functions correctly and maybe get a little more speed. But if you are certain your download speed will not vary then you do not need the ACC. Just set the downlink speed as high as you can and still have QoS work.
Your correct that the ACC does not manage the uplink but again if you think your link is stable it would not help you in any case. If your ping times are getting too high then crank back your upload speed until they are acceptable. But a 200ms ping is not that bad under full load.