It certainly looks that way. It most likely cpu or nic related and not something you could fix by tweaking the system...
Guido On Tue, Apr 16, 2013 at 12:50 AM, John Elliot <johnellio...@hotmail.com> wrote: > Ok - Just an update to this. > > Connected a Laptop to the same switch the Deb server is connected to @ POPB > - The Laptop was able to achieve acceptable performance: > > POPA -> POPB (FTP) - ~36Mb/sec > POPB -> POPA (FTP) - ~30Mb/sec (The link is currently in use, so there is > some background traffic so this speed is ok) > > Also connected the Laptop to the same port the Deb server is connected to @ > POPB, and achieved the same results as above. > > So it is looking like the Deb server @ POPB is the cause... > > > > > > >> From: mtzgu...@gmail.com >> Date: Fri, 12 Apr 2013 09:55:12 -0300 > >> Subject: Re: iperf / ftp / http TCP poor performance in one direction (UDP >> good) >> To: debian-user@lists.debian.org > >> >> 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=rmrmw...@mail.gmail.com >> -- 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++DQU=oy6rffvmj-mx1cuzxcadgg84u85kfakwj0wogtct...@mail.gmail.com
