Thanks for the reply:
ss results (wget in "bad" direction):
"Receiver" - Recv and Send does not change from "0":ESTAB 0 0
192.168.123.1:32815
192.168.123.2:www
"Sender" - snapshots below:State Recv-Q Send-Q
Local Address:Port
Peer Address:Port ESTAB 0 505352
192.168.123.2:www
192.168.123.1:32816
ESTAB 0 522728
192.168.123.2:www
192.168.123.1:32816
ESTAB 0 328696
192.168.123.2:www
192.168.123.1:32816
In the other direction:
Reciever:ESTAB 0 0 192.168.123.2:33036
192.168.123.1:www
Sender:ESTAB 0 535760 ::ffff:192.168.123.1:www
::ffff:192.168.123.2:33038 ESTAB 0 383720 ::ffff:192.168.123.1:www
::ffff:192.168.123.2:33038 ESTAB 0 474944
::ffff:192.168.123.1:www ::ffff:192.168.123.2:33038
Date: Fri, 12 Apr 2013 10:06:38 +0200
Subject: Re: iperf / ftp / http TCP poor performance in one direction (UDP good)
From: [email protected]
To: [email protected]
CC: [email protected]; [email protected]
Hello
Maybe it can the the disks write speed, anayway you can use netstat or ss
look for Recv-Q Send-Q columns
2013/4/12 John Elliot <[email protected]>
Thanks again for your help with this.
I've run 500 pings (-c 500 -i 0) in both directions, and got zero loss.
Ill try running tcpdump on both servers, and re-testing to check the segments.
Swapping the servers would be extremely difficult ;) (They are over 1000k's
apart, and one is in an unmanned(majority of the time) data centre.
> From: [email protected]
> Date: Fri, 12 Apr 2013 01:38:40 -0300
> Subject: Re: iperf / ftp / http TCP poor performance in one direction (UDP
> good)
> To: [email protected]
> CC: [email protected]
>
> On Fri, Apr 12, 2013 at 1:16 AM, Guido Martínez <[email protected]> wrote:
> > Did you check if A acknowledges every received segment?
> Sorry, what I meant by this is if every sent segment from B reaches A.
> You can run an instance of wireshark on each host to check this.
> Basically you need to check for packet loss at high speeds (ping could
> be of use if you set the interval to 0).
>
> TCP Dup ACKs are likely caused by packet loss.
> TCP segment of a reassembled PDU is something Wireshark adds since it
> interprets a bit about application layer protocols, and I think it's
> not a reason to worry (I could have understood this wrong, I just
> looked it up).
>
> If it's easy, you could also try swapping the location of the hosts,
> to see if the problem is on the hosts, or on the link.
>
> Hope it helps and post more info if you find any.
> Guido
>
>
> --
> To UNSUBSCRIBE, email to [email protected]
> with a subject of "unsubscribe". Trouble? Contact [email protected]
> Archive:
> http://lists.debian.org/[email protected]
>
--
esta es mi vida e me la vivo hasta que dios quiera
