BT issue

[george13]

Hi,

Since recently I'm having a serious issue with bittorrent downloads, and having a bandwidth of 25 Mbps down and 10 Mbps up, I'm lucky if I can get 10 kB/s down for torrents with 4000+ seeds. The problem occurs both on my win 8.1 PC and my Synology DS412+ (with link aggregation), and so this points at a block, or by the ISP, or by the RT AC66U.
Running the Glasnost test (port 6881), to check if the ISP is at cause, I however get a negative result, and download speeds of about 600 kB/s are found. I'm however not 100% sure if this points at the router as possible cause, and I am running the latest Merlin build, 3.0.0.4.374.35_4. The confirmation came however after replacing the Asus with a Syslink E4200, which gives me the normal download rates.
One detail, although I'm not sure why this would play a role for the Asus and not for the Syslink, is that I am on a satellite connection, with about 600 ms latency.
I would be extremely interested to know if other people have similar issues, or if there might be a setting for the Asus which I have skipped. And by the way, the Download Master on the Asus is not installed, which excludes port conflicts.
Ports used are 6881:6889 for my PC and 16881:16889 for the NAS, and they are open. I've tried alternative ports, but the result is the same.

 

[sinshiva]

heya

forwarding both tcp and udp for BT? it looks like you're trying to forward a range, which should work, but have you tried individual ports?

definitely in the port forwarding menu as compared to port triggering?

perhaps try disabling 'hw acceleration'; is your sat link pppoe?

how is everything else over the sat link? have you successfully forwarded any other ports on the asus?

[edit/] how are you connected to the asus router?

 

[george13]

Hi,

I have never had any issues in forwarding individual ports, or port ranges. For the BT, I have tried to have the range defined as "Both", and have tried half of the range for TCP and the other half for UDP, and done the same with individual ports, but it doesn't make any difference.
The satellite ... only one recommendation, and that is to stay away from it. UDP is no problem, but for TCP you have to multiply the latency with a factor of 4 (signal + acknowledge)x2, and that is the delay, for example when you open a link. There are of course tricks, such as sensing a follow up signal before the acknowledge is received, but there remains a limit to what you can recover in speed, and it holds risks for errors.
The providers of course never talk to you about the latency, and when people see a bandwidth advertised which is >20Mbps, then they jump on it. Doing a speed test indeed gives for me about 25 Mbps down and at least 10 Mbps up, but it doesn't mean anything. It is the latency that is dominant and I can tell you that my effective speed is less that that of an old 56k modem. But, I have no other options in the area where where I live, which is at only 15 minutes from downtown the 2nd biggest city in the France.
The connection: ViaSat modem which is taking care of the WAN side of the Asus.

 

[george13]

I may have found an issue. In running a end-to-end path analysis, I found that there is packet queuing, and this might lead to the slow speeds. The question however is, what is causing the queuing and how do I resolve it?
And of course, why do I not find the same problem for the Linksys router.

 

[sinshiva]

some things to try;

a lot of network cards now have things like 'tcp offloading', etc. you might try and configure the network card to disable these functions

your wan MTU might need to be specified, perhaps check what the working router had and maybe verify with the ISP.

sorry you have to deal with that latency, that would kill me

 

[RMerlin]

Do a standard speed test from speedtest.net. If the speed is fine, then it's possible that your ISP is throttling bittorrent traffic.

Also doublecheck your bittorrent client's settings to ensure you aren't limiting your upload or download speed at incorrect values.

 

[george13]

Do a standard speed test from speedtest.net. If the speed is fine, then it's possible that your ISP is throttling bittorrent traffic.

Also doublecheck your bittorrent client's settings to ensure you aren't limiting your upload or download speed at incorrect values.

Thank you, but as I mentioned, speed test gives me at least 25 Mbps down and 12 Mbps up, so is perfect. And as I mentioned, I did the Glasnost test, and it showed that the ISP is not touching the bittorrent traffic at port 6881, and what is weird is that Glasnost found a bittorrent download speed of 600 kbps on port 6881, and approx. 150 kbps up.

If it was the bittorrent client, than you would expect that my NAS, using its own client, would not have the same issue, but it does.

I ran another test, using the BitMate (Vuze variant), and I got the following report:

Pausing downloads before performing test...................................................
TCP/Web100 Network Diagnostic Tool v3.6.2b
** Starting test 1 of 1 **
Connecting to 'ndt.iupui.donar.measurement-lab.org' [ndt.iupui.donar.measurement-lab.org/197.136.0.101] to run test
Connected to: ndt.iupui.donar.measurement-lab.org-- Using IPv4 address
Checking for Middleboxes . . . . . . . . . . . . . . . . . .
Done.
Checking for firewalls . . . . . . . . . . . . . . . . . . .
Done.
running 10s outbound test (client-to-server [C2S]) . . . . .
191.0kb/s
running 10s inbound test (server-to-client [S2C]) . . . . . .
867.30kb/s
The slowest link in the end-to-end path is a
a 622 Mbps OC-12 subnet
Information: Other network traffic is congesting the link
[C2S]: Packet queueing detected
Completed: up=23.3 kB/s, down=105.9 kB/s

These tests all give acceptable results, whereas reality is different. And again, there is the packet queuing.

I may be wrong, but I assume that using TCP, packets would be put in a queue if the router is waiting for an acknowledgement. If that is the case, then you would expect a faster transport if the MTU is increased. I did do the standard test to optimize the MTU size, and this gave 1500, which is a value that everyone uses. For a larger MTU, I was getting errors.
So there must be something else playing a role, but what?

 

[sinshiva]

well, it's quite probable that you might have an MTU less than 1500, which is why i suggested asking the ISP about it. Using the correct MTU, despite being lower, can lead to significant performance gains, if this is indeed contributing to your troubles. I'm not familiar with satelite, but i am pretty sure 1500 isn't an optimal MTU for that particular link

 

[george13]

I just found some interesting info of how to limit the queuing:
TCP Small Queues
and
Design Best Practices for Latency Optimization

This paragraph might give a hint:
When packets are coming into a router faster than they can leave, you will have queuing. The best way to avoid packet-queuing latency is to avoid congestion. This translates into over-engineering your network to handle traffic bursts. When some level of congestion is inevitable then QoS methods such as Low-Latency Queuing (LLQ) should be used. In converged networks—with many different traffic types—market data must be integrated into the overall QoS strategy.

Taking into account the latency (distance earth-satellite/speed of light) I would however turn this around and say that packets leaving the router faster than they can be acknowledged by the end point will cause output queuing.

The question now is, how can this be taken care of with the Asuswrt_merlin?

 

[george13]

well, it's quite probable that you might have an MTU less than 1500, which is why i suggested asking the ISP about it. Using the correct MTU, despite being lower, can lead to significant performance gains, if this is indeed contributing to your troubles. I'm not familiar with satelite, but i am pretty sure 1500 isn't an optimal MTU for that particular link

Thank you, and I have the same feeling. There must be an optimum. Are the packets too small, then the data amount becomes negligeable compared to the fixed header size and other info send with each packet. I remember a software tool to optimize the connection, MTU, TTL, ... If I remember right was called Connection Booster or something like that. Will check if it still exists and give that a try.

 

[sinshiva]

i believe this is what you are looking for

good luck

 

[george13]

Something weird. Just to see what it would do, I changed the MTU from 1500 to 1480, and I did gain 10kB/s in bandwidth. However, since the change, I am unable to open the router's GUI. I need to reboot the router, and then I have access. The GUI askes me for login info, and next, it simply keep spinning with a blank page, no message at all.
How can the MTU be related to access to the web GUI? I'm lost.

 

[george13]

I changed the MTU back to 1500, but the problem remains. And a new issue. I cannot access the USB drive connected to the RT AC66U anymore. Windows gives me the message "insufficient resources". And that with only 4GB out of 16GB of memory used.
Any advice please?

 

[sinshiva]

Something weird. Just to see what it would do, I changed the MTU from 1500 to 1480, and I did gain 10kB/s in bandwidth. However, since the change, I am unable to open the router's GUI. I need to reboot the router, and then I have access. The GUI askes me for login info, and next, it simply keep spinning with a blank page, no message at all.
How can the MTU be related to access to the web GUI? I'm lost.

hey, you'll need to adjust the MTU of devices connected to the router.

for windows, from cmd;

netsh interface ipv4 show subinterfaces (to get int names, etc)
netsh interface ipv4 set subinterface "Local Area Connection" mtu=1480 store=persistent

usually for wired, or

netsh interface ipv4 set subinterface "Wireless Network Connection" mtu=1480 store=persistent

usually for wireless interfaces.

i'd keep testing lower MTUs. as long as you dont use xbox live, you should be able to drop it to whatever works best. XBL requires a minimum of 1356 or something like that. not that you'd be playing with 600ms, but there you have it

 

[george13]

Have still no solution for the slow bittorrent speeds. For my NAS I found an optimum at 1470, but ... the NAS is preprogrammed for 1500, 3000, ... 8000 and am waiting for response from tech support as how to do it. It must be simple though as from brosing through the /etc/rc I noticed that the case of an MTU smaller than 12500 is foreseen, so if necessary, I'll simply modify the script.
I did have something weird yesterday. The download ran at about 10 kB/s when suddenly it went up to 3MB/s, and the download finished in a flash. I have however not been able to copy this to other downloads. The fact that 3 MB/s is feasable with the MTU that is used hints in a different direction, but which one?
Does anyone have any idea?

 

[sinshiva]

how large was the file and what type? is there any compression going on with the sat link ?

have you tried using a vpn service over the sat link?

 

[george13]

The file was about 7.5 GB and I was at about 30% after several days, when the change suddenly happened. The number of seeders was over a 1000.

 

[george13]

Am using VPN, and once connected is ok. Everything turns around the 750 ms latency.