From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 17 14:11:11 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71DAE16A4CE for ; Thu, 17 Jun 2004 14:11:11 +0000 (GMT) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13E1043D45 for ; Thu, 17 Jun 2004 14:11:11 +0000 (GMT) (envelope-from tillman@seekingfire.com) Received: by mail.seekingfire.com (Postfix, from userid 500) id CBECD381; Thu, 17 Jun 2004 08:10:08 -0600 (CST) Date: Thu, 17 Jun 2004 08:10:08 -0600 From: Tillman Hodgson To: freebsd-sparc64@freebsd.org Message-ID: <20040617141008.GN76337@seekingfire.com> References: <20040616034520.GB7887@kt-is.co.kr> <20040616234258.A95312@ra.aabs> <20040617064935.GB11797@kt-is.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040617064935.GB11797@kt-is.co.kr> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-GPG-Key-ID: 828AFC7B X-GPG-Fingerprint: 5584 14BA C9EB 1524 0E68 F543 0F0A 7FBC 828A FC7B X-GPG-Key: http://www.seekingfire.com/gpg_key.asc X-Urban-Legend: There is lots of hidden information in headers User-Agent: Mutt/1.5.6i Subject: Re: TCP/UDP cksum offload on hme(4) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2004 14:11:11 -0000 On Thu, Jun 17, 2004 at 03:49:35PM +0900, Pyun YongHyeon wrote: > I can't saturate the wire with/without my patch.(For TCP without > witness it was about 67Mbps. On OpenBSD I got about 93Mbps.) > I vaguely guess the reason was caused by hme's lack of > auto-negotiation. That seems odd to me ... on my Ultra 5 (with 5 hme ports) running -current as of April 16, I recently ran some IPsec vs clear transmission tests: Ultra 5, clear transmission: [root@caliban /usr/local/netperf]# ./netperf -t UDP_STREAM -H athena UDP UNIDIRECTIONAL SEND TEST to athena : histogram Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 9216 9216 10.01 13004 13160 95.81 42080 10.01 12778 94.14 Ultra 5, with 3des: [root@caliban /usr/local/netperf]# ./netperf -t UDP_STREAM -H secathena UDP UNIDIRECTIONAL SEND TEST to secathena : histogram Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 9216 9216 10.01 715 0 5.27 42080 10.01 713 5.25 Ultra 5n, with blowfish: [root@caliban ~]# /usr/local/netperf/netperf -t UDP_STREAM -H secathena UDP UNIDIRECTIONAL SEND TEST to secathena : histogram Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 9216 9216 10.01 14744 0 108.63 42080 10.01 3681 27.12 (108, greater than 100mbit max, is due to using 'deflate' compression algorithm) (Oh, and the moral of the story is that blowfish rocks when usign IPsec in transport mode :-)) This was testing a UDP stream (simulating my UDP NFS exports) to an x86 NFS file server runing -STABLE with the a gigabit interface. They were connected through a D-link 1026G switch, and auto-negotiation was used. -T -- Zen is the unsymbolization of the world. R.H. Blyth