> I try to make some research on the network slowdown problem, which was
> reported from some people. In some case the shutoff of tcp_timestamps
> was helping, but in other cases not. I don't saw this problem on my
One problem with timestamps is that it sometimes ignores reordered acks.
> machine up to now, but during some test I saw other strange things.
> I the moment I run 2.2.13pre7 (+ ISDN from 2.2.13pre8) but the
> same was under plain 2.2.12.
> Here a short description of my "test bench":
>
> I make uploads with scp (a ~400K .gz file) over a 64k rawip ISDN line
> rate is about 6.6K/s (not optimum, but reliable). The strange things are
> the observation on begin and end of the transmit, which I don't understand.
>
> the statistics from scp shows following:
>
> 1-2 sec after start 140-160K are transfered
This sounds bogus.
> after ~35 sec the transfer is 100%
> after ~60 sec the transfer is finished (I got the prompt back).
>
> a netstat -c -t shows allways 40k-60K in Send-Q
>
> the 40k-60K in Send-Q came from a (too big I know) dev->tx_queue_len
> value in the ISDN network devive, but where are the other 100K ?
Normally in the TCP retransmit queue, but that should be really shown
in netstat. I guess scp's display is buggy.
> If I try to change tx_queue_len with ifconfig, it don't change anything,
> only the new value is displayed in ifconfig.
It does not attempt to shorten a too long queue, it'll only drop new packets
that would exceed the queue limit.
> This is no problem for me, because the allover rate is OK here, but I like
> to understand where and why so much data is buffered somewhere, because
> I believe that this may have something to do with the other problem
> (network slowdown). With this problem one people saw following:
The data is buffered by TCP when it does not get any ACKs back. When
some flow control problem (probably at driver level) prevents TCP from
seeing the ACKs it'll not free the retransmit queue.
> Networking over an sync ppp ISDN line slows down, a ping freezed.
> He started tcpdump on the interface and saw that no packets are going out.
> netstat shows data in Send-Q. The ISDN is open and idle.
> He was starting a second ping and now pakets are going out, but also from the
> old ping every second, so I suspect somewhere a queue or buffer is blocked.
This sounds like the device has dev->tbusy set.
Could you repeat your tests which something that has a trustworthy
progress display?
-Andi
-- This is like TV. I don't like TV.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/