Re: Why does scp stall on low bandwidth connections?

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Marc wrote:
Hi,

I am new to tc and have been reading quite a bit on how to set it up etc.
Everything seems to be working fine, until I started scp-ing a large file
over a low bandwidth connection as part of my testing process.

Here is the setup:
my pc --- bridge running tc/htb --- rest of network

TC is filtering traffic from "my pc" and classifies it as 120kbit (see my
script below). I then scp a 5MB file from a server in "rest of network" to
"my pc". Everything seems to work fine and copies at a speed of around
12KB/s, which is what I would expect from a 120kbit connection. At some
stage scp stalls and eventually disconnects or I get bored and press
<Ctrl>+C. The stage at which it stalls is different every time. First it was
at 76% of the copy progress, then at 32% of the copy progress.

For my testing purposes, there is no other traffic flowing through either
this class or any other class. My expectation was that it would copy the
entire file, just at a low speed. I expected to be able to copy a 600MB file
at 12KB/s, which would of course be very slow, but eventually arrive.

Here are the rules I specified, note that "my pc" does *not* have the ip
address 10.0.2.42 in the test desribed above:

#eth0 qdisc
tc qdisc add dev eth0 root handle 1:0 htb default 2
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 10mbit ceil 10mbit
tc class add dev eth0 parent 1:1 classid 1:2 htb rate 120kbit ceil 120kbit
tc class add dev eth0 parent 1:1 classid 1:3 htb rate 200kbit ceil 1mbit

#eth1 qdisc
tc qdisc add dev eth1 root handle 2:0 htb default 2
tc class add dev eth1 parent 2:1 classid 2:2 htb rate 120kbit ceil 120kbit
tc class add dev eth1 parent 2:1 classid 2:3 htb rate 200kbit ceil 1mbit

#eth0 filter
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip src
10.0.2.42 flowid 1:3

#eth1 filter
tc filter add dev eth1 parent 2:0 protocol ip prio 1 u32 match ip dst
10.0.2.42 flowid 2:3

Thank you for your comments on this situation.

It's probably because arp is being sent to 1:2 which is backlogged. Try not using the default parameter and instead use a catch all ip tc filter
like -

tc filter add dev eth0 parent 1:0 protocol ip prio 2 u32 match u32 0 0 flowid 1:2

You could also consider adding p/bfifos to the classes and use the limit parameter to make the queues shorter. At low bitrates the default 1000pkts (picked up from the queuelen on eth) is too long.

Andy.
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux