It's probably not disk related since iperf is also showing symptoms. That being said, I'm out of clues for the moment.
Good luck and keep up posted! Guido On Fri, Apr 12, 2013 at 7:27 AM, emmanuel segura <emi2f...@gmail.com> wrote: > Hello Jhon > > With read test i mean dd or others tools > > Thanks > > > 2013/4/12 John Elliot <johnellio...@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: emi2f...@gmail.com >> To: johnellio...@hotmail.com >> CC: mtzgu...@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 <johnellio...@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: emi2f...@gmail.com >> To: johnellio...@hotmail.com >> CC: mtzgu...@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 <johnellio...@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: mtzgu...@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: johnellio...@hotmail.com >> > CC: debian-user@lists.debian.org >> >> > >> > On Fri, Apr 12, 2013 at 1:16 AM, Guido Martínez <mtzgu...@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-requ...@lists.debian.org >> > with a subject of "unsubscribe". Trouble? Contact >> > listmas...@lists.debian.org >> > Archive: >> > http://lists.debian.org/CA++DQUnEPW=oEAHY02MPSXihm-FpoAC3ddYOA0+m=vk...@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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CA++DQUmdEaZ9zwoRM_hP96eoB2YPewHQxK1onNA=H=rmrmw...@mail.gmail.com
