From owner-freebsd-performance@FreeBSD.ORG Sun Mar 19 00:48:01 2006 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 693D116A400 for ; Sun, 19 Mar 2006 00:48:01 +0000 (UTC) (envelope-from g_jin@lbl.gov) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by mx1.FreeBSD.org (Postfix) with SMTP id 09C6543D46 for ; Sun, 19 Mar 2006 00:48:00 +0000 (GMT) (envelope-from g_jin@lbl.gov) Received: (qmail 62692 invoked from network); 19 Mar 2006 00:48:00 -0000 Received: from unknown (HELO ?192.168.2.10?) (jinmtb@sbcglobal.net@68.127.172.58 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 19 Mar 2006 00:47:59 -0000 Message-ID: <441CAA8D.3020308@lbl.gov> Date: Sat, 18 Mar 2006 16:49:17 -0800 From: "Jin Guojun [VFFS]" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050108 X-Accept-Language: zh, zh-CN, en MIME-Version: 1.0 To: OxY , Chuck Swiger X-Priority: 3) References: <000a01c64a81$45eb6850$0201a8c0@oxy> <441BF838.1080600@mac.com><000601c64a87$51d7dee0$0201a8c0@oxy> <441BFF26.90807@mac.com> <000e01c64a8f$1b2bec80$0201a8c0@oxy> In-Reply-To: <000e01c64a8f$1b2bec80$0201a8c0@oxy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 19 Mar 2006 01:23:40 +0000 Cc: freebsd-performance@freebsd.org Subject: Re: packet drop with intel gigabit / marwell gigabit X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2006 00:48:01 -0000 It is still not clear how you did measurement. Did FTP show such % drop? or Did you measure it by other tools? How did you measured incoming traffic? http://field.hu/netstat.txt shows 0 tcp packet drop. Anyway, the first thing first is to have CPU utilization when you see packet drop. This can be get from running "top" or "vmstat 1". As well as run netstat -i -p tcp | grep -i drop If CPU utilization is approaching 100%, either the traffic is no 2 MBps, or some process is taking CPU time. For this reason, "top" is a better tool to use. At this point, if you run netstat command multiple times, you would see drop counter increasing. Once you find out what process takes CPU time, then further tuning can be determined. If CPU utilization is well below 70-80%, then you need to use tcpdump and tcptrace to visualize what cause packet drop, then perform a solution. Jin ----- Original Message ----- From: "OxY" To: "Chuck Swiger" Cc: Sent: Saturday, March 18, 2006 2:23 PM Subject: Re: packet drop with intel gigabit / marwell gigabit > currently i use HZ=2000 > here's the output of netstat -i, -s, and vmstat -i : > (currently i am uploading on the gigabit with ftp, 3 threads) > > Field root# vmstat -i > interrupt total rate > irq0: clk 27503959 1993 > irq1: atkbd0 1 0 > irq3: fxp0 2 0 > irq7: 146 0 > stray irq7 146 0 > irq8: rtc 1765569 127 > irq10: atapci1 2807786 203 > irq11: atapci0 475039 34 > irq13: npx0 1 0 > irq14: ata0 99 0 > Total 32552748 2359 > > Field root# netstat -i > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs > Coll > fxp0 1500 00:a0:c9:8d:79:68 13163545 0 21899372 1 > 0 > fxp0 1500 195.38.96.64/ field 141 - > 6 - - > em0 1500 00:0e:0c:a2:ac:42 68644181 4 66793904 0 > 0 > em0 1500 195.38.96.64/ field 211255811 - > - - > lo0 16384 129622061 0 129622061 > 0 0 > > netstat -s is here: > http://field.hu/netstat.txt > > ----- Original Message ----- > From: "Chuck Swiger" > To: "OxY" > Cc: > Sent: Saturday, March 18, 2006 1:37 PM > Subject: Re: packet drop with intel gigabit / marwell gigabit > > >> OxY wrote: >>> yeah, i googled these settings, but i put them back to default then! >>> i measured iperf performance, and it showed that the packet drop is >>> depending on the system load.. >> >> If you are using the normal interrupt-driven configuration, you should >> look at >> netstat -i, -s, and vmstat -i. If you're turning on device polling, you >> ought >> to retry your testing at higher HZ (try 2000 or 5000): >> >> echo 'kern.hz="2000"' >> /boot/loader.conf >> >> -- >> -Chuck