debugging low transfer speed

[Thomas Klausner]

Hi!

In the following setup:

host1 - firewall - INTERNET - firewall - firewall - host2
|
host3

When I use scp or rsync from host1 to host3, I get ~300kb/s.
host2 to host3 is at 1MB/s or more.
host1 to host2 gives me ~30kb/s.

When I pipe data via host3 to host2, I get 300kb/s as well.

host1 is NetBSD-6.99.15/amd64; host2 is NetBSD-5.99.40/amd64; host3 is
some Linux 2.6.26/amd64.

What could be the cause that the direct connection between host1 and
host2 is so much slower? How can I debug it? How can I change it?

Thanks,
Thomas

(Please Cc me.)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

To debug things like this, I know of only one truly effective way, and
it's a little involved.

1) While doing transfers, capture tcpdumps of them (all TCP packets) at
each end. Having both lets one separate an endpoint not sending a
packet from the packet not arriving at the other.

2) Install xplot (in pkgsrc), and use tcpdump2xplot. Read the
explanation in the xplot sources. Read all the TCP congestion-control
RFCs. Analyze the plots to see what's wrong.

But seriously, step 2 isn't that hard, if your problem is not that
subtle.

I am happy to look at the plots, if you want to provide either the raw
tcpdump files or the tcpdump2xplot output.

[Lloyd Parkes]

Post by Greg Troxel
To debug things like this, I know of only one truly effective way, and
it's a little involved.
1) While doing transfers, capture tcpdumps of them (all TCP packets) at
each end. Having both lets one separate an endpoint not sending a
packet from the packet not arriving at the other.

I also take packet captures on all relevant interfaces of all firewalls on the path. I don't feed those firewall captures into xplot because I'm not an xplot wizard like Greg, but I use them to track down issues I may see at one end of the connection, but not the other. Some firewalls will proxy connections through them, even if it's only a TCP proxy. If the sequence numbers for the TCP stream of interest in both endpoint packet captures don't match, then one or more of your firewalls is proxying the connection.

I've seen a commercial firewall whose stateful packet inspection system didn't handle window scaling, but the Linux kernel it was running on always attempted to use window scaling when parodying connections. I'm a little bit twitchy about firewalls misbehaving now.

Cheers,
Lloyd


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de