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

Re: iperf / ftp / http TCP poor performance in one direction (UDP good)



Hello Jhon

With read test i mean dd or others tools

Thanks


2013/4/12 John Elliot <johnelliot67@hotmail.com>
Hi - What do you mean by "read test"?  hdparm?

hdparm -tT /dev/sda1

/dev/sda1:
 Timing cached reads:   8412 MB in  2.00 seconds = 4207.53 MB/sec
 Timing buffered disk reads: 190 MB in  1.94 seconds =  97.96 MB/sec

# hdparm -Tt /dev/sda3

/dev/sda3:
 Timing cached reads:   7400 MB in  2.00 seconds = 3703.93 MB/sec
 Timing buffered disk reads: 186 MB in  3.02 seconds =  61.58 MB/sec


ftp (With ss)

ESTAB      0      477840   ::ffff:192.168.123.2:ftp-data   ::ffff:192.168.123.1:51161   
ESTAB      0      360552   ::ffff:192.168.123.2:ftp-data   ::ffff:192.168.123.1:51161  

And results (Similar to iperf):

ftp> get 64Mb.zip
local: 64Mb.zip remote: 64Mb.zip
200 PORT command successful
150 Opening BINARY mode data connection for 64Mb.zip (67108864 bytes)
226 Transfer complete
67108864 bytes received in 42.11 secs (1556.2 kB/s)







Date: Fri, 12 Apr 2013 11:08:23 +0200

Subject: Re: iperf / ftp / http TCP poor performance in one direction (UDP good)
From: emi2fast@gmail.com
To: johnelliot67@hotmail.com
CC: mtzguido@gmail.com; debian-user@lists.debian.org

Hello John

Try to do read test on the sender, if you don't find any read problem try to do a transfer using ftp

Thanks


2013/4/12 John Elliot <johnelliot67@hotmail.com>
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: emi2fast@gmail.com
To: johnelliot67@hotmail.com
CC: mtzguido@gmail.com; debian-user@lists.debian.org


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 <johnelliot67@hotmail.com>
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: mtzguido@gmail.com
> Date: Fri, 12 Apr 2013 01:38:40 -0300
> Subject: Re: iperf / ftp / http TCP poor performance in one direction (UDP good)
> To: johnelliot67@hotmail.com
> CC: debian-user@lists.debian.org

>
> On Fri, Apr 12, 2013 at 1:16 AM, Guido Martínez <mtzguido@gmail.com> 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 debian-user-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: http://lists.debian.org/CA++DQUnEPW=oEAHY02MPSXihm-FpoAC3ddYOA0+m=VkeQg@mail.gmail.com
>



--
esta es mi vida e me la vivo hasta que dios quiera



--
esta es mi vida e me la vivo hasta que dios quiera



--
esta es mi vida e me la vivo hasta que dios quiera

Reply to: