Re: [LARTC] Why does scp stall on low bandwidth connections?

[Nikolay Kichukov <hijacker@oldum.net>]

Hello Andy,
Is that line:
tc filter add dev eth0 parent 1:0 protocol ip prio 2 u32 match u32 0 0
flowid 1:2

not equal to:
tc qdisc add dev eth0 root handle 1:0 htb default 2

in terms of achieved results? If not, what is the difference?

Thanks,
-Nikolay

Andy Furniss wrote:
> 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@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc