From owner-freebsd-net@FreeBSD.ORG Sun Oct 9 06:20:43 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DB8216A41F for ; Sun, 9 Oct 2005 06:20:43 +0000 (GMT) (envelope-from vulture@netvulture.com) Received: from rackman.netvulture.com (adsl-63-197-17-60.dsl.snfc21.pacbell.net [63.197.17.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2531343D45 for ; Sun, 9 Oct 2005 06:20:40 +0000 (GMT) (envelope-from vulture@netvulture.com) Received: from [192.168.2.119] (LAPMAN.inside.netvulture.com [192.168.2.119]) (authenticated bits=0) by rackman.netvulture.com (8.13.5/8.13.5) with ESMTP id j996KQWN016987 for ; Sat, 8 Oct 2005 23:20:35 -0700 (PDT) Message-ID: <4348B6AF.8020207@netvulture.com> Date: Sat, 08 Oct 2005 23:20:31 -0700 From: Jonathan Feally User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact your system administrator for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-2.82, required 2.5, ALL_TRUSTED -2.82) Subject: Having issues with bridging vlan and em in 5.4-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2005 06:20:43 -0000 I'm trying to setup a machine that will be both routing traffic and bridging 2 segments of one network with ipfw processing on that bridged network. The routing seems to be OK and bridging is also OK from Side to side, however when trying to talk to the IP of the machine from another machine on the bridged network i am seeing packet loss. Setup em0 x.y.199.254 connected to segment with outgoing router at x.y.199.1. Lets call this Side A em1 no IP. Internal interface with all the vlans attached to it vlan199 no IP configured as tagged vlan 199 attached to em1. We'll call this Side B. 10 more vlans configured with IP's for the routing portion. No packet loss in the routed scenario. em0 and vlan199 are bridged Host at x.y.199.101 connected to Side B can reach all hosts connected to Side A except for the bridging machine Using nslookup on .101 to .254 as a test, tcpdump on vlan199 shows packets in from .101 to .254 and the returning packets from .254 to .101. em0 does not show any packets in or out. However packets are not being returned to the .101 host. IPFW is not a culprit here as I have tried it with ipfw add 1 allow ip from any to any. Moving the IP of .254 from em0 to vlan199 results in the same packet loss execpt on the Side A now. Not all traffic from Side B to .254 and back is lost. dhcp and icmp do seem to be working. I am leaning towards an issue with BIND, however it does bother me that tcpdump sees packets leaving vlan199. Anybody have any ideas?? Thanks in advance. -Jon From owner-freebsd-net@FreeBSD.ORG Sun Oct 9 15:27:26 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F9E316A41F for ; Sun, 9 Oct 2005 15:27:26 +0000 (GMT) (envelope-from jan@melen.org) Received: from foxgw.melen.org (Savi-Mel.dna.fi [83.143.60.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6D4043D46 for ; Sun, 9 Oct 2005 15:27:25 +0000 (GMT) (envelope-from jan@melen.org) Received: from 4.2.168.192.in-addr.arpa ([192.168.2.4]) (authenticated bits=0) by foxgw.melen.org (8.13.4/8.13.4) with ESMTP id j99FRAks016257 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 9 Oct 2005 18:27:22 +0300 (EEST) (envelope-from jan@melen.org) From: Jan Mikael Melen To: freebsd-net@freebsd.org Date: Sun, 9 Oct 2005 18:27:03 +0300 User-Agent: KMail/1.8.2 References: <200509251353.j8PDr5XE005907@lurza.secnetix.de> <200509271107.37830.jan@melen.org> In-Reply-To: <200509271107.37830.jan@melen.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200510091827.03988.jan@melen.org> Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on foxgw.melen.org X-Virus-Status: Clean Subject: Kernel panic due atheros driver after finalsync (Was: VIA VT6103 support (VIA EPIA PD)) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2005 15:27:26 -0000 Hi, I have the D-Link DWL-G520 which has the atheros 5212 chip. When rebooting the FreeBSD 6.0-BETA5 after the final sync kernel panics. If the if_ath module has not been loaded in to the memory all works fine. Does anyone have any good idea how to get rid of this problem? Unloading the kernel module will cause the whole system to halt totally, the system does not respond to anything except power button and reset ;) The output from vmcore: <118>Oct 9 16:52:46 bullgw syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...8 4 4 3 2 2 0 0 0 done All buffers synced. Uptime: 16m6s ukphy0: detached miibus0: detached kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x20:0xc06588d0 stack pointer = 0x28:0xd341dc6c frame pointer = 0x28:0xd341dc80 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 22 (irq11: vr0 ath0++) trap number = 12 panic: page fault Uptime: 16m6s Dmesg shows: ath0: mem 0xde000000-0xde00ffff irq 11 at device 20.0 on pci0 ath0: [GIANT-LOCKED] ath0: Ethernet address: 00:11:95:94:29:08 ath0: mac 7.9 phy 4.5 radio 5.6 pciconf: ath0@pci0:20:0: class=0x020000 card=0x3a131186 chip=0x0013168c rev=0x01 hdr=0x00 On Tuesday 27 September 2005 11:07, Jan Mikael Melen wrote: > > Other weird thing is that I get a kernel panic after final sync when > halting system, I've investigated that this propably doesn't have anything > to do with the VIA EPIA motherboard and I think the problem has something > do either with bridging or the atheros wireless driver. From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 01:05:27 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A64216A41F for ; Mon, 10 Oct 2005 01:05:27 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from lakepoint.domeneshop.no (lakepoint.domeneshop.no [194.63.248.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28E9943D45 for ; Mon, 10 Oct 2005 01:05:25 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from [192.168.5.8] (host-81-191-3-170.bluecom.no [81.191.3.170]) (authenticated bits=0) by lakepoint.domeneshop.no (8.13.4/8.13.4) with ESMTP id j9A15LsY004606; Mon, 10 Oct 2005 03:05:23 +0200 Message-ID: <4349BE4F.9030102@wm-access.no> Date: Mon, 10 Oct 2005 03:05:19 +0200 From: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcin Jessa References: <20050926195807.GD95971@sandvine.com> <17208.30606.117170.36398@khavrinen.csail.mit.edu> <20050927001650.GA9994@sandvine.com> <20050927180021.GB9994@sandvine.com> <433A2882.4030003@freebsd.org> <433A2D6E.7020205@freebsd.org> <20050928152112.GC9994@sandvine.com> <2262110.20050928194326@mail.ru> <584642479.20050930101019@mail.ru> <20050930095743.402e56cd.lists@yazzy.org> <372828116.20051004102540@mail.ru> <20051004093517.15e368f2.lists@yazzy.org> <1721705859.20051004163721@mail.ru> <20051004151842.66ffca58.lists@yazzy.org> In-Reply-To: <20051004151842.66ffca58.lists@yazzy.org> X-Enigmail-Version: 0.92.0.0 OpenPGP: id=C308A003 Content-Type: multipart/mixed; boundary="------------040707080404080506060809" Cc: freebsd-net@freebsd.org, SAMU Subject: Re: How connect 2 PC with ath in hostap mode ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2005 01:05:27 -0000 This is a multi-part message in MIME format. --------------040707080404080506060809 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Marcin Jessa wrote: > On Tue, 4 Oct 2005 16:37:21 +0400 > Andrey Smagin wrote: > >>Hello Marcin, >>Tuesday, October 4, 2005, 11:35:17 AM, you wrote: >> >>MJ> How are you bridging the interfaces? What kind of bridging >>MJ> mechanism are you using? >> >> In FreeBSD: >> kldload ath, ath_hal, bridge, fxp > > Recompile your kernel with following options. > device wlan # 802.11 support > device ath > device ath_hal > device ath_rate_sample > >>On both host: >> ifconfig_ath0="inet ssid 1234 channel 6 mode 11g mediaopt adhoc" >>in sysctl.conf >> hw....bridge.config=ath0:1,fxp0:1 >> hw....bridge.enable=1 >> >> ipfw allow ip from any to any >>in this mode speed about 8KBy/s > > Try to use if_bridge instead > ifconfig bridge0 create up > ifconfig bridge0 addm ath0 fxp0 > etc... > The "old" bridge code is removed from CURRENT anyway. > > Try to play with different sysctl values for ath as well, it may or may > not have an impact on your performance. If you want to be vague, why not add a disclaimer to your e-mails? >> ifconfig_ath0="inet ssid 1234 channel 6 media OFDM54 mode 11g >>mediaopt adhoc" increase speed up to 45-50 KBy/s > > Right, still pretty little. You should get between 2-7 MB/s Stating the obvious? >>Bridging work fine and uptime for both host more >>wheek under full load :) (40KBy/s over wireless) >>Some strange - ping report low average delay about >>0.700ms for any host in another net segment. > > Try to adjust values of ACK timing, I have made a table with some > proposed values: > http://www.wifibsd.org/docs/atheros.php Taking credit for other peoples work again? Appended and attached is an e-mail from the authors of the ack timings. They wished to relay to you that you have copied the mikrotik routeros documentation without consent and thus potentially violated the copyright. [...snip...] >> >>MJ> I am not sure why you have such a speed loss running in adhoc >>MJ> mode. What I noticed on NetBSD (where the ath driver is not yet >>MJ> fully ported) was I got pretty decent speed with the same setup >>MJ> as yours (2xath in adhoc bridged with wired nics) but my embedded >>MJ> devices allways crashed when I sent over many small packets. >> I think this is a driver problem, two ap sucessfully connect >>with each other, why hostap can't do this ? Because it would require WDS or other extension to the standard. > That's becouse FreeBSD ath hostap is for access points , not for > interaction between two APs. FreeBSD ath hostap is for AP's not for interaction between AP's? Where were you going with that, exactly? [...snip...] > Did you run tcpdump on both the hosts to find out what may be causing > your problems? > I will test adhoc between two atheros boxes at home > today. Did your "atheros boxes" perform any better? ---------------------------[ Appended e-mail ]-------------------------- Subject: [Ticket#: 2005100716000313] [Fwd: Re: How connect 2 PC with ath in hosta [...] From: "MikroTik Support [Dmitry]" Date: Fri, 07 Oct 2005 17:09:55 +0300 To: Sten Daniel Sørsdal Hello, The first table I've got from our developers, and I really have no idea where did it come from, the available frequencies table is freely accessible via RouterOS console and also may be obtained from atheros cards' eeprom. But the second one (that about ACK times) is authored here. Me and one my collegue have invested much time into making this table and his claims can be considered as copyright violation. I am sure he can not provide any proof of his authorship, but I still have few pieces of paper with some weird formulae lost somewhere on my table. Thank you for pointing out this issue, can you also write back to the list for me? Regards, Dmitry Sten Daniel Sørsdal wrote: >> Apologies for the inconvenience but on the freebsd-net@freebsd.org >> mailing list there is a guy that claims he wrote the tables >> found here >> (http://www.wifibsd.org/docs/atheros.php). >> >> Which are identical (aside from font formatting) to the ones >> found here: >> (http://www.mikrotik.com/docs/ros/2.9/interface/wireless). >> >> Who's material is it? >> -- >> Sten Daniel Sørsdal ----------------------------------------------------------------------- -- Sten Daniel Sørsdal --------------040707080404080506060809 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="Attached Message" X-Account-Key: account2 Return-Path: Received: from frog.mt.lv (frog.mt.lv [159.148.172.197]) by mx.domeneshop.no (8.12.11/8.12.11) with ESMTP id j97E9xVn031869 for ; Fri, 7 Oct 2005 16:10:01 +0200 Received: from www-data by frog.mt.lv with local (Exim 4.52) id 1ENsv5-0004Hp-65; Fri, 07 Oct 2005 17:09:55 +0300 Content-Type: text/plain; charset="iso-8859-15" Content-Disposition: inline MIME-Version: 1.0 Subject: [Ticket#: 2005100716000313] [Fwd: Re: How connect 2 PC with ath in hosta [...] X-Powered-BY: OTRS - Open Ticket Request System (http://otrs.org/) X-Mailer: OTRS Mail Service (1.19.2.1) References: <43467A13.1040908@wm-access.no> Message-Id: <1128694195.998181.436651434.27276.7@frog.mt.lv> To: Sten Daniel =?ISO-8859-15?Q?S=F8rsdal?= Organization: MikroTik In-Reply-To: <43467A13.1040908@wm-access.no> From: "MikroTik Support [Dmitry]" Date: Fri, 07 Oct 2005 17:09:55 +0300 X-Spam-Status: No, hits=-0.5 required=4.0 X-Spam-Report: -0.5 hits, 4.0 required; * -0.5 ALL_TRUSTED Did not pass through any untrusted hosts X-Virus-Scanned: by moam (http://www.moam.net/) X-Moam-Version: 0.91 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mx.domeneshop.no id j97E9xVn031869 Hello, The first table I've got from our developers, and I really have no idea where did it come from, the available frequencies table is freely accessible via RouterOS console and also may be obtained from atheros cards' eeprom. But the second one (that about ACK times) is authored here. Me and one my collegue have invested much time into making this table and his claims can be considered as copyright violation. I am sure he can not provide any proof of his authorship, but I still have few pieces of paper with some weird formulae lost somewhere on my table. Thank you for pointing out this issue, can you also write back to the list for me? Regards, Dmitry Sten Daniel Sørsdal wrote: > Apologies for the inconvenience but on the freebsd-net@freebsd.org > mailing list there is a guy that claims he wrote the tables found here > (http://www.wifibsd.org/docs/atheros.php). > > Which are identical (aside from font formatting) to the ones found here: > (http://www.mikrotik.com/docs/ros/2.9/interface/wireless). > > Who's material is it? > -- > Sten Daniel Sørsdal > --------------040707080404080506060809-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 06:22:27 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D1C316A41F for ; Mon, 10 Oct 2005 06:22:27 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B55B43D46 for ; Mon, 10 Oct 2005 06:22:25 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from banyan.cs.ait.ac.th (banyan.cs.ait.ac.th [192.41.170.5]) by mail.cs.ait.ac.th (8.12.11/8.12.11) with ESMTP id j9A6MM8p043890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 10 Oct 2005 13:22:22 +0700 (ICT) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.13.1/8.12.11) id j9A6MMbW014091; Mon, 10 Oct 2005 13:22:22 +0700 (ICT) Date: Mon, 10 Oct 2005 13:22:22 +0700 (ICT) Message-Id: <200510100622.j9A6MMbW014091@banyan.cs.ait.ac.th> From: Olivier Nicole To: freebsd-net@freebsd.org X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) Subject: SYN limit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2005 06:22:27 -0000 Hi, I am facing the following problem: I have a web server with an application that calls a MySQL server. For class and test run, I may have 100 users accessing the same web page to login to the same database. For some reason, it seems that the MySQL server only accepts 50 connections to the same resource comming from the same client at one given time. 50 other connections are in SYN_SENT state. Any reason why this limit? Both servers are CPU idled 90% or more, disk are running max 5 transactions/second, network is local LAN and busy less than 5%. It could be a MySQL limit, but MySQL maxconnection is set to 250, so... Thanks in advance, Olivier From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 06:31:07 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2073216A41F for ; Mon, 10 Oct 2005 06:31:07 +0000 (GMT) (envelope-from silby@silby.com) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 93F8143D4C for ; Mon, 10 Oct 2005 06:31:06 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 54667 invoked from network); 10 Oct 2005 06:31:04 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 10 Oct 2005 06:31:04 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 10 Oct 2005 01:31:03 -0500 (CDT) From: Mike Silbersack To: Olivier Nicole In-Reply-To: <200510100622.j9A6MMbW014091@banyan.cs.ait.ac.th> Message-ID: <20051010012831.G60693@odysseus.silby.com> References: <200510100622.j9A6MMbW014091@banyan.cs.ait.ac.th> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: SYN limit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2005 06:31:07 -0000 On Mon, 10 Oct 2005, Olivier Nicole wrote: > For some reason, it seems that the MySQL server only accepts 50 > connections to the same resource comming from the same client at one > given time. 50 other connections are in SYN_SENT state. > > Any reason why this limit? FreeBSD has no SYN rate limit, but you could be running into TIME_WAIT recycling issues. Run a netstat on both the client and server, see if the port numbers match. For example, see if the client is trying to connect to port 3549 and the server has a TIME_WAIT socket on port 3549. The connection is supposed to recycle, but under certain conditions it might not... After doing that, try setting net.inet.ip.portrange.randomized=0 and see if the problem clears up at all. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 06:52:22 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1E2016A41F for ; Mon, 10 Oct 2005 06:52:22 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7336143D53 for ; Mon, 10 Oct 2005 06:52:21 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from banyan.cs.ait.ac.th (banyan.cs.ait.ac.th [192.41.170.5]) by mail.cs.ait.ac.th (8.12.11/8.12.11) with ESMTP id j9A6qI2l045011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 10 Oct 2005 13:52:18 +0700 (ICT) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.13.1/8.12.11) id j9A6qIbV015852; Mon, 10 Oct 2005 13:52:18 +0700 (ICT) Date: Mon, 10 Oct 2005 13:52:18 +0700 (ICT) Message-Id: <200510100652.j9A6qIbV015852@banyan.cs.ait.ac.th> From: Olivier Nicole CC: freebsd-net@freebsd.org In-reply-to: <20051010012831.G60693@odysseus.silby.com> (message from Mike Silbersack on Mon, 10 Oct 2005 01:31:03 -0500 (CDT)) References: <200510100622.j9A6MMbW014091@banyan.cs.ait.ac.th> <20051010012831.G60693@odysseus.silby.com> X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) Subject: Re: SYN limit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2005 06:52:22 -0000 > FreeBSD has no SYN rate limit, but you could be running into TIME_WAIT > recycling issues. I already set tcp.msl to 5000 to release the TIME WAIT quickly. > Run a netstat on both the client and server, see if the port numbers > match. For example, see if the client is trying to connect to port 3549 > and the server has a TIME_WAIT socket on port 3549. The connection is > supposed to recycle, but under certain conditions it might not... I could not find any port conflict. > After doing that, try setting net.inet.ip.portrange.randomized=0 and see > if the problem clears up at all. Tried that too but it dod not help. olivier From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 07:18:54 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58F9616A41F for ; Mon, 10 Oct 2005 07:18:54 +0000 (GMT) (envelope-from ferdinand.goldmann@jku.at) Received: from mail2.edvz.uni-linz.ac.at (mail2.edvz.uni-linz.ac.at [140.78.3.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1DC243D45 for ; Mon, 10 Oct 2005 07:18:53 +0000 (GMT) (envelope-from ferdinand.goldmann@jku.at) Received: from emailsecure.uni-linz.ac.at (emailsecure.uni-linz.ac.at [140.78.3.66]) by mail2.edvz.uni-linz.ac.at (8.13.3/8.13.3) with ESMTP id j9A7Idjc006608 for ; Mon, 10 Oct 2005 09:18:42 +0200 (CEST) (envelope-from ferdinand.goldmann@jku.at) Received: from [140.78.164.13] (jku006048.edvz.uni-linz.ac.at [140.78.6.48]) by emailsecure.uni-linz.ac.at (Postfix) with ESMTP id 229D0228019 for ; Mon, 10 Oct 2005 08:57:25 +0200 (CEST) Message-ID: <434A10D9.1060409@jku.at> Date: Mon, 10 Oct 2005 08:57:29 +0200 From: Ferdinand Goldmann Organization: Johannes Kepler University User-Agent: Thunderbird 1.4 (Macintosh/20050908) MIME-Version: 1.0 To: net@freebsd.org References: <4341089F.7010504@jku.at> <20051003104548.GB70355@cell.sick.ru> <4341242F.9060602@jku.at> <20051003123210.GF70355@cell.sick.ru> <43426EF3.3020404@jku.at> <9CD8C672-1EF2-42FE-A61E-83DC684C893D@dragondata.com> <43429157.90606@jku.at> <4342987D.7000200@benswebs.com> <20051004161217.GB43195@obiwan.tataz.chchile.org> <1128470191.75484.TMDA@seddon.ca> <979B163D-7078-4558-9095-DC329707A5B4@dragondata.com> <4343C559.5000000@jku.at> <4343CE03.7090008@pp.nic.fi> In-Reply-To: <4343CE03.7090008@pp.nic.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.44 Cc: Subject: Re: dummynet, em driver, device polling issues :-(( X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ferdinand.goldmann@jku.at List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2005 07:18:54 -0000 Pertti Kosunen wrote: > Ferdinand Goldmann wrote: >> 944mbps is a very good value, anyway. What we see in our setup are >> throuput rates around 300mbps or below. When testing with tcpspray, >> throughput hardly exceeded 13MB/s. > > Increasing MTU should help to get better results, as long all devices in > network support jumbo frames (at least on large files). 9k or even 16k > might be supported. > Problem is only that the em driver does not support Jumbo frames on the 82545GM. :-( -- >> Ferdinand Goldmann //// | | >> EMail: Ferdinand.Goldmann@zid.uni-linz.ac.at |--00 | UNIX | >> Tel. : +43/732/2468/9398 Fax. : +43/732/2468/9397 C ^ | | >> EMail: Ferdinand.Goldmann@zid.uni-linz.ac.at \ ~/ ~~~|~~~~~~~~ >> PGP D4CF 8AA4 4B2A 7B88 65CA 5EDC 0A9B FA9A 13EA B993| |-----3 From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 07:57:39 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEDB216A420 for ; Mon, 10 Oct 2005 07:57:39 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C77443D4C for ; Mon, 10 Oct 2005 07:57:36 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from 217-13-2-82.dd.nextgentel.com ([217.13.2.82] helo=marcin) by mail.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1EOsWr-00017D-GG; Mon, 10 Oct 2005 09:57:04 +0200 Date: Mon, 10 Oct 2005 09:57:44 +0200 From: Marcin Jessa To: Sten Daniel =?ISO-8859-1?Q?S=F8rsdal?= Message-Id: <20051010095744.7e35a863.lists@yazzy.org> In-Reply-To: <4349BE4F.9030102@wm-access.no> References: <20050926195807.GD95971@sandvine.com> <17208.30606.117170.36398@khavrinen.csail.mit.edu> <20050927001650.GA9994@sandvine.com> <20050927180021.GB9994@sandvine.com> <433A2882.4030003@freebsd.org> <433A2D6E.7020205@freebsd.org> <20050928152112.GC9994@sandvine.com> <2262110.20050928194326@mail.ru> <584642479.20050930101019@mail.ru> <20050930095743.402e56cd.lists@yazzy.org> <372828116.20051004102540@mail.ru> <20051004093517.15e368f2.lists@yazzy.org> <1721705859.20051004163721@mail.ru> <20051004151842.66ffca58.lists@yazzy.org> <4349BE4F.9030102@wm-access.no> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.0 (GTK+ 2.6.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.5 (--) Cc: freebsd-net@freebsd.org Subject: Re: How connect 2 PC with ath in hostap mode ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2005 07:57:40 -0000 On Mon, 10 Oct 2005 03:05:19 +0200 Sten Daniel S=F8rsdal wrote: What's exactly the point of this email? I don't see any help being provided here. The table in question is removed. I wasn't aware of it being copyrighted. Next time please contact me _first_ if you're in doubt of something.=20 And when it comes to mikrotik, you can ask them to release their GPLd code first before running to them like a stupid dog telling on someone who used their freely avaliable information published on the web. > Marcin Jessa wrote: > > On Tue, 4 Oct 2005 16:37:21 +0400 > > Andrey Smagin wrote: > >=20 > >>Hello Marcin, > >>Tuesday, October 4, 2005, 11:35:17 AM, you wrote: > >> > >>MJ> How are you bridging the interfaces? What kind of bridging > >>MJ> mechanism are you using? > >> > >> In FreeBSD: > >> kldload ath, ath_hal, bridge, fxp > >=20 > > Recompile your kernel with following options. > > device wlan # 802.11 support > > device ath > > device ath_hal > > device ath_rate_sample > >=20 > >>On both host: > >> ifconfig_ath0=3D"inet ssid 1234 channel 6 mode 11g mediaopt adhoc" > >>in sysctl.conf > >> hw....bridge.config=3Dath0:1,fxp0:1 > >> hw....bridge.enable=3D1 > >> =20 > >> ipfw allow ip from any to any > >>in this mode speed about 8KBy/s > >=20 > > Try to use if_bridge instead > > ifconfig bridge0 create up > > ifconfig bridge0 addm ath0 fxp0=20 > > etc... > > The "old" bridge code is removed from CURRENT anyway. > >=20 > > Try to play with different sysctl values for ath as well, it may or > > may not have an impact on your performance. >=20 > If you want to be vague, why not add a disclaimer to your e-mails? >=20 > >> ifconfig_ath0=3D"inet ssid 1234 channel 6 media OFDM54 mode 11g > >>mediaopt adhoc" increase speed up to 45-50 KBy/s > >=20 > > Right, still pretty little. You should get between 2-7 MB/s >=20 > Stating the obvious? >=20 > >>Bridging work fine and uptime for both host more > >>wheek under full load :) (40KBy/s over wireless) > >>Some strange - ping report low average delay about > >>0.700ms for any host in another net segment. > >=20 > > Try to adjust values of ACK timing, I have made a table with some > > proposed values: > > http://www.wifibsd.org/docs/atheros.php >=20 > Taking credit for other peoples work again? Appended and attached is > an e-mail from the authors of the ack timings. They wished to relay > to you that you have copied the mikrotik routeros documentation > without consent and thus potentially violated the copyright. >=20 > [...snip...] >=20 > >> > >>MJ> I am not sure why you have such a speed loss running in adhoc > >>MJ> mode. What I noticed on NetBSD (where the ath driver is not yet > >>MJ> fully ported) was I got pretty decent speed with the same setup > >>MJ> as yours (2xath in adhoc bridged with wired nics) but my > >>MJ> embedded devices allways crashed when I sent over many small > >>MJ> packets. > >> I think this is a driver problem, two ap sucessfully connect > >>with each other, why hostap can't do this ?=20 >=20 > Because it would require WDS or other extension to the standard. >=20 > > That's becouse FreeBSD ath hostap is for access points , not for > > interaction between two APs. >=20 > FreeBSD ath hostap is for AP's not for interaction between AP's? > Where were you going with that, exactly? >=20 > [...snip...] >=20 > > Did you run tcpdump on both the hosts to find out what may be > > causing your problems? > > I will test adhoc between two atheros boxes at home > > today.=20 >=20 > Did your "atheros boxes" perform any better? >=20 > ---------------------------[ Appended > e-mail ]-------------------------- Subject: [Ticket#: > 2005100716000313] [Fwd: Re: How connect 2 PC with ath in hosta [...] > From: "MikroTik Support [Dmitry]" > Date: Fri, 07 Oct 2005 17:09:55 +0300 > To: Sten Daniel S=F8rsdal >=20 > Hello, >=20 > The first table I've got from our developers, and I really have no > idea where did it come from, the available frequencies table is freely > accessible via RouterOS console and also may be obtained from atheros > cards' eeprom. But the second one (that about ACK times) is authored > here. Me and one my collegue have invested much time into making this > table and his claims can be considered as copyright violation. I am > sure he can not provide any proof of his authorship, but I still have > few pieces of paper with some weird formulae lost somewhere on my > table. Thank you for pointing out this issue, can you also write back > to the list for me? >=20 > Regards, > Dmitry >=20 > Sten Daniel S=F8rsdal wrote: >=20 > >> Apologies for the inconvenience but on the freebsd-net@freebsd.org > >> mailing list there is a guy that claims he wrote the tables > >> found here > >> (http://www.wifibsd.org/docs/atheros.php). > >> > >> Which are identical (aside from font formatting) to the ones > >> found here: > >> (http://www.mikrotik.com/docs/ros/2.9/interface/wireless). > >> > >> Who's material is it? > >> -- > >> Sten Daniel S=F8rsdal > ----------------------------------------------------------------------- >=20 >=20 > --=20 > Sten Daniel S=F8rsdal >=20 From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 08:04:33 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0AED16A41F for ; Mon, 10 Oct 2005 08:04:33 +0000 (GMT) (envelope-from silby@silby.com) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 1F44143D58 for ; Mon, 10 Oct 2005 08:04:32 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 85877 invoked from network); 10 Oct 2005 08:04:31 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 10 Oct 2005 08:04:31 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 10 Oct 2005 03:04:29 -0500 (CDT) From: Mike Silbersack To: Olivier Nicole In-Reply-To: <200510100652.j9A6qIbV015852@banyan.cs.ait.ac.th> Message-ID: <20051010030301.F60693@odysseus.silby.com> References: <200510100622.j9A6MMbW014091@banyan.cs.ait.ac.th> <20051010012831.G60693@odysseus.silby.com> <200510100652.j9A6qIbV015852@banyan.cs.ait.ac.th> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: SYN limit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2005 08:04:33 -0000 On Mon, 10 Oct 2005, Olivier Nicole wrote: >> FreeBSD has no SYN rate limit, but you could be running into TIME_WAIT >> recycling issues. > > I already set tcp.msl to 5000 to release the TIME WAIT quickly. I should really remove that sysctl... It's tangential to the problem, that would only help if you were running out of sockets. > I could not find any port conflict. > Tried that too but it dod not help. > > olivier Well, you're going to need to take tcpdumps at both hosts to figure this out, I have no idea what could be happening. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 10:32:20 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E83A516A41F for ; Mon, 10 Oct 2005 10:32:20 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E30043D48 for ; Mon, 10 Oct 2005 10:32:20 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j9AAWHVl069022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Oct 2005 14:32:17 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j9AAWGcE069021; Mon, 10 Oct 2005 14:32:16 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 10 Oct 2005 14:32:16 +0400 From: Gleb Smirnoff To: Iasen Kostov Message-ID: <20051010103216.GP14542@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Iasen Kostov , freebsd-net@freebsd.org References: <1128697135.71975.24.camel@DraGoN.OTEL.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1128697135.71975.24.camel@DraGoN.OTEL.net> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org Subject: Re: Proxy arp should only replay on specified interface. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2005 10:32:21 -0000 Iasen, On Fri, Oct 07, 2005 at 05:58:55PM +0300, Iasen Kostov wrote: I> IMHO proxy arp should only replay on specified interface not on every I> arp capable interface which recieved request for the proxied address. I> If lets say host A have arp capable if0 and if1 interfaces and U set: I> route add -host 1.0.0.2 -iface if1 -proxy I> I> and then a request is recieved on if0 for 1.0.0.2, host A will replay I> that it has it (which IMHO is wrong as the proxy route is set for if1). I> I> This sometimes is a big problem for our PPPoE/VPN server when the I> client uses linux or some small routers (e.g Linksys or something) I> probably linux based. It happen that sometimes (when the link is down or I> god knows why) it broadcasts arp "who-has" and the gateway replays. Then I> this host try to use ethernet path and not the (right) tunnel path until I> arp cache expires (which is not real fun as there is firewall rules I> blocking ethernet path :)). I> I> And even worse :) - I can think of ways to bypass routing protocols I> using proxy-arp routes like the one mentioned above. But it will not I> work if proxy-arp behaves the way it does now. I> And 1 thing more - there could be a switch which restores (or turns on) I> old behavior. I> I> (patch agains 5.4-STABLE is attached) Isn't this what you need? http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/if_ether.c?rev=1.140&content-type=text/x-cvsweb-markup -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 10:52:52 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2BF116A41F for ; Mon, 10 Oct 2005 10:52:52 +0000 (GMT) (envelope-from pertti.kosunen@pp.nic.fi) Received: from fep16.inet.fi (fep16.inet.fi [194.251.242.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4E6943D48 for ; Mon, 10 Oct 2005 10:52:51 +0000 (GMT) (envelope-from pertti.kosunen@pp.nic.fi) Received: from [192.168.0.20] ([84.249.3.49]) by fep16.inet.fi with ESMTP id <20051010105249.SHAJ26717.fep16.inet.fi@[192.168.0.20]>; Mon, 10 Oct 2005 13:52:49 +0300 Message-ID: <434A4801.4000401@pp.nic.fi> Date: Mon, 10 Oct 2005 13:52:49 +0300 From: Pertti Kosunen User-Agent: Mozilla Thunderbird 1.0.2 / FreeBSD 6.0-BETA5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ferdinand.goldmann@jku.at References: <4341089F.7010504@jku.at> <20051003104548.GB70355@cell.sick.ru> <4341242F.9060602@jku.at> <20051003123210.GF70355@cell.sick.ru> <43426EF3.3020404@jku.at> <9CD8C672-1EF2-42FE-A61E-83DC684C893D@dragondata.com> <43429157.90606@jku.at> <4342987D.7000200@benswebs.com> <20051004161217.GB43195@obiwan.tataz.chchile.org> <1128470191.75484.TMDA@seddon.ca> <979B163D-7078-4558-9095-DC329707A5B4@dragondata.com> <4343C559.5000000@jku.at> <4343CE03.7090008@pp.nic.fi> <434A10D9.1060409@jku.at> In-Reply-To: <434A10D9.1060409@jku.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: dummynet, em driver, device polling issues :-(( X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2005 10:52:52 -0000 Ferdinand Goldmann wrote: > Problem is only that the em driver does not support Jumbo frames on the > 82545GM. :-( You should try, the em man page is not up to date (6.0-BETA5). "The driver supports Transmit/Receive checksum offload and Jumbo Frames only on 82540, 82543, 82544 and 82546-based adapters." em0@pci0:13:0: class=0x020000 card=0x11768086 chip=0x10768086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82547EI Gigabit Ethernet Controller' em0: flags=8843 mtu 9014 options=4b inet 10.0.10.10 netmask 0xffffff00 broadcast 10.0.10.255 ether 00:0e:0c:68:88:86 media: Ethernet autoselect (1000baseTX ) status: active From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 11:01:58 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18E9C16A41F for ; Mon, 10 Oct 2005 11:01:58 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C471543D46 for ; Mon, 10 Oct 2005 11:01:57 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9AB1vP8051353 for ; Mon, 10 Oct 2005 11:01:57 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9AB1uH1051347 for freebsd-net@freebsd.org; Mon, 10 Oct 2005 11:01:56 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 10 Oct 2005 11:01:56 GMT Message-Id: <200510101101.j9AB1uH1051347@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2005 11:01:58 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 12:02:43 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CC3F16A41F for ; Mon, 10 Oct 2005 12:02:43 +0000 (GMT) (envelope-from tbyte@otel.net) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0ECA543D49 for ; Mon, 10 Oct 2005 12:02:40 +0000 (GMT) (envelope-from tbyte@otel.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.30; FreeBSD) id 1EOwMZ-0002xX-CT for freebsd-net@FreeBSD.org; Mon, 10 Oct 2005 15:02:39 +0300 From: Iasen Kostov To: freebsd-net@FreeBSD.org In-Reply-To: <20051010103216.GP14542@cell.sick.ru> References: <1128697135.71975.24.camel@DraGoN.OTEL.net> <20051010103216.GP14542@cell.sick.ru> Content-Type: text/plain Date: Mon, 10 Oct 2005 15:02:39 +0300 Message-Id: <1128945759.11704.5.camel@DraGoN.OTEL.net> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Subject: Re: Proxy arp should only replay on specified interface. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2005 12:02:43 -0000 On Mon, 2005-10-10 at 14:32 +0400, Gleb Smirnoff wrote: > Iasen, > > On Fri, Oct 07, 2005 at 05:58:55PM +0300, Iasen Kostov wrote: > I> IMHO proxy arp should only replay on specified interface not on every > I> arp capable interface which recieved request for the proxied address. > I> If lets say host A have arp capable if0 and if1 interfaces and U set: > I> route add -host 1.0.0.2 -iface if1 -proxy > I> > I> and then a request is recieved on if0 for 1.0.0.2, host A will replay > I> that it has it (which IMHO is wrong as the proxy route is set for if1). > I> > I> This sometimes is a big problem for our PPPoE/VPN server when the > I> client uses linux or some small routers (e.g Linksys or something) > I> probably linux based. It happen that sometimes (when the link is down or > I> god knows why) it broadcasts arp "who-has" and the gateway replays. Then > I> this host try to use ethernet path and not the (right) tunnel path until > I> arp cache expires (which is not real fun as there is firewall rules > I> blocking ethernet path :)). > I> > I> And even worse :) - I can think of ways to bypass routing protocols > I> using proxy-arp routes like the one mentioned above. But it will not > I> work if proxy-arp behaves the way it does now. > I> And 1 thing more - there could be a switch which restores (or turns on) > I> old behavior. > I> > I> (patch agains 5.4-STABLE is attached) > > Isn't this what you need? > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/if_ether.c?rev=1.140&content-type=text/x-cvsweb-markup > Exactly :). Thanks. This probably won't make it into 5.x but its good to know that it's fixed :) regards. From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 12:05:48 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E88A16A41F for ; Mon, 10 Oct 2005 12:05:48 +0000 (GMT) (envelope-from tbyte@otel.net) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E37A43D55 for ; Mon, 10 Oct 2005 12:05:47 +0000 (GMT) (envelope-from tbyte@otel.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.30; FreeBSD) id 1EOwPY-000342-RB; Mon, 10 Oct 2005 15:05:44 +0300 From: Iasen Kostov To: Chuck Swiger In-Reply-To: <434699D8.7000306@mac.com> References: <1128697135.71975.24.camel@DraGoN.OTEL.net> <434699D8.7000306@mac.com> Content-Type: text/plain Date: Mon, 10 Oct 2005 15:05:44 +0300 Message-Id: <1128945944.11704.9.camel@DraGoN.OTEL.net> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Proxy arp should only replay on specified interface. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2005 12:05:48 -0000 On Fri, 2005-10-07 at 11:52 -0400, Chuck Swiger wrote: > Iasen Kostov wrote: > > IMHO proxy arp should only replay on specified interface not on every > > arp capable interface which recieved request for the proxied address. > > This is an interesting idea, but shouldn't it at least take into consideration > whether some interfaces are being bridged...? > U can proxy-arp on bridgeX interface (if U use if_bridge ofcourse) that way U can proxy in the bridge (if that was the question :). From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 15:31:13 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D214C16A41F for ; Mon, 10 Oct 2005 15:31:13 +0000 (GMT) (envelope-from comte0@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CDC243D69 for ; Mon, 10 Oct 2005 15:31:01 +0000 (GMT) (envelope-from comte0@gmail.com) Received: by nproxy.gmail.com with SMTP id x4so457189nfb for ; Mon, 10 Oct 2005 08:31:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=QTmpzrJvWW+984FZj/1jcP8CI1SqJEOLSN1ssEHbMFuRKpaKki4L1nlLxxquJUsDxECQkVauepgLVR3huzkdU0nHGXkcm5FOadnVv2XYm+x2cHEYVjJ2H7zu385aFWlFhefClAFLhgDVEVtdteAp6ZAXLA4OKkxrvzFYeUxpvF0= Received: by 10.48.108.1 with SMTP id g1mr307159nfc; Mon, 10 Oct 2005 08:31:01 -0700 (PDT) Received: by 10.48.237.5 with HTTP; Mon, 10 Oct 2005 08:31:00 -0700 (PDT) Message-ID: <1d881b2f0510100831k5b05f190p48c7f018e49d82ae@mail.gmail.com> Date: Mon, 10 Oct 2005 17:31:00 +0200 From: ComteZero _ To: Gleb Smirnoff , freebsd-net@freebsd.org In-Reply-To: <20051003064437.GD45345@cell.sick.ru> MIME-Version: 1.0 References: <1d881b2f050914072350d79a65@mail.gmail.com> <20051003064437.GD45345@cell.sick.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: PPPoE (STABLE 5) : two PADI packets emitted and then nothing... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2005 15:31:13 -0000 thx for your answer, now seems that PPPoE negociation works better. but i still have no connection, and when I try with #ppp, I stay in ppp mod= e (ie I can't see the Ppp, PPp, PPP...) : Oct 4 22:01:19 fidelio ppp[30314]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Oct 4 22:01:19 fidelio ppp[30314]: tun0: Debug: Found the following interfaces: Oct 4 22:01:19 fidelio ppp[30314]: tun0: Debug: Index 1, name "fxp0" Oct 4 22:01:19 fidelio ppp[30314]: tun0: Debug: Index 2, name "xl0" Oct 4 22:01:19 fidelio ppp[30314]: tun0: Debug: Index 3, name "plip0" Oct 4 22:01:19 fidelio ppp[30314]: tun0: Debug: Index 4, name "lo0" Oct 4 22:01:19 fidelio ppp[30314]: tun0: Debug: Index 5, name "tun0" Oct 4 22:01:19 fidelio ppp[30314]: tun0: Debug: Index 6, name "tun1" Oct 4 22:01:19 fidelio ppp[30314]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80bf068] Oct 4 22:01:19 fidelio ppp[30314]: tun0: Phase: deflink: Connected! Oct 4 22:01:19 fidelio ppp[30314]: tun0: Phase: deflink: opening -> dial Oct 4 22:01:19 fidelio ppp[30314]: tun0: Phase: deflink: dial -> carrier Oct 4 22:01:19 fidelio ppp[30314]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "3Com HomeConnect ADSL Modem Dua") Oct 4 22:01:19 fidelio ppp[30314]: tun0: Phase: Received NGM_PPPOE_SESSIONI= D Oct 4 22:01:19 fidelio ppp[30314]: tun0: Phase: Received NGM_PPPOE_SUCCESS Oct 4 22:01:19 fidelio ppp[30314]: tun0: Phase: deflink: carrier -> login Oct 4 22:01:19 fidelio ppp[30314]: tun0: Phase: deflink: login -> lcp Oct 4 22:01:19 fidelio ppp[30314]: tun0: LCP: FSM: Using "deflink" as a transport Oct 4 22:01:19 fidelio ppp[30314]: tun0: LCP: deflink: State change Initial --> Closed Oct 4 22:01:19 fidelio ppp[30314]: tun0: LCP: deflink: State change Closed --> Stopped Oct 4 22:01:19 fidelio ppp[30314]: tun0: Timer: timer_Start: Inserting LCP openmode timer[0x80bf15c] before physical throughput timer[0x80bf068], delt= a =3D 10 Oct 4 22:01:19 fidelio ppp[30314]: tun0: Timer: deflink(ctrl): fdset(r) 0 Oct 4 22:01:19 fidelio ppp[30314]: tun0: Timer: deflink: fdset(r) 1 Oct 4 22:01:19 fidelio ppp[30314]: tun0: Timer: deflink: fdset(e) 1 Oct 4 22:01:20 fidelio ppp[30314]: tun0: Timer: Select returns -1 ifconfig shows interfaces up & active. my ppp.conf is as follow : default: set log all set ifaddr X.X.X.X/0 10.0.0.2/0 my_isp : set pppoe 3com set device PPPoE:xl0 set mtu max 1492 set mru max 1492 set authname MY_USER set authkey MY_PWD disable ipv6cp set dial #set login add default HISADDR Seems that Chap/Pap authentification does not start... any help welcome, Rgds, Eric, On 10/3/05, Gleb Smirnoff wrote: > > On Wed, Sep 14, 2005 at 04:23:30PM +0200, ComteZero _ wrote: > C> Hello, > C> > C> I already posted this thread in freebsd-stable but seems that this lis= t > is > C> more appropriate. > C> > C> it's been two weeks I try to find out what's wrong. Clean install from > cvsup > C> STABLE (5). > C> my ADSL account works fine with REL. 4.4+rp_pppoe but not with my new > STABLE > C> (5) (without using rp_pppoe). > C> could someone help me on this issue (logs provided here, ppp.log in > attached > C> file)... > C> two PADI are emitted but nothing happens after. > C> (i saw that someone had a similar problem, but with previous netgraph > C> revisions). > C> > C> thank you. > C> > C> Since my ADSL modem is 3Com HomeConnect, I've set the > C> net.graph.nonstandard_pppoe=3D1 > > This interface is deprecated in 5-STABLE. The correct way is to set > this via ppp.conf. > > C> ng_pppoe.c rev. is 1.67.2.1 > C> ng_socket.c rev. is 1.53.2.3 > C> > C> my ppp.conf is : > C> default: > C> set log all > C> set ifaddr X.X.X.X/0 10.0.0.2/0 > C> > C> my_isp : > C> set device PPPoE:xl0 > C> set authname MY_USER > C> set authkey MY_PWD > C> set dial > C> #set login > C> add default HISADDR > C> > C> > C> here is a tcpdump -vv -i xl0 : > C> > C> 18:48:40.808687 PPPoE PADI [Host-Uniq 0x00E654C1] > C> 18:48:42.807533 PPPoE PADI [Host-Uniq 0x00E654C1] > C> 18:51:44.010839 PPPoE PADI [Host-Uniq 0x40F195C1] > C> 18:51:46.009639 PPPoE PADI [Host-Uniq 0x40F195C1] > > It is strange, that your box sends standard PPPoE packets. May be you hav= e > set > net.graph.nonstandard_pppoe=3D1 _after_ starting ppp(8)? > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 17:35:24 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78CFB16A41F for ; Mon, 10 Oct 2005 17:35:24 +0000 (GMT) (envelope-from dart@es.net) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48AFE43D46 for ; Mon, 10 Oct 2005 17:35:24 +0000 (GMT) (envelope-from dart@es.net) Received: from [198.128.1.31] ([198.128.1.31]) by postal1.es.net (Postal Node 1) with ASMTP (SSL) id IBA74465; Mon, 10 Oct 2005 10:35:21 -0700 Message-ID: <434AA658.1090505@es.net> Date: Mon, 10 Oct 2005 10:35:20 -0700 From: Eli Dart Organization: Energy Sciences Network User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050726) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Olivier Nicole References: <200510100622.j9A6MMbW014091@banyan.cs.ait.ac.th> In-Reply-To: <200510100622.j9A6MMbW014091@banyan.cs.ait.ac.th> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: SYN limit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dart@es.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2005 17:35:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Olivier Nicole wrote: > Hi, > > I am facing the following problem: I have a web server with an > application that calls a MySQL server. > > For class and test run, I may have 100 users accessing the same web > page to login to the same database. > > For some reason, it seems that the MySQL server only accepts 50 > connections to the same resource comming from the same client at one > given time. 50 other connections are in SYN_SENT state. My guess is that you've run into a MySQL configuration limit. MySQL can be configured to accept more connections. Try looking through the MySQL docs and see if you need to tweak your config? --eli -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDSqZYLTFEeF+CsrMRAo1oAJwNuMJBtbYizTEAN1Vnyep7uaffbwCcD4+/ iVEugod3dCGk1Kk8fdVz/j0= =tke4 -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 03:34:03 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C942816A41F for ; Tue, 11 Oct 2005 03:34:02 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C0DA43D46 for ; Tue, 11 Oct 2005 03:34:00 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from banyan.cs.ait.ac.th (banyan.cs.ait.ac.th [192.41.170.5]) by mail.cs.ait.ac.th (8.12.11/8.12.11) with ESMTP id j9B3Xv97087583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Oct 2005 10:33:57 +0700 (ICT) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.13.1/8.12.11) id j9B3XuS6061712; Tue, 11 Oct 2005 10:33:56 +0700 (ICT) Date: Tue, 11 Oct 2005 10:33:56 +0700 (ICT) Message-Id: <200510110333.j9B3XuS6061712@banyan.cs.ait.ac.th> From: Olivier Nicole To: freebsd-net@freebsd.org In-reply-to: <20051010030301.F60693@odysseus.silby.com> (message from Mike Silbersack on Mon, 10 Oct 2005 03:04:29 -0500 (CDT)) References: <200510100622.j9A6MMbW014091@banyan.cs.ait.ac.th> <20051010012831.G60693@odysseus.silby.com> <200510100652.j9A6qIbV015852@banyan.cs.ait.ac.th> <20051010030301.F60693@odysseus.silby.com> X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) Subject: Re: SYN limit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2005 03:34:03 -0000 > I am facing the following problem: I have a web server with an > application that calls a MySQL server. > > For class and test run, I may have 100 users accessing the same web > page to login to the same database. Well, it seems that was due to a bad installation of MySQL. Going for the port with linythread did the trick, I can now connect 100 clients to MySQL server, plus the reply are much faster. Bests, olivier From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 05:33:35 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EBA516A41F for ; Tue, 11 Oct 2005 05:33:35 +0000 (GMT) (envelope-from silby@silby.com) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 1B32343D45 for ; Tue, 11 Oct 2005 05:33:34 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 12641 invoked from network); 11 Oct 2005 05:33:32 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 11 Oct 2005 05:33:32 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 11 Oct 2005 00:33:30 -0500 (CDT) From: Mike Silbersack To: Olivier Nicole In-Reply-To: <200510110333.j9B3XuS6061712@banyan.cs.ait.ac.th> Message-ID: <20051011003306.D8442@odysseus.silby.com> References: <200510100622.j9A6MMbW014091@banyan.cs.ait.ac.th> <20051010012831.G60693@odysseus.silby.com> <200510100652.j9A6qIbV015852@banyan.cs.ait.ac.th> <20051010030301.F60693@odysseus.silby.com> <200510110333.j9B3XuS6061712@banyan.cs.ait.ac.th> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: SYN limit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2005 05:33:35 -0000 On Tue, 11 Oct 2005, Olivier Nicole wrote: >> I am facing the following problem: I have a web server with an >> application that calls a MySQL server. >> >> For class and test run, I may have 100 users accessing the same web >> page to login to the same database. > > Well, it seems that was due to a bad installation of MySQL. Going for > the port with linythread did the trick, I can now connect 100 clients > to MySQL server, plus the reply are much faster. > > Bests, > > olivier Oh, ah. If you haven't rebooted since the trouble, what does this show on the server? netstat -s | grep "listen queue overflows" Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 06:08:54 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD91E16A41F for ; Tue, 11 Oct 2005 06:08:54 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66EAA43D45 for ; Tue, 11 Oct 2005 06:08:52 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from banyan.cs.ait.ac.th (banyan.cs.ait.ac.th [192.41.170.5]) by mail.cs.ait.ac.th (8.12.11/8.12.11) with ESMTP id j9B68n09092793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Oct 2005 13:08:49 +0700 (ICT) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.13.1/8.12.11) id j9B68lJh065202; Tue, 11 Oct 2005 13:08:47 +0700 (ICT) Date: Tue, 11 Oct 2005 13:08:47 +0700 (ICT) Message-Id: <200510110608.j9B68lJh065202@banyan.cs.ait.ac.th> From: Olivier Nicole To: silby@silby.com In-reply-to: <20051011003306.D8442@odysseus.silby.com> (message from Mike Silbersack on Tue, 11 Oct 2005 00:33:30 -0500 (CDT)) References: <200510100622.j9A6MMbW014091@banyan.cs.ait.ac.th> <20051010012831.G60693@odysseus.silby.com> <200510100652.j9A6qIbV015852@banyan.cs.ait.ac.th> <20051010030301.F60693@odysseus.silby.com> <200510110333.j9B3XuS6061712@banyan.cs.ait.ac.th> <20051011003306.D8442@odysseus.silby.com> X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) Cc: freebsd-net@freebsd.org Subject: Re: SYN limit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2005 06:08:54 -0000 > Oh, ah. If you haven't rebooted since the trouble, what does this show on > the server? I did reboot, and it basically shown nothing, that's why it was not easy to find out. The queue di not overflow, only the server took some time to accept the connections, it accepted 50 and the rest was waiting at SYN stage and would be ACKed and processed as soon as one other connection terminated. Olivier From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 06:39:51 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC8CA16A41F for ; Tue, 11 Oct 2005 06:39:51 +0000 (GMT) (envelope-from vulture@netvulture.com) Received: from rackman.netvulture.com (adsl-63-197-17-60.dsl.snfc21.pacbell.net [63.197.17.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C06B43D45 for ; Tue, 11 Oct 2005 06:39:49 +0000 (GMT) (envelope-from vulture@netvulture.com) Received: from [66.160.199.14] (1202.nthair.com [66.160.199.14] (may be forged)) (authenticated bits=0) by rackman.netvulture.com (8.13.5/8.13.5) with ESMTP id j9B6dTWO092124; Mon, 10 Oct 2005 23:39:30 -0700 (PDT) Message-ID: <434B5E27.1010208@netvulture.com> Date: Mon, 10 Oct 2005 23:39:35 -0700 From: Jonathan Feally User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Feally References: <4348B6AF.8020207@netvulture.com> In-Reply-To: <4348B6AF.8020207@netvulture.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact your system administrator for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-2.779, required 2.5, ALL_TRUSTED -2.82, AWL 0.04) Cc: freebsd-net@freebsd.org Subject: Re: Having issues with bridging vlan and em in 5.4-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2005 06:39:51 -0000 After further testing I have found 2 issues pertaining to my problem. a. ) MAC on returning packets from box are that of the vlan199 parent interface's instead of that of the other em0 interface. b.) The dns responses are leaving the box on the vlan, but the dst port number is getting scrambled in the process. tcpdump on the box shows in and out on the same ports, but the host shows out on one and in on something else. Is this an issue with the bridging code, the vlan code, or both?? I have em0 and em1 set with the following flags UP, BROADCAST, RUNNING, PROMISC, SIMPLEX, MULTICAST options: RXCSUM, TXCSUM, VLAN_MTU, POLLING vlan199 flags UP, BROADCAST, RUNNING, PROMISC, SIMPLEX, MULTICAST vlan199 has no options. Anybody else run into this problem? I am running 5-STABLE as of today. -Jon Jonathan Feally wrote: > I'm trying to setup a machine that will be both routing traffic and > bridging 2 segments of one network with ipfw processing on that > bridged network. The routing seems to be OK and bridging is also OK > from Side to side, however when trying to talk to the IP of the > machine from another machine on the bridged network i am seeing packet > loss. > > Setup > > > em0 x.y.199.254 connected to segment with outgoing router at > x.y.199.1. Lets call this Side A > em1 no IP. Internal interface with all the vlans attached to it > vlan199 no IP configured as tagged vlan 199 attached to em1. We'll > call this Side B. > 10 more vlans configured with IP's for the routing portion. No packet > loss in the routed scenario. > > em0 and vlan199 are bridged > > Host at x.y.199.101 connected to Side B can reach all hosts connected > to Side A except for the bridging machine > Using nslookup on .101 to .254 as a test, tcpdump on vlan199 shows > packets in from .101 to .254 and the returning packets from .254 to > .101. em0 does not show any packets in or out. However packets are not > being returned to the .101 host. > IPFW is not a culprit here as I have tried it with ipfw add 1 allow ip > from any to any. > > Moving the IP of .254 from em0 to vlan199 results in the same packet > loss execpt on the Side A now. > > Not all traffic from Side B to .254 and back is lost. dhcp and icmp do > seem to be working. I am leaning towards an issue with BIND, however > it does bother me that tcpdump sees packets leaving vlan199. > > Anybody have any ideas?? Thanks in advance. > > -Jon > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 09:14:50 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.ORG Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DD6E16A41F for ; Tue, 11 Oct 2005 09:14:50 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69AD943D45 for ; Tue, 11 Oct 2005 09:14:49 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (jylqnu@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.1/8.13.1) with ESMTP id j9B9ElXi092759 for ; Tue, 11 Oct 2005 11:14:48 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.1/8.13.1/Submit) id j9B9Elct092758; Tue, 11 Oct 2005 11:14:47 +0200 (CEST) (envelope-from olli) Date: Tue, 11 Oct 2005 11:14:47 +0200 (CEST) Message-Id: <200510110914.j9B9Elct092758@lurza.secnetix.de> From: Oliver Fromme To: freebsd-net@FreeBSD.ORG In-Reply-To: <05kfk11pk1o960o0bro2lr7d7jhi5l28et@4ax.com> X-Newsgroups: list.freebsd-net User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-RELEASE (i386)) Cc: Subject: Re: VIA VT6103 support (VIA EPIA PD) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-net@FreeBSD.ORG List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2005 09:14:50 -0000 Mike Tancsa wrote: > [ Oliver Fromme wrote: ] > > It has survived several buildworlds and network activity > > without any problems. It's now running today's 6.0-BETA5. > > Here's a copy of dmesg, if someone's interested: > > > > http://www.secnetix.de/~olli/dmesg/epia.6.0-BETA5.txt > > IF you use FAST_IPSEC, load the padlock.,ko as it makes a nice speed > boost! Also, you will need to use the patch in > http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/86598 > otherwise you will get the odd SSH problem when using AES Sounds cool! I'll give that a try this weekend. Thanks for the hint. However, don't quite understand how things work together. Is the padlock.ko module used by IPSec only? Or is it used by OpenSSL, too? Do I have to recompile OpenSSL with special options? I assume that only AES is supported by the hardware, right? So I have to set up my /etc/ssh/ssh_config to use aes128_cbc as the first entry in the "Ciphers" line, right? (I've set it to blowfish by default, because it's faster than aes, but that's without hardware support, of course.) Oh, by the way: What would be an appropriate CPUTYPE for /etc/make.conf for the C3 Nehemiah processor? Currently I don't set any CPUTYPE at all, but I wonder if there's a setting for more efficient code generation. According to the processor information ... CPU: VIA C3 Nehemiah+RNG+ACE (1002.28-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x698 Stepping = 8 Features=0x381b83f .. it supports MMX and SSE, so CPUTYPE="pentium3" should work, I think. But I'm not sure. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "If you aim the gun at your foot and pull the trigger, it's UNIX's job to ensure reliable delivery of the bullet to where you aimed the gun (in this case, Mr. Foot)." -- Terry Lambert, FreeBSD-hackers mailing list. From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 14:01:13 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60AE116A41F; Tue, 11 Oct 2005 14:01:13 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDAFF43D58; Tue, 11 Oct 2005 14:01:12 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E0CA346B7C; Tue, 11 Oct 2005 10:01:11 -0400 (EDT) Date: Tue, 11 Oct 2005 15:01:11 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: performance@FreeBSD.org In-Reply-To: <20051005133730.R87201@fledge.watson.org> Message-ID: <20051011145923.B92528@fledge.watson.org> References: <20051005133730.R87201@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: net@FreeBSD.org Subject: Re: Call for performance evaluation: net.isr.direct X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2005 14:01:13 -0000 On Wed, 5 Oct 2005, Robert Watson wrote: > In 2003, Jonathan Lemon added initial support for direct dispatch of > netisr handlers from the calling thread, as part of his DARPA/NAI Labs > contract in the DARPA CHATS research program. Over the last two years > since then, Sam Leffler and I have worked to refine this implementation, > removing a number of ordering related issues, opportunities for > excessive parallelism, recursion issues, and testing with a broad range > of network components. There has also been a significant effort to > complete MPSAFE locking work throughout the network stack. Combined > with the earlier move to ithreads and a functional direct dispatch > ("process to completion" implementation), there are a number of exciting > possible benefits. If I don't hear anything back in the near future, I will commit a change to 7.x to make direct dispatch the default, in order to let a broader community do the testing. :-) If you are setup to easily test stability and performance relating to direct dispatch, I would appreciate any help. As of 6.0-RC1 and recent 7.x, the name of the sysctl is "net.isr.direct"; previously it has been named "net.isr.enable", but its use is not recommend in versions that do not use the new name. Thanks, Robert N M Watson > > - Possible parallelism by packet source -- ithreads can dispatch > simultaenously into the higher level network stack layers. Since > ithreads can execute in parallel on different CPU, so can code they > invoke directly. > > - Elimination of context switches in the network receive path -- rather > than context switching to the netisr thread from the ithread, we can now > directly execute netisr code from the ithread. > > - A CPU-bound netisr thread on a multi-processor system will no longer > rate limit traffic to the available resources on one CPU. > > - Eliminating the additional queueing in the handoff reduces the > opportunity for queues to overfill as a result of scheduling delays. > > There are, however, some possible downsides and/or trade-offs: > > - Higher level network processing will now compete with the interrupt > handler for CPU resources available to the ithread. This means less > time for the interrupt code to execute in the thread if the thread is > CPU-bound. > > - Lower levels of parallelism between portions of the inbound packet > processing path. Without direct dispatch, there is possible parallelism > between receive network driver execution and higher level stack layers, > whereas with direct dispatch they can no longer execute in parallel. > > - Re-queued packets from tunnel and encapsulation processing will now > require a context switch to process, since they will be processed in the > netisr proper rather than in the ithread, whereas before the netisr > thread would pick them up immediately after completing the current > processing without a context switch. > > - Code that previously ran in the SWI at a SWI priority now runs in the > ithread at an ithread priority, elevating the general priority at which > network processing takes place. > > And there are a few mixed things, that can offer good and bad elements: > > - Less queueing takes place in the network stack in in-bound processing: > packets are taken directly from the driver and processed to completion > one by one, rather than queued for batch processing. Packets will be > dropped before the link layer, rather than on the boundary between the > link and protocol layers. This is good in that we invest less work in > packets we were going to drop anyway, but bad in that less queueing > means less room for scheduling delays. > > In previous FreeBSD releases, such as several 5.x series releases, > net.isr.enable could not be turned on by default because there was > insufficient synchronization in the network stack. As of 5.5 and 6.0, I > believe there is sufficient synchronization, especially given that we force > non-MPSAFE protocol handlers to run in the netisr without direct dispatch. > As such, there has been a gradual conversation going on about making direct > dispatch the default behavior in the 7.x development series, and more > publically documenting and supporting the use of direct dispatch in the 6.x > release engineering series. > > Obviously, this is about two things: performance, and stability. Many of us > have been running with direct dispatch on by default for quite some time, so > it passes some of the basic "does it run" tests. However, since it > significantly increases the opportunity for parallelism in the receive path > of the network stack, it likely will trigger otherwise latent or infrequent > races and bugs to occur more frequently. The second aspect is performance: > many results suggest that direct dispatch has a significant performance > benefit. However, evaluating the impact on a broad range of results is > required in order for us to go ahead with what is effectively a significant > architectural change in how we perform network stack processing. > > To give you a sense of some of the performance effect I've measured recently, > using the netperf measurement tool (with -DHISTOGRAM removed from the FreeBSD > port build), here are some results. In each case, I've put parenthesis > around host or router to indicate which is the host where the configuration > change is being tested. These tests were performed using dual Xeon systems, > and using back-to-back gigabit ethernet cards and the if_em driver: > > TCP round trip benchmark (TCP_RR), host-(host): > > 7.x UP: 0.9% performance improvement > 7.x SMP: 0.7% performance improvement > > TCP round trip benchmark (TCP_RR), host-(router)-host: > > 7.x UP: 2.4% performance improvement > 7.x SMP: 2.9% performance improvement > > UDP round trip benchmark (UDP_RR), host-(host): > > 7.x UP: 0.7% performance improvement > 7.x SMP: 0.6% performance improvement > > UDP round trip benchmark (UDP_RR), host-(router)-host: > > 7.x UP: 2.2% performance improvement > 7.x SMP: 3.0% performance improvement > > TCP stream banchmark (TCP_STREAM), host-(host): > > 7.x UP: 0.8% performance improvement > 7.x SMP: 1.8% performance improvement > > TCP stream benchmark (TCP_STREAM), host-(router)-host: > > 7.x UP: 13.6% performance improvement > 7.x SMP: 15.7% performance improvement > > UDP stream benchmark (UDP_STREAM), host-(host): > > 7.x UP: none > 7.x SMP: none > > UDP stream benchmark (UDP_STREAM), host-(router)-host: > > 7.x UP: none > 7.x SMP: none > > TCP connect benchmark (src/tools/tools/netrate/tcpconnect) > > 7.x UP: 7.90383% +/- 0.553773% > 7.x SMP: 12.2391% +/- 0.500561% > > So in some cases, the impact is negligible -- in other places, it is quite > significant. So far, I've not measured a case where performance has gotten > worse, but that's probably because I've only been measuring a limited number > of cases, and with a fairly limited scope of configurations, especially given > that the hardware I have is pushing the limits of what the wire supports, so > minor changes in latency are possible, but not large changes in throughput. > > So other than a summary of the status quo, this is also a call to action. I > would like to get more widespread benchmarking of the impact of direct > dispatch on network-related workloads. This means a variety of things: > > (1) Performance of low level network services, such as routing, bridging, > and filtering. > > (2) Performance of high level application servces, such as web and > database. > > (3) Performance of integrated kernel network services, such as the NFS > client and server. > > (4) Performance of user space distributed file systems, such as Samba and > AFS. > > All you need to do to switch to direct dispatch mode is set the sysctl or > tunable "net.isr.dispatch" to 1. To disable it again, remove the setting, or > set it to 0. It can be modified at run-time, although during the transition > from one mode to the other, there may be a small quantity of packet > misordering, so benchmarking over the transition is discouraged. > FYI: as of 6.0-RC1 and recent 7.0, net.isr.dispatch is the name of the > variable. In earlier releases, the name of this variable was net.isr.enable. > > Some important details: > > - Only non-local protocol traffic is affected: loopback traffic still goes > via the netisr to avoid issues of recursion and lock order. > > - In the general case, only in-bound traffic is directly affected by this > change. As such, send-only benchmarks may reveal little change. They > are still interesting, however. > > - However, the send path is indirectly affected due to changes in > scheduling, workload, interrupt handling, and so on. > > - Because network benchmarks, especially micro-benchmarks, are especially > sensitive to minor perturbations, I highly recommend running in a > minimal multi-user or ideally single-user environment, and suggest > isolating undesired sources of network traffic from segments where > testing is occuring. For macro-benchmarks this can be less important, > but should be paid attention to. > > - Please make sure debugging features are turned off when running tests -- > especially WITNESS, INVARIANTS, INVARIANT_SUPPORT, and user space malloc > debugging. These can have a significant impact on performance, both > potentially overshadowing changes, and in some cases, actually reversing > results (due to higher overhead under locks, for example). > > - Do not use net.isr.enable in the 5.x line unless you know what you are > doing. While it is reasonably safe with 5.4 forwards, it is not a > supported configuration, and may cause stability issues with specific > workloads. > > - What we're particularly interested in is a statistically meaningful > comparison of the "before" and "after" case. When doing measurements, I > like to run 10-12 samples, and usually discard the first one or two, > depending on the details of the benchmark. I'll then use > src/tools/tools/ministat to compare the data sets. Running a number of > samples is quite important, because the variance in many tests can be > significant, and if the two sample sets overlap, you can quite easily > draw the entirely wrong conclusion about the results from a small number > of measurements in a sample. > > Assuming you have a fixed width font, typicaly output from ministat looks > something like the following and may be human readable: > > x 7SMP/tcpconnect_queue > + 7SMP/tcpconnect_direct > +--------------------------------------------------------------------------+ > |x xx + +| > |xxxxx xx ++ +++++ +| > ||__A__| |___A__| | > +--------------------------------------------------------------------------+ > N Min Max Median Avg Stddev > x 10 5425 5503 5460 5456.3 26.284977 > + 10 6074 6169 6126 6124.1 31.606785 > Difference at 95.0% confidence > 667.8 +/- 27.3121 > 12.2391% +/- 0.500561% > (Student's t, pooled s = 29.0679) > > Of particular interest is if changing to direct dispatch hurts performance in > your environment, and understanding why that is. > > Thanks, > > Robert N M Watson > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to > "freebsd-performance-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 18:04:55 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7CAB16A420; Tue, 11 Oct 2005 18:04:54 +0000 (GMT) (envelope-from josh@metropark.com) Received: from web.metropark.com (209.248.134.200.nw.nuvox.net [209.248.134.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67D4243D45; Tue, 11 Oct 2005 18:04:54 +0000 (GMT) (envelope-from josh@metropark.com) Received: (from root@localhost) by web.metropark.com (8.12.10/8.12.3) id j9BI4tXW096787; Tue, 11 Oct 2005 13:04:55 -0500 (CDT) (envelope-from josh@metropark.com) Received: from jweaver (users.metropark.com [209.248.134.245]) by web.metropark.com (8.12.10/8.12.3av) with ESMTP id j9BI4qLl096732; Tue, 11 Oct 2005 13:04:52 -0500 (CDT) (envelope-from josh@metropark.com) From: "Joshua Weaver" To: "'free bsd'" , Date: Tue, 11 Oct 2005 13:06:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0021_01C5CE64.AC878060" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcXOjpHvXeL0kJ87TJSBCD7GZgOPjQ== X-Virus-Scanned: by AMaViS perl-11 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: GRE tunnels anyone? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2005 18:04:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C5CE64.AC878060 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The company I work for uses a lot of multicast tunnels, usually with a QOS/GRE implementation with quite pricy hardware. I googled around a bit, it looks like basic vpn is supported for FreeBSD. I guess my questions are 1.) Does FreeBSD play well with vpn-capable routers (like a 3Com 5012) 2.) Would getting acceptable latency tunneling multicast mean hardware that's just as expensive as a router costing thousands? TINA Joshua Weaver Senior Systems Engineer Metropark Communications, Inc. (314) 439-1900 main (314) 439-1313 fax (866) NBX-HELP Metropark's Home Page http://www.metropark.com WorldWide NBX Support http://www.nbxhelpdesk.com NBX Accessories http://www.nbxsoftware.com ------=_NextPart_000_0021_01C5CE64.AC878060-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 18:30:03 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4BC216A41F for ; Tue, 11 Oct 2005 18:30:03 +0000 (GMT) (envelope-from tms3@fsklaw.com) Received: from thor-new.fsklaw.com (adsl-64-174-116-34.dsl.lsan03.pacbell.net [64.174.116.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CB2343D5E for ; Tue, 11 Oct 2005 18:30:03 +0000 (GMT) (envelope-from tms3@fsklaw.com) Received: from [192.168.62.67] by thor-new.fsklaw.com with SMTP (EHLO [192.168.62.67]) (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.8.1)); Tue, 11 Oct 2005 11:31:33 -0700 Message-ID: <434C04A7.7090001@fsklaw.com> Date: Tue, 11 Oct 2005 11:29:59 -0700 From: "Thomas M. Skeren III" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20050502 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ArGoMail-Authenticated: tms3 Subject: Strange Network Performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2005 18:30:04 -0000 I have 6 5.3 and 3 5.4 for servers. The servers provide Samba/LDAP, DHCP, Natting, IPSec (for vlan tunnels). One, and only one server behaves very oddly. If I do a transfer to the other BSD server there (LDAP Master and DNS), I get full wire speed: tp> 150 Opening BINARY mode data connection for 'open.tar.bz2'. ftp> 66% |***************************************************************************** | 355 MB 7.56 MB/s ftp> However when I issue a get command I get this: ftp> get open.tar.bz2 local: open.tar.bz2 remote: open.tar.bz2 229 Entering Extended Passive Mode (|||61238|) 150 Opening BINARY mode data connection for 'open.tar.bz2' (557269784 bytes). 0% | | 2849 KB 105.55 KB/s 1:25:28 ETA The data transfer rate is about 93.5% of these speeds for smb transfers. No other server exhibits this behavior. I'm really puzzeled. Here's an ifconfig -a: camarillo# ifconfig -a fxp0: flags=8843 mtu 1500 options=b inet xx.xx.xx.xx netmask 0xfffffff8 broadcast xx.xx.xx.xx inet6 xxxxxxxxxxxxxxx%fxp0 prefixlen 64 scopeid 0x1 ether 00:0e:0c:50:b1:fa media: Ethernet autoselect (100baseTX ) status: active sk0: flags=8843 mtu 1500 inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::214:85ff:fe14:92b7%sk0 prefixlen 64 scopeid 0x2 ether 00:14:85:14:92:b7 media: Ethernet autoselect (100baseTX ) status: active plip0: flags=108810 mtu 1500 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 gif0: flags=8051 mtu 1280 tunnel inet xx.xx.xx.xx --> xx.xx.xx.xx inet6 xxxxxxxxxxxxxxxgif0 prefixlen 64 scopeid 0x5 inet 192.168.0.1 --> 192.168.64.1 netmask 0xffffff00 camarillo# Any suggestions as to wtf is up would be appreciated. TMS III From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 18:56:17 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 998DB16A41F for ; Tue, 11 Oct 2005 18:56:17 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5942B43D45 for ; Tue, 11 Oct 2005 18:56:17 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from [192.168.1.3] ([68.161.71.31]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IO700K2JLSVE3T1@vms044.mailsrvcs.net> for freebsd-net@freebsd.org; Tue, 11 Oct 2005 13:53:20 -0500 (CDT) Date: Tue, 11 Oct 2005 14:53:27 -0400 From: Chuck Swiger In-reply-to: <434C04A7.7090001@fsklaw.com> To: "Thomas M. Skeren III" Message-id: <434C0A27.7060306@mac.com> Organization: The Courts of Chaos MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit X-Accept-Language: en-us, en References: <434C04A7.7090001@fsklaw.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Cc: freebsd-net@freebsd.org Subject: Re: Strange Network Performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2005 18:56:17 -0000 Thomas M. Skeren III wrote: [ ...FTP transfer speeds very different... ] > The data transfer rate is about 93.5% of these speeds for smb > transfers. No other server exhibits this behavior. I'm really puzzeled. [ ... ] > Any suggestions as to wtf is up would be appreciated. You should look at "netstat -i" and check for packet errors, perhaps, as well as double-checking cabling and duplex and so forth. This makes a nice network test: ping -i 0.001 -s 1450 -c 100 host.example.com If you adjust "sysctl net.inet.icmp.icmplim" upwards, you can change the count to send as much data as you want. Using a big size is assymmetric and involves much more data sent from the machine running the commmand than is received, using the default side sends roughly equal amounts of data. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 20:20:30 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3160A16A428; Tue, 11 Oct 2005 20:20:30 +0000 (GMT) (envelope-from djh@nebcorp.com) Received: from ratchet.nebcorp.com (ratchet.nebcorp.com [205.217.153.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id F180E43D46; Tue, 11 Oct 2005 20:20:29 +0000 (GMT) (envelope-from djh@nebcorp.com) Received: by ratchet.nebcorp.com (Postfix, from userid 1014) id D6AA7D983B; Tue, 11 Oct 2005 13:20:29 -0700 (PDT) Date: Tue, 11 Oct 2005 13:20:29 -0700 From: Danny Howard To: Joshua Weaver Message-ID: <20051011202029.GI564@ratchet.nebcorp.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Loop: djhoward@uiuc.edu Cc: freebsd-net@freebsd.org, 'free bsd' Subject: Re: GRE tunnels anyone? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2005 20:20:30 -0000 On Tue, Oct 11, 2005 at 01:06:58PM -0500, Joshua Weaver wrote: > The company I work for uses a lot of multicast tunnels, usually with a > QOS/GRE implementation with quite pricy hardware. I googled around a bit, > it looks like basic vpn is supported for FreeBSD. I guess my questions are > > 1.) Does FreeBSD play well with vpn-capable routers (like a 3Com 5012) > > 2.) Would getting acceptable latency tunneling multicast mean hardware > that's just as expensive as a router costing thousands? Joshua, We run a tunnel using gif interfaces, managed by racoon. The performance is less than super, but I think that's a constraint of our network resources. My answer would be: "Why not grab a spare box and try it out?" If the day's diversion may lead you to saving thousands, then please spend a little more effort and write a brief article on a blog or a journal somewhere to help the next person who comes along asking your question. :) The handbook has a great chapter on how-to-setup-a-tunnel-from-scratch, though it sounds like you don't need a lot of hand-holding. I would LIKE to think that if we spent a bit of cash on proper VPN hardware, that tunnel maintenance would be easier and performance might be better. Well, that's an aside. Good Luck, -danny -- http://dannyman.toldme.com/ From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 21:28:35 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBEAF16A41F; Tue, 11 Oct 2005 21:28:35 +0000 (GMT) (envelope-from jmire@lsuhsc.edu) Received: from EXCHMX2.master.lsuhsc.edu (exchmx2.lsuhsc.edu [155.58.212.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A10443D5F; Tue, 11 Oct 2005 21:28:33 +0000 (GMT) (envelope-from jmire@lsuhsc.edu) Received: by exchmx2.master.lsuhsc.edu with Internet Mail Service (5.5.2657.72) id <4R9F8YKR>; Tue, 11 Oct 2005 16:22:01 -0500 Message-ID: From: "Mire, John" To: Danny Howard , Joshua Weaver Date: Tue, 11 Oct 2005 16:22:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Cc: freebsd-net@freebsd.org, 'free bsd' Subject: RE: GRE tunnels anyone? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2005 21:28:36 -0000 In the past, with RELEASE-4.X we had multiple tunnels coming in to our 7206VXR, I can't put my hands on the the IOS config at the moment but here's the startup script used on the two remote boxes. #!/bin/sh if [ $# -eq 0 ]; then disable_config_ipsec="NO" else if [ "$#" -eq 1 ]; then case "$1" in [Yy][Ee][Ss]) disable_config_ipsec="YES" ;; *) disable_config_ipsec="NO" ;; esac fi fi ################################################################# # # /usr/local/etc/rc.d/tunnel.sh - configure gif tunnels and ipsec # $Id: tunnel.sh,v 1.3 2002/05/13 14:21:30 jmire Exp $ # ################################################################# # Function definitions f_ipsecinit1(){ /usr/sbin/setkey -FP #Flush the SPD entries /usr/sbin/setkey -F #Flush the SAD entries } # end f_ipsecinit1 f_gifconfig1() { ifconfig $GIF destroy # make sure gif doesn't exist with old config ifconfig $GIF create # create gif interface gifconfig $GIF $BSD1_PUB $BSD2_PUB # setup the tunnel endpoints ifconfig $GIF inet $BSD1_IP $BSD2_IP netmask $NETMASK # setup the network connects inside tunnel route add $BSD2_NET $BSD2_IP # setup the route } # end f_gifconfig1 f_confipsec1() { /usr/sbin/setkey -c << EOF spdadd $BSD1_PUB $BSD2_PUB any -P out ipsec esp/tunnel/${BSD1_PUB}-${BSD2_PUB}/require; spdadd $BSD2_PUB $BSD1_PUB any -P in ipsec esp/tunnel/${BSD2_PUB}-${BSD1_PUB}/require; EOF } # end f_confipsec1 f_confipsec3() { /usr/sbin/setkey -c << EOF spdadd $BSD1_NET $BSD2_NET any -P out ipsec esp/tunnel/${BSD1_IP}-${BSD2_IP}/require; spdadd $BSD2_NET $BSD1_NET any -P in ipsec esp/tunnel/${BSD2_IP}-${BSD1_IP}/require; EOF } # end f_confipsec3 f_config-remote1() { ############################################################## # gif0: flags=8051 mtu 1280 # tunnel inet 24.242.107.143 --> 206.176.175.6 # inet 192.168.1.1 --> 192.168.4.1 netmask 0xffffff00 # # set local variables # gif0, 24.242.107.143, 205.166.221.1, 192.168.1.1, 192.168.4.1 local GIF="gif0" local BSD2_IP="192.168.4.1" local BSD2_NET="192.168.4.0/24" local BSD2_PUB="206.176.175.6" local BSD1_IP="192.168.1.1" local BSD1_NET="192.168.1.0/24" local BSD1_PUB="24.242.107.143" local NETMASK="255.255.255.0" f_gifconfig1 > /dev/null # set gif0 config ifconfig $GIF # check config case ${disable_config_ipsec} in [Nn][Oo]) f_confipsec1 # set policy setkey -DP ;; *) ;; esac } # end f_config-remote1 f_config-remote2() { ############################################################# # gif0: flags=8051 mtu 1280 # tunnel inet 207.254.204.147 --> 206.176.175.6 # inet 192.168.0.5 --> 192.168.0.6 netmask 0xfffffffc # # gif0, 207.254.204.147, 205.166.221.1, 192.168.0.5, 192.168.0.6 local GIF="gif0" local BSD2_IP="192.168.0.6" local BSD2_NET="192.168.4.0/24" local BSD2_PUB="206.176.175.6" local BSD1_IP="192.168.0.5" local BSD1_NET="192.168.3.0/24" local BSD1_PUB="207.254.204.147" local NETMASK="255.255.255.252" f_gifconfig1 > /dev/null # set gif0 config ifconfig $GIF # check config case ${disable_config_ipsec} in [Nn][Oo]) f_confipsec1 # set policy setkey -DP ;; *) ;; esac } # end f_config-fosa3 # main ############################################################# HOSTNAME=`/bin/hostname -s` #kill racoon if running killall racoon f_ipsecinit1 # initialize case $HOSTNAME in Remote1) echo $HOSTNAME f_config-remote1 ;; Remote2) echo $HOSTNAME f_config-remote2 ;; esac -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Danny Howard Sent: Tuesday, October 11, 2005 3:20 PM To: Joshua Weaver Cc: freebsd-net@freebsd.org; 'free bsd' Subject: Re: GRE tunnels anyone? On Tue, Oct 11, 2005 at 01:06:58PM -0500, Joshua Weaver wrote: > The company I work for uses a lot of multicast tunnels, usually with a > QOS/GRE implementation with quite pricy hardware. I googled around a bit, > it looks like basic vpn is supported for FreeBSD. I guess my questions are > > 1.) Does FreeBSD play well with vpn-capable routers (like a 3Com 5012) > > 2.) Would getting acceptable latency tunneling multicast mean hardware > that's just as expensive as a router costing thousands? Joshua, We run a tunnel using gif interfaces, managed by racoon. The performance is less than super, but I think that's a constraint of our network resources. My answer would be: "Why not grab a spare box and try it out?" If the day's diversion may lead you to saving thousands, then please spend a little more effort and write a brief article on a blog or a journal somewhere to help the next person who comes along asking your question. :) The handbook has a great chapter on how-to-setup-a-tunnel-from-scratch, though it sounds like you don't need a lot of hand-holding. I would LIKE to think that if we spent a bit of cash on proper VPN hardware, that tunnel maintenance would be easier and performance might be better. Well, that's an aside. Good Luck, -danny -- http://dannyman.toldme.com/ _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 22:07:27 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C8E316A41F; Tue, 11 Oct 2005 22:07:27 +0000 (GMT) (envelope-from julian@elischer.org) Received: from delight.idiom.com (outbound.idiom.com [216.240.47.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBDE943D49; Tue, 11 Oct 2005 22:07:26 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id 401FE1F7D3A; Tue, 11 Oct 2005 15:07:26 -0700 (PDT) Received: from [192.168.2.2] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id j9BM1NII090363; Tue, 11 Oct 2005 15:01:24 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <434C362A.3070604@elischer.org> Date: Tue, 11 Oct 2005 15:01:14 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.10) Gecko/20050823 X-Accept-Language: en, hu MIME-Version: 1.0 To: luigi@freebsd.org, net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: ipfw man page inconsistency X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2005 22:07:27 -0000 The man page says: (yes, at the moment there is no way to differentiate between ether_demux and bdg_forward). However in the "options" section there is a "bridged" keyword bridged Matches only bridged packets. so we should be able to differentiate between: # packets from ether_demux or bdg_forward ipfw add 10 skipto 1000 all from any to any layer2 in with ipfw add 10 skipto 1000 all from any to any layer2 in and ipfw add 10 skipto 1000 all from any to any layer2 in bridged correct? From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 03:18:46 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 819ED16A41F for ; Wed, 12 Oct 2005 03:18:46 +0000 (GMT) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F0F943D45 for ; Wed, 12 Oct 2005 03:18:45 +0000 (GMT) (envelope-from mike@sentex.net) Received: from BLUELAPIS.sentex.ca (cage.simianscience.com [64.7.134.1]) by smarthost2.sentex.ca (8.13.4/8.13.4) with SMTP id j9C3Iib4009820; Tue, 11 Oct 2005 23:18:44 -0400 (EDT) (envelope-from mike@sentex.net) From: Mike Tancsa To: Oliver Fromme Date: Tue, 11 Oct 2005 23:18:49 -0400 Message-ID: <7hnok1p8bnvjrdps7273k20d0fi8ia8jkj@4ax.com> References: <05kfk11pk1o960o0bro2lr7d7jhi5l28et@4ax.com> <200510110914.j9B9Elct092758@lurza.secnetix.de> In-Reply-To: <200510110914.j9B9Elct092758@lurza.secnetix.de> X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: freebsd-net@freebsd.org Subject: Re: VIA VT6103 support (VIA EPIA PD) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 03:18:46 -0000 On Tue, 11 Oct 2005 11:14:47 +0200 (CEST), in sentex.lists.freebsd.net you wrote: >Mike Tancsa wrote: > > [ Oliver Fromme wrote: ] > > > It has survived several buildworlds and network activity > > > without any problems. It's now running today's 6.0-BETA5. > > > Here's a copy of dmesg, if someone's interested: > > >=20 > > > http://www.secnetix.de/~olli/dmesg/epia.6.0-BETA5.txt > >=20 > > IF you use FAST_IPSEC, load the padlock.,ko as it makes a nice speed > > boost! Also, you will need to use the patch in > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Di386/86598 > > otherwise you will get the odd SSH problem when using AES > >Sounds cool! I'll give that a try this weekend. >Thanks for the hint. > >However, don't quite understand how things work together. >Is the padlock.ko module used by IPSec only? Or is it >used by OpenSSL, too? Do I have to recompile OpenSSL with >special options? Padlock.ko works with the FreeBSD CryptoDev framework. So things like geil(8) will make use of it as well as anything that uses the cryptodev framework (e.g. FAST_IPSEC). See the docs on cryptodev for more info > >I assume that only AES is supported by the hardware, right? Correct. Not all Via's support it either. The ACE in the CPU features tells you that yours does. >So I have to set up my /etc/ssh/ssh_config to use aes128_cbc >as the first entry in the "Ciphers" line, right? (I've set >it to blowfish by default, because it's faster than aes, >but that's without hardware support, of course.) Yes > >Oh, by the way: What would be an appropriate CPUTYPE for Generally, I have not set it as I have been burned in the past for generally little benefit. >/etc/make.conf for the C3 Nehemiah processor? Currently I >don't set any CPUTYPE at all, but I wonder if there's a >setting for more efficient code generation. According to >the processor information ... > >CPU: VIA C3 Nehemiah+RNG+ACE (1002.28-MHz 686-class CPU) > Origin =3D "CentaurHauls" Id =3D 0x698 Stepping =3D 8 > = Features=3D0x381b83f > >.. it supports MMX and SSE, so CPUTYPE=3D"pentium3" should >work, I think. But I'm not sure. > >Best regards > Oliver -------------------------------------------------------- Mike Tancsa, Sentex communications http://www.sentex.net Providing Internet Access since 1994 mike@sentex.net, (http://www.tancsa.com) From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 05:16:57 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A067616A41F for ; Wed, 12 Oct 2005 05:16:57 +0000 (GMT) (envelope-from dave-sender-1932b5@seddon.ca) Received: from seddon.ca (seddon.ca [203.209.212.18]) by mx1.FreeBSD.org (Postfix) with SMTP id D642C43D46 for ; Wed, 12 Oct 2005 05:16:56 +0000 (GMT) (envelope-from dave-sender-1932b5@seddon.ca) Received: (qmail 27012 invoked by uid 89); 12 Oct 2005 05:16:54 -0000 Received: by seddon.ca (tmda-sendmail, from uid 89); Wed, 12 Oct 2005 15:16:54 +1000 (EST) References: <4344DDE5.1070301@roamingsolutions.net> In-Reply-To: <4344DDE5.1070301@roamingsolutions.net> To: freebsd-net@freebsd.org Date: Wed, 12 Oct 2005 15:16:52 +1000 Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit From: Dave+Seddon Message-ID: <1129094214.26994.TMDA@seddon.ca> X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) Subject: ipf ttl question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: das-keyword-net.6770cb@seddon.ca List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 05:16:57 -0000 Greetings, I'm running ipf+ipnat and proftp. I'm encountering a problem where the data connection is working fine, however because there's a large tranfer no data is tranferred on port 21, so the port 21 session dies (ttl expires). The transfer is running now. How can I change the ttl on the port 21 session, without dropping the session? Or can I change the ruleset to allow everything without dropping the session? Regards, Dave From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 11:45:19 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80DE816A41F; Wed, 12 Oct 2005 11:45:19 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4841A43D46; Wed, 12 Oct 2005 11:45:19 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout1.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id j9CBiEpW088169; Wed, 12 Oct 2005 04:44:15 -0700 (PDT) Date: Wed, 12 Oct 2005 20:44:13 +0900 Message-ID: From: gnn@freebsd.org To: Robert Watson In-Reply-To: <20051011145923.B92528@fledge.watson.org> References: <20051005133730.R87201@fledge.watson.org> <20051011145923.B92528@fledge.watson.org> User-Agent: Wanderlust/2.12.2 (99 Luftballons) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin8.1.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: performance@freebsd.org, net@freebsd.org Subject: Re: Call for performance evaluation: net.isr.direct X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 11:45:19 -0000 At Tue, 11 Oct 2005 15:01:11 +0100 (BST), rwatson wrote: > If I don't hear anything back in the near future, I will commit a > change to 7.x to make direct dispatch the default, in order to let a > broader community do the testing. :-) If you are setup to easily > test stability and performance relating to direct dispatch, I would > appreciate any help. > One thing I would caution, though I have no proof nor have I made any tests (yes, I know, bad gnn), is that I would expect this change to degrade non-network performance when the network is under load. This kind of change is most likely to help those with purely network loads, i.e. routers, bridges, etc and to hurt anyone else. Are you absolutely sure we should make this the default? Later, George From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 12:33:27 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 166A216A41F; Wed, 12 Oct 2005 12:33:27 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id E60D543D69; Wed, 12 Oct 2005 12:33:07 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 82CFE46B0A; Wed, 12 Oct 2005 08:33:06 -0400 (EDT) Date: Wed, 12 Oct 2005 13:33:06 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: gnn@freebsd.org In-Reply-To: Message-ID: <20051012132648.J7178@fledge.watson.org> References: <20051005133730.R87201@fledge.watson.org> <20051011145923.B92528@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: performance@freebsd.org, net@freebsd.org Subject: Re: Call for performance evaluation: net.isr.direct X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 12:33:27 -0000 On Wed, 12 Oct 2005 gnn@freebsd.org wrote: > At Tue, 11 Oct 2005 15:01:11 +0100 (BST), > rwatson wrote: >> If I don't hear anything back in the near future, I will commit a >> change to 7.x to make direct dispatch the default, in order to let a >> broader community do the testing. :-) If you are setup to easily >> test stability and performance relating to direct dispatch, I would >> appreciate any help. > > One thing I would caution, though I have no proof nor have I made any > tests (yes, I know, bad gnn), is that I would expect this change to > degrade non-network performance when the network is under load. This > kind of change is most likely to help those with purely network loads, > i.e. routers, bridges, etc and to hurt anyone else. Are you absolutely > sure we should make this the default? In theory, as I mentioned in my earlier e-mail, this does result in more network processing occurring at a hardware ithread priority. However, the software ithread (swi) priority is already quite high. Looking closely at that is probably called for -- specifically, how will this impact scheduling for other hardware (rather than software) ithreads? The most interesting effect I've seen on non-network applications is that, because the network stack now uses significantly less CPU when under high load, more CPU is available for other activities. With the performance of network hardware available on server now often exceeding the CPU capacity of those servers (as compared to a few years ago when 100mbps cards could be trivially saturated by server hardware), the cost of processing packets is now back up again, so this can occur with relative ease. Another interesting point is that remote traffic can now no longer result in a denial of service of local traffic by virtue of overflowing the netisr queue. Previously, a single queue was shared by all network interfaces going to the netisr, and in the direct dispatch model, the queueing now happens almost entirely in the device driver and skips entering a queue to get to the stack. This has some other interesting effects, not least that older cards with less buffering now see significantly less queue space, but I'm not sure if that's significant. In general, I agree with your point though: we need to evaluate the effect of this change on a broad array of real-world workloads. Hence my e-mail, which so far has seen two responses -- a private one from Mike Tancsa offering to run testing, and your public one. So anyone willing to help evaluate the performance of this change would be most welcome to. Robert N M Watson From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 13:21:23 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC34A16A41F for ; Wed, 12 Oct 2005 13:21:23 +0000 (GMT) (envelope-from thomas@FreeBSD.ORG) Received: from melusine.cuivre.fr.eu.org (melusine.cuivre.fr.eu.org [82.225.155.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F75243D46 for ; Wed, 12 Oct 2005 13:21:23 +0000 (GMT) (envelope-from thomas@FreeBSD.ORG) Received: by melusine.cuivre.fr.eu.org (Postfix, from userid 1000) id 40C4E2C43B; Wed, 12 Oct 2005 15:21:21 +0200 (CEST) Date: Wed, 12 Oct 2005 15:21:21 +0200 From: Thomas Quinot To: freebsd-net@freebsd.org Message-ID: <20051012132121.GA6218@melusine.cuivre.fr.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-message-flag: WARNING! Using Outlook can damage your computer. User-Agent: Mutt/1.5.8i Subject: RSVP on recent FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 13:21:23 -0000 All, Is anyone running any RSVP daemon on a FreeBSD release >= 5? I would like to do RSVP with ALTQ, but the KOM RSVP daemon (3.0f) won't compile under 5.4-REL (many C++ problems). Thomas. From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 14:19:09 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEE6D16A420 for ; Wed, 12 Oct 2005 14:19:09 +0000 (GMT) (envelope-from mkarsten@cs.uwaterloo.ca) Received: from services110.cs.uwaterloo.ca (services110.cs.uwaterloo.ca [129.97.152.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 133C543D73 for ; Wed, 12 Oct 2005 14:19:08 +0000 (GMT) (envelope-from mkarsten@cs.uwaterloo.ca) Received: from [129.97.34.33] (kalli.uwaterloo.ca [129.97.34.33]) by services110.cs.uwaterloo.ca (8.11.7/8.11.7) with ESMTP id j9CEJ5b24089 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Wed, 12 Oct 2005 10:19:06 -0400 (EDT) Message-ID: <434D1B59.4010006@cs.uwaterloo.ca> Date: Wed, 12 Oct 2005 10:19:05 -0400 From: Martin Karsten User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20051012132121.GA6218@melusine.cuivre.fr.eu.org> In-Reply-To: <20051012132121.GA6218@melusine.cuivre.fr.eu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at rhadamanthus with ID 434D1B59.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on localhost X-Virus-Status: Clean Subject: Re: RSVP on recent FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 14:19:10 -0000 I have an unsupported patch for up to gcc 4.0. I'll send it as separate email to you and will eventually put it on my web page. Martin Thomas Quinot wrote: > All, > > Is anyone running any RSVP daemon on a FreeBSD release >= 5? > I would like to do RSVP with ALTQ, but the KOM RSVP daemon (3.0f) won't > compile under 5.4-REL (many C++ problems). > > Thomas. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 17:59:05 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B191E16A41F for ; Wed, 12 Oct 2005 17:59:05 +0000 (GMT) (envelope-from caiquanqing@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 992A843D64 for ; Wed, 12 Oct 2005 17:58:58 +0000 (GMT) (envelope-from caiquanqing@gmail.com) Received: by xproxy.gmail.com with SMTP id t12so109883wxc for ; Wed, 12 Oct 2005 10:58:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=PYLJBnsAozj9TpyNrpfkOzJZ3gWpRoibMjblFRAk/YabpTL0JAi6zCJQotZHouWcZACTp6/38MYbPahOO598eoRk8PfGg3RxutAniBBydOpHfaiDKFPEd+4KwN3+1Fh1/O6zdt+ShPSJeOoaKATayiy5KBgXA3kVBRC/ua1t0Q4= Received: by 10.70.51.7 with SMTP id y7mr255307wxy; Wed, 12 Oct 2005 10:58:57 -0700 (PDT) Received: by 10.70.11.18 with HTTP; Wed, 12 Oct 2005 10:58:57 -0700 (PDT) Message-ID: <2b22951e0510121058u49cccf20kddd55352543c2304@mail.gmail.com> Date: Wed, 12 Oct 2005 10:58:57 -0700 From: "Cai, Quanqing" To: freebsd-current@freebsd.org, freebsd-drivers@freebsd.org, freebsd-firewire@freebsd.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: kiyohara@kk.iij4u.or.jp Subject: Regarding kern/73852, please help to apply the patch thus we can close this bug. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 17:59:05 -0000 Hi guys, I noticed there is bug filed by KIYOHARA Takashi with a patch, link is here: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/73852, I tested if_fwip w= ith this patch, it works great for me. When we switch byte-order two times on i386, the byte-order will back to original. if you look at the files src/lib/libc/i386/net/ntohl.S and src/lib/libc/i386/net/htonl.S, you will find exact same code: movl 4(%esp),%eax bswap %eax ret This tells everything. So I hope somebody can apply the patch made by KIYOHARA Takashi and close this bug. Thanks Cai, Quanqing From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 18:50:59 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9ACEA16A41F for ; Wed, 12 Oct 2005 18:50:59 +0000 (GMT) (envelope-from caiquanqing@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1294D43D53 for ; Wed, 12 Oct 2005 18:50:57 +0000 (GMT) (envelope-from caiquanqing@gmail.com) Received: by xproxy.gmail.com with SMTP id t12so117405wxc for ; Wed, 12 Oct 2005 11:50:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Vk10lzzcanNDb607JybyMjZK739D4MvyU4lRjAo3TwTbjACmVFC6WtAp/l5a17YbILnToYd8eUSpWs5Fn8Z5hWq0125G1n6+9UwHTIYqHcxczj9gl88s4B1VaWaeCmpD/8wR5BhT1VXklMlZfelc6mgAJgrzY+MF3astKowSxgo= Received: by 10.70.87.14 with SMTP id k14mr283476wxb; Wed, 12 Oct 2005 11:50:57 -0700 (PDT) Received: by 10.70.11.18 with HTTP; Wed, 12 Oct 2005 11:50:57 -0700 (PDT) Message-ID: <2b22951e0510121150o7be85033ic054cabed7e94e5e@mail.gmail.com> Date: Wed, 12 Oct 2005 11:50:57 -0700 From: "Cai, Quanqing" To: freebsd-current@freebsd.org, freebsd-drivers@freebsd.org, freebsd-firewire@freebsd.org, freebsd-net@freebsd.org In-Reply-To: <2b22951e0510121058u49cccf20kddd55352543c2304@mail.gmail.com> MIME-Version: 1.0 References: <2b22951e0510121058u49cccf20kddd55352543c2304@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: kiyohara@kk.iij4u.or.jp Subject: Re: Regarding kern/73852, please help to apply the patch thus we can close this bug. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 18:50:59 -0000 Forget to mention that my test machines, one is 7.0-CURRENT, another one is FreeBSD 6.0-RC1. So I think we can MFC to 6.x too. Cai, Quanqing On 10/12/05, Cai, Quanqing wrote: > > Hi guys, > > I noticed there is bug filed by KIYOHARA Takashi > with a patch, link is here: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/73852, I tested if_fwip > with this patch, it works great for me. When we switch byte-order two tim= es > on i386, the byte-order will back to original. if you look at the files > src/lib/libc/i386/net/ntohl.S and src/lib/libc/i386/net/htonl.S, you will > find exact same code: > > movl 4(%esp),%eax > bswap %eax > ret > > This tells everything. > > So I hope somebody can apply the patch made by KIYOHARA Takashi and close > this bug. > > Thanks > Cai, Quanqing From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 20:28:37 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16A5A16A41F; Wed, 12 Oct 2005 20:28:37 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2A7843D55; Wed, 12 Oct 2005 20:28:34 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id j9CKSXcp011348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Oct 2005 16:28:34 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id j9CKSSoL007159; Wed, 12 Oct 2005 16:28:28 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17229.29164.891534.200216@grasshopper.cs.duke.edu> Date: Wed, 12 Oct 2005 16:28:28 -0400 (EDT) To: Robert Watson In-Reply-To: <20051008143854.B84936@fledge.watson.org> References: <20051008143854.B84936@fledge.watson.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: net@FreeBSD.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 20:28:37 -0000 Speaking of net.isr, is there any reason why if_simloop() calls netisr_queue() rather than netisr_dispatch()? Drew From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 20:32:06 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 607E416A41F for ; Wed, 12 Oct 2005 20:32:06 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id C911D43D46 for ; Wed, 12 Oct 2005 20:32:05 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Wed, 12 Oct 2005 16:48:23 -0400 From: John Baldwin To: "Yuriy N. Shkandybin" Date: Wed, 12 Oct 2005 16:10:46 -0400 User-Agent: KMail/1.8.2 References: <092e01c5cb15$f7fe5840$6504010a@Jura> In-Reply-To: <092e01c5cb15$f7fe5840$6504010a@Jura> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510121610.47507.jhb@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: if_nge & if_lge drivers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 20:32:06 -0000 On Friday 07 October 2005 04:06 am, Yuriy N. Shkandybin wrote: > Hello. > > I saw John Baldwin commit to if_lge.c rev 1.43 and perform same changes for > if_nge.c I've tested it and it works. > Patch in attachment or available from > http://www.netams.com/if_nge.c.patch > > > > Also i've noticed if_lge affected same problem i've met nge. > In if_lgereg.h we have > struct lge_list_data { > struct lge_rx_desc lge_rx_list[LGE_RX_LIST_CNT]; > struct lge_tx_desc lge_tx_list[LGE_TX_LIST_CNT]; > }; > > In if_lge.c > 524: sc->lge_ldata = contigmalloc(sizeof(struct lge_list_data), M_DEVBUF, > M_NOWAIT, 0, 0xffffffff, PAGE_SIZE, 0); > > So lge_rx_list and lge_tx_list might be initialized with garbage in it. > > But in lge_stop() there is: > /* > * Free data in the RX lists. > */ > for (i = 0; i < LGE_RX_LIST_CNT; i++) { > if (sc->lge_ldata->lge_rx_list[i].lge_mbuf != NULL) { > m_freem(sc->lge_ldata->lge_rx_list[i].lge_mbuf); > sc->lge_ldata->lge_rx_list[i].lge_mbuf = NULL; > } > } > > And lge_stop() called from lge_init() (if_lge.c line 1242) > So m_freem() called on garbage from lge_rx_list! > > I suggest to add M_ZERO to contigmalloc() flags for both if_nge.c and > if_lge.c > > > Jura Note that lge() has a bzero() call after the contigmalloc(), but M_ZERO is probably better to use: sc->lge_ldata = contigmalloc(sizeof(struct lge_list_data), M_DEVBUF, M_NOWAIT, 0, 0xffffffff, PAGE_SIZE, 0); ... bzero(sc->lge_ldata, sizeof(struct lge_list_data)); I'll put that in my lge(4) patches and incorporate your nge(4) patches. One issue with your nge(4) patch is that you moved the bus_setup_intr() up when it really should happen after ether_ifattach(). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 20:32:06 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65F0416A420 for ; Wed, 12 Oct 2005 20:32:06 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id C929643D48 for ; Wed, 12 Oct 2005 20:32:05 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Wed, 12 Oct 2005 16:48:23 -0400 From: John Baldwin To: "Yuriy N. Shkandybin" Date: Wed, 12 Oct 2005 16:21:10 -0400 User-Agent: KMail/1.8.2 References: <092e01c5cb15$f7fe5840$6504010a@Jura> In-Reply-To: <092e01c5cb15$f7fe5840$6504010a@Jura> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510121621.11666.jhb@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: if_nge & if_lge drivers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 20:32:06 -0000 On Friday 07 October 2005 04:06 am, Yuriy N. Shkandybin wrote: > Hello. > > I saw John Baldwin commit to if_lge.c rev 1.43 and perform same changes for > if_nge.c I've tested it and it works. > Patch in attachment or available from > http://www.netams.com/if_nge.c.patch > > > > Also i've noticed if_lge affected same problem i've met nge. > In if_lgereg.h we have > struct lge_list_data { > struct lge_rx_desc lge_rx_list[LGE_RX_LIST_CNT]; > struct lge_tx_desc lge_tx_list[LGE_TX_LIST_CNT]; > }; > > In if_lge.c > 524: sc->lge_ldata = contigmalloc(sizeof(struct lge_list_data), M_DEVBUF, > M_NOWAIT, 0, 0xffffffff, PAGE_SIZE, 0); > > So lge_rx_list and lge_tx_list might be initialized with garbage in it. > > But in lge_stop() there is: > /* > * Free data in the RX lists. > */ > for (i = 0; i < LGE_RX_LIST_CNT; i++) { > if (sc->lge_ldata->lge_rx_list[i].lge_mbuf != NULL) { > m_freem(sc->lge_ldata->lge_rx_list[i].lge_mbuf); > sc->lge_ldata->lge_rx_list[i].lge_mbuf = NULL; > } > } > > And lge_stop() called from lge_init() (if_lge.c line 1242) > So m_freem() called on garbage from lge_rx_list! > > I suggest to add M_ZERO to contigmalloc() flags for both if_nge.c and > if_lge.c Also, is there a reason you added a call to nge_reset() after nge_stop() in nge_init()? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 20:36:02 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9F9D16A41F for ; Wed, 12 Oct 2005 20:36:02 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C5B943D45 for ; Wed, 12 Oct 2005 20:36:02 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 765DA46BDA; Wed, 12 Oct 2005 16:36:01 -0400 (EDT) Date: Wed, 12 Oct 2005 21:36:01 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andrew Gallatin In-Reply-To: <17229.29164.891534.200216@grasshopper.cs.duke.edu> Message-ID: <20051012212915.E66014@fledge.watson.org> References: <20051008143854.B84936@fledge.watson.org> <17229.29164.891534.200216@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: net@FreeBSD.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 20:36:03 -0000 On Wed, 12 Oct 2005, Andrew Gallatin wrote: > Speaking of net.isr, is there any reason why if_simloop() calls > netisr_queue() rather than netisr_dispatch()? Yes -- it's basically to prevent recursion for loopback traffic, which can result in both lock orders and general concerns regarding reentrance. To be specific: if you send a packet on a loopback TCP socket, it gets processes asynchronously in the netisr rather than immediately walking back into the TCP code again. Right now WITNESS would warn about this, but there were also quite bad things that could happen before we did the locking work -- for example, when connections are torn down. It also avoids Really Deep Stacks. At some point, someone needs to look at some scheduler traces and make sure we're not seeing anything silly like the following: - Socket output delivers to TCP, which outputs to loopback, which inserts the packet into the netisr queue, waking up the netisr thread. - The netisr, running at a lower priority, preempts the running thread, which may still hold TCP locks, causing it to hit to the lock and yield to the user thread, which will now run briefly with depressed priority due to priority propagation. I.e., it may be that we're taking untimely context switches on UP for loopback traffic. I've not actually seen this, but we should make sure we're not seeing it. Robert N M Watson From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 21:17:10 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 533E216A41F; Wed, 12 Oct 2005 21:17:10 +0000 (GMT) (envelope-from jura@networks.ru) Received: from networks.ru (orange.networks.ru [80.249.138.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74FDD43D45; Wed, 12 Oct 2005 21:17:08 +0000 (GMT) (envelope-from jura@networks.ru) X-Spam-Status: No, hits=0.0 required=2.0 Received: from [83.237.16.183] (HELO notebook) by networks.ru (CommuniGate Pro SMTP 4.3.8) with ESMTPS id 2004255; Thu, 13 Oct 2005 01:17:03 +0400 Message-ID: <002c01c5cf72$54901fc0$0701010a@notebook> From: "Yuriy N. Shkandybin" To: "John Baldwin" References: <092e01c5cb15$f7fe5840$6504010a@Jura> <200510121610.47507.jhb@freebsd.org> Date: Thu, 13 Oct 2005 01:13:13 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-6"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Cc: freebsd-net@freebsd.org Subject: Re: if_nge & if_lge drivers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 21:17:10 -0000 > > Note that lge() has a bzero() call after the contigmalloc(), but M_ZERO is > probably better to use: > > sc->lge_ldata = contigmalloc(sizeof(struct lge_list_data), M_DEVBUF, > M_NOWAIT, 0, 0xffffffff, PAGE_SIZE, 0); > > ... > bzero(sc->lge_ldata, sizeof(struct lge_list_data)); > Yes, i;ve missed that. But there is no such bzero in nge. > I'll put that in my lge(4) patches and incorporate your nge(4) patches. > One > issue with your nge(4) patch is that you moved the bus_setup_intr() up > when > it really should happen after ether_ifattach(). > Probably. I've looked into if_lge.c for that as example. There goes bus_setup_intr() first and later ether_ifattach(). > > Also, is there a reason you added a call to nge_reset() after nge_stop() > in > nge_init()? > Only reason - same done in if_lge.c Jura From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 21:17:20 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BEA116A41F; Wed, 12 Oct 2005 21:17:20 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3FAB43D45; Wed, 12 Oct 2005 21:17:19 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id j9CLHHn1020537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Oct 2005 17:17:18 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id j9CLHCqn007199; Wed, 12 Oct 2005 17:17:12 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17229.32088.696346.868182@grasshopper.cs.duke.edu> Date: Wed, 12 Oct 2005 17:17:12 -0400 (EDT) To: Robert Watson In-Reply-To: <20051012212915.E66014@fledge.watson.org> References: <20051008143854.B84936@fledge.watson.org> <17229.29164.891534.200216@grasshopper.cs.duke.edu> <20051012212915.E66014@fledge.watson.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: net@FreeBSD.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 21:17:20 -0000 Robert Watson writes: > > On Wed, 12 Oct 2005, Andrew Gallatin wrote: > > > Speaking of net.isr, is there any reason why if_simloop() calls > > netisr_queue() rather than netisr_dispatch()? > > Yes -- it's basically to prevent recursion for loopback traffic, which can > result in both lock orders and general concerns regarding reentrance. To > be specific: if you send a packet on a loopback TCP socket, it gets > processes asynchronously in the netisr rather than immediately walking > back into the TCP code again. Right now WITNESS would warn about this, > but there were also quite bad things that could happen before we did the > locking work -- for example, when connections are torn down. It also > avoids Really Deep Stacks. Right now, at least, it seems to work OK. I haven't tried witness, but a non-debug kernel shows a big speedup from enabling it. Do you think there is a chance that it could be made to work in FreeBSD? For what its worth, our TCP RR loopback latency on a dual-core AMD64 3800+ is roughly 2x as much as the solaris and linux latency. Heck, we're even slower than Darwin. And I didn't think it was *possible* to be slower than Darwin: --------------------------------------------------------------------- Host OS 2p/0K Pipe AF UDP RPC/ TCP RPC/ TCP ctxsw UNIX UDP TCP conn --------- ------------- ----- ----- ---- ----- ----- ----- ----- ---- rome FreeBSD 7.0-C 7.220 15.7 18.1 36.1 rome.sw.m Darwin 8.2.0 1.250 6.531 19.9 33.7 48.4 33.0 48.0 63. rome SunOS 5.11 5.140 12.8 15.4 22.0 17.0 43.1 141. rome Linux 2.6.9-1 3.760 9.780 11.7 17.0 20.5 18.9 23.2 32. Using net.isr.direct over the loopback brings the latency down to 25us. vmstat 1 with direct disabled: procs memory page disk faults cpu r b w avm fre flt re pi po fr sr ad0 in sy cs us sy id 2 0 0 33216 457016 0 0 0 0 0 0 4 53593 107075 214030 5 68 27 2 0 0 33216 457016 0 0 0 0 0 0 0 53694 107279 214356 5 72 24 <...> And with it enabled: 2 0 0 33796 456620 0 0 0 0 0 0 0 106 153987 150570 2 59 39 2 0 0 33796 456620 0 0 0 0 0 0 0 107 154100 150945 3 61 36 Drew From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 08:54:52 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26A8416A41F for ; Thu, 13 Oct 2005 08:54:52 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9ABD43D48 for ; Thu, 13 Oct 2005 08:54:51 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id D21B1CE for ; Thu, 13 Oct 2005 04:32:45 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id AE77D55F1 for ; Thu, 13 Oct 2005 04:32:45 -0400 (EDT) Received: from lists by mappit.local.linnet.org with local (Exim 4.54 (FreeBSD)) id 1EPyrN-0002pZ-AB for freebsd-net@freebsd.org; Thu, 13 Oct 2005 09:54:45 +0100 Date: Thu, 13 Oct 2005 09:54:45 +0100 From: Brian Candler To: freebsd-net@freebsd.org Message-ID: <20051013085445.GA10797@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: 255.255.255.255 broadcast changed from 4.x to 5.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2005 08:54:52 -0000 I've noticed a change in behaviour between FreeBSD 4.9 and FreeBSD 5.4 When sending an undirected broadcast to 255.255.255.255, FreeBSD 4.9 encapsulates this with the broadcast MAC address (ff:ff:ff:ff:ff:ff) as the destination. However, FreeBSD 5.4 encapsulates the packet using the MAC address of the default router, and therefore nobody else on the network sees it. Where this broke me was using wakeonlan. This utility sends a magic packet to 255.255.255.255 by default, and worked under FreeBSD 4.9 but not 5.4. After debugging with tcpdump -e, I found the issue with the MAC address. Configuring the program to send to the network's broadcast address instead of 255.255.255.255 fixed the problem; the packet was addressed to ff:ff:ff:ff:ff:ff, and the other computer woke up. Now I know about this, I can demonstrate it using 'ping 255.255.255.255' just as easily. My question is: is this an intentional change? Is it documented? # egrep -i '(broadcast|255)' /usr/src/UPDATING # Thanks, Brian. From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 17:20:54 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17D3316A41F for ; Thu, 13 Oct 2005 17:20:54 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: from ns2.alphaque.com (ns2.alphaque.com [202.75.47.153]) by mx1.FreeBSD.org (Postfix) with SMTP id B740A43D4C for ; Thu, 13 Oct 2005 17:20:52 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: (qmail 76610 invoked by uid 0); 13 Oct 2005 17:20:51 -0000 Received: from lucifer.net-gw.com (HELO prophet.alphaque.com) (202.75.47.153) by lucifer.net-gw.com with SMTP; 13 Oct 2005 17:20:51 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by prophet.alphaque.com (8.13.3/8.13.3) with ESMTP id j9DHKf0c053666; Fri, 14 Oct 2005 01:20:41 +0800 (MYT) (envelope-from dinesh@alphaque.com) Message-ID: <434E9769.6010603@alphaque.com> Date: Fri, 14 Oct 2005 01:20:41 +0800 From: Dinesh Nair User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050326 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org, freebsd-hardware@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Broadcom NetXtreme BCM5751M Gigabit Ethernet PCI Express and FreeBSD 4.10 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2005 17:20:54 -0000 has anyone got the above gigabit ethernet working with freebsd 4.10 ? patching sys/dev/bge/if_bge.c and sys/dev/bge/if_bgereg.h with the device and vendor IDs in the proper places doesnt seem to work, though the entries exist in the same files in the 4.11 sources. a mailing list search shows it working fine on the ibm t43 notebooks but on freebsd 5.4 instead. however, as mentioned above, RELENG_4 sources contain the device id for the BCM5751M, so i'd assume it'd work there too. there seems to be no special handling of this device in the code, so getting it to work on 4.10 (as opposed to 4.11R) would be as simple as adding in the same device ids. or so i thought. pciconf -l -v yields none4@pci16:0:0: class=0x020000 card=0x0944103c chip=0x167d14e4 rev=0x11 hdr=0x0 vendor = 'Broadcom Corporation' class = network subclass = ethernet and a kldload if_bge returns (after patching in device id): bge0: mem 0xc8000000-0xc800ffff irq 10 at device 0.0 on pci16 bge0: firmware handshake timed out bge0: RX CPU self-diagnostics failed! bge0: chip initialization failed device_probe_and_attach: bge0 returned 6 the notebook is a HP nc6230. -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.alphaque.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 17:45:03 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6687416A424 for ; Thu, 13 Oct 2005 17:45:03 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3C1E43D45 for ; Thu, 13 Oct 2005 17:45:02 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Thu, 13 Oct 2005 14:01:22 -0400 From: John Baldwin To: "Yuriy N. Shkandybin" Date: Thu, 13 Oct 2005 13:20:51 -0400 User-Agent: KMail/1.8.2 References: <092e01c5cb15$f7fe5840$6504010a@Jura> <200510121610.47507.jhb@freebsd.org> <002c01c5cf72$54901fc0$0701010a@notebook> In-Reply-To: <002c01c5cf72$54901fc0$0701010a@notebook> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510131320.52797.jhb@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: if_nge & if_lge drivers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2005 17:45:03 -0000 On Wednesday 12 October 2005 05:13 pm, Yuriy N. Shkandybin wrote: > > Note that lge() has a bzero() call after the contigmalloc(), but M_ZERO > > is probably better to use: > > > > sc->lge_ldata = contigmalloc(sizeof(struct lge_list_data), M_DEVBUF, > > M_NOWAIT, 0, 0xffffffff, PAGE_SIZE, 0); > > > > ... > > bzero(sc->lge_ldata, sizeof(struct lge_list_data)); > > Yes, i;ve missed that. > But there is no such bzero in nge. Right. > > I'll put that in my lge(4) patches and incorporate your nge(4) patches. > > One > > issue with your nge(4) patch is that you moved the bus_setup_intr() up > > when > > it really should happen after ether_ifattach(). > > Probably. > I've looked into if_lge.c for that as example. > There goes bus_setup_intr() first and later ether_ifattach(). My locking patches for lge(4) move it. :) Once a driver is properly locked it should call ether_ifattach() first, and nge is mostly properly locked. > > Also, is there a reason you added a call to nge_reset() after nge_stop() > > in > > nge_init()? > > Only reason - same done in if_lge.c Ah, hmm. Do you have nge(4) hardware such that you can test my slightly larger nge patch? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 19:56:34 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05F8316A41F for ; Thu, 13 Oct 2005 19:56:34 +0000 (GMT) (envelope-from gregorynou@altern.org) Received: from gtl.georgiatech-metz.fr (gtl.georgiatech-metz.fr [192.93.8.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5328943D46 for ; Thu, 13 Oct 2005 19:56:32 +0000 (GMT) (envelope-from gregorynou@altern.org) Received: from vignes.georgiatech-metz.fr (vignes.georgiatech-metz.fr [192.93.8.34]) by gtl.georgiatech-metz.fr (8.11.7p1+Sun/8.9.0) with SMTP id j9DJuPU04739 for ; Thu, 13 Oct 2005 21:56:31 +0200 (MEST) X-Authentication-Warning: gtl.georgiatech-metz.fr: vignes.georgiatech-metz.fr [192.93.8.34] didn't use HELO protocol Message-ID: <434EBC0B.90409@altern.org> Date: Thu, 13 Oct 2005 21:56:59 +0200 From: Gregory Nou User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051009) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ping vs ping6 on localhost X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2005 19:56:34 -0000 Hi, I was making some small tests on ipv6 (before bigger ones, of course :)), and got some astonishing results: when doing a ping6 -c 20 ::1 => --- ::1 ping6 statistics --- 20 packets transmitted, 20 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.100/0.265/1.655/0.367 ms I think the max and std-dev are not that relevant, because usually, the results were approx. 0.130 ms. when doing a ping -c 20 127.0.0.1 => --- 127.0.0.1 ping statistics --- 20 packets transmitted, 20 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.050/0.070/0.089/0.008 ms I made the test at the same time (well, not really at the same time, but with only a few seconds of delay), and at different moment, with a load of 0.45 (which is not that much) I did not go further, because I'm quite new in the pratical use of ipv6, but this looks astonishing to me. Is this due to the IPv6 implementation, to ping6, or to my computer ? I'm sorry if this has already been discussed, I had not brave enough to look in all the archives of the mailing list. -- Gregory From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 22:24:57 2005 Return-Path: X-Original-To: net@FreeBSD.ORG Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BABC316A420 for ; Thu, 13 Oct 2005 22:24:57 +0000 (GMT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E2E543D48 for ; Thu, 13 Oct 2005 22:24:57 +0000 (GMT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (localhost.csail.mit.edu [127.0.0.1]) by khavrinen.csail.mit.edu (8.13.1/8.13.4) with ESMTP id j9DMOY60016646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.csail.mit.edu issuer=Client+20CA); Thu, 13 Oct 2005 18:24:35 -0400 (EDT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.13.1/8.13.4/Submit) id j9DMOYUw016643; Thu, 13 Oct 2005 18:24:34 -0400 (EDT) (envelope-from wollman) From: Garrett Wollman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17230.56994.552228.385003@khavrinen.csail.mit.edu> Date: Thu, 13 Oct 2005 18:24:34 -0400 To: Andrew Gallatin In-Reply-To: <17229.32088.696346.868182@grasshopper.cs.duke.edu> References: <20051008143854.B84936@fledge.watson.org> <17229.29164.891534.200216@grasshopper.cs.duke.edu> <20051012212915.E66014@fledge.watson.org> <17229.32088.696346.868182@grasshopper.cs.duke.edu> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-1.6 (khavrinen.csail.mit.edu [127.0.0.1]); Thu, 13 Oct 2005 18:24:35 -0400 (EDT) X-Spam-Status: No, score=0.0 required=5.0 tests=none version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on khavrinen.csail.mit.edu Cc: net@FreeBSD.ORG Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2005 22:24:57 -0000 < said: > Right now, at least, it seems to work OK. I haven't tried witness, > but a non-debug kernel shows a big speedup from enabling it. Do > you think there is a chance that it could be made to work in FreeBSD? I did this ten years ago for a previous job and was able to blow out the stack very easily. -GAWollman From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 23:55:03 2005 Return-Path: X-Original-To: net@FreeBSD.ORG Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05D9F16A41F for ; Thu, 13 Oct 2005 23:55:02 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D60C43D55 for ; Thu, 13 Oct 2005 23:55:02 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id j9DNt1PO002359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Oct 2005 19:55:01 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id j9DNsuqK009364; Thu, 13 Oct 2005 19:54:56 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17230.62415.991707.840932@grasshopper.cs.duke.edu> Date: Thu, 13 Oct 2005 19:54:55 -0400 (EDT) To: Garrett Wollman In-Reply-To: <17230.56994.552228.385003@khavrinen.csail.mit.edu> References: <20051008143854.B84936@fledge.watson.org> <17229.29164.891534.200216@grasshopper.cs.duke.edu> <20051012212915.E66014@fledge.watson.org> <17229.32088.696346.868182@grasshopper.cs.duke.edu> <17230.56994.552228.385003@khavrinen.csail.mit.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: net@FreeBSD.ORG Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2005 23:55:03 -0000 Garrett Wollman writes: > < said: > > > Right now, at least, it seems to work OK. I haven't tried witness, > > but a non-debug kernel shows a big speedup from enabling it. Do > > you think there is a chance that it could be made to work in FreeBSD? > > I did this ten years ago for a previous job and was able to blow out > the stack very easily. I haven't blown it out yet, but for that and other reasons, it seems to be a bigger can of worms than it would be worth. The interesting thing is that using the TSC timecounter rather than ACPI-fast reduces the context switch latency enough so as to make the TCP latency 25us when using a netisr thread. 25us is identical to what I saw with the direct dispatch loopback hack. Linux already takes care of syncing the TSC between SMP cpus, so we know it is possible. This seems like a much more doable optimization. And it is likely to have other benefits.. Drew From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 08:25:10 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0727116A41F; Fri, 14 Oct 2005 08:25:10 +0000 (GMT) (envelope-from Nicolas.Kowalski@imag.fr) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60C5343D46; Fri, 14 Oct 2005 08:25:08 +0000 (GMT) (envelope-from Nicolas.Kowalski@imag.fr) Received: from mail-veri.imag.fr (mail-veri.imag.fr [129.88.43.52]) by imag.imag.fr (8.13.0/8.13.0) with ESMTP id j9E8OwmQ008634 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 14 Oct 2005 10:24:58 +0200 (CEST) Received: from corbeau.imag.fr ([129.88.43.162]) by mail-veri.imag.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1EQKs6-0002o8-2o; Fri, 14 Oct 2005 10:24:58 +0200 Date: Fri, 14 Oct 2005 10:24:58 +0200 From: Nicolas KOWALSKI To: freebsd-fs@freebsd.org, freebsd-net@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (imag.imag.fr [129.88.30.1]); Fri, 14 Oct 2005 10:24:58 +0200 (CEST) X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information Cc: Subject: FreeBSD NFS server not responding to TCP SYN packets from Linux/SunOS clients X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 08:25:10 -0000 Hello, This is a repost of a question I sent to freebsd-questions 10 days ago. I "crosspost" it to freebsd-fs and freebsd-net, because the question is about both... Our FreeBSD 4.10 NFS server has some problems serving files by NFS on TCP (no problem with UDP) when the Linux (2.6) or Solaris (5.9) clients shut down in an unclean manner (power failure). When the clients try to mount the shares from the server after an unclean shutdown, the mount process hang during several minutes (delay is varying), then succeeds. I used ethereal on a Linux client, just after an unclean shutdown, and it looks like the client is sending SYN packets to the 2049 port of the server, but the server does not respond to this ; the client retries a few seconds later, and the server still does not acknoledge it ; and it continues several times, until succeeding. Here is a trace ; the frames showing the problem are 33-36, when the client request a SYN to the 2049 port. No. Time Source Destination Protocol Info 16 0.001774 MOUNT V3 MNT Call (Reply In 17) 17 0.001983 MOUNT V3 MNT Reply (Call In 16) 18 0.002013 TCP 909 > 805 [ACK] Seq=105 Ack=73 Win=5840 Len=0 TSV=4294748848 TSER=1226883802 19 0.002233 TCP 911 > sunrpc [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=4294748848 TSER=0 WS=2 20 0.002418 TCP sunrpc > 911 [SYN, ACK] Seq=0 Ack=1 Win=57344 Len=0 MSS=1460 WS=0 TSV=1226883802 TSER=4294748848 21 0.002447 TCP 911 > sunrpc [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSV=4294748848 TSER=1226883802 22 0.002579 Portmap V2 GETPORT Call (Reply In 23) 23 0.002782 Portmap V2 GETPORT Reply (Call In 22) 24 0.002807 TCP 911 > sunrpc [ACK] Seq=61 Ack=33 Win=5840 Len=0 TSV=4294748849 TSER=1226883802 25 0.002941 TCP 911 > sunrpc [FIN, ACK] Seq=61 Ack=33 Win=5840 Len=0 TSV=4294748849 TSER=1226883802 26 0.003042 TCP sunrpc > 911 [ACK] Seq=33 Ack=62 Win=57920 Len=0 TSV=1226883803 TSER=4294748849 27 0.003057 TCP sunrpc > 911 [FIN, ACK] Seq=33 Ack=62 Win=57920 Len=0 TSV=1226883803 TSER=4294748849 28 0.003105 TCP 911 > sunrpc [ACK] Seq=62 Ack=34 Win=5840 Len=0 TSV=4294748849 TSER=1226883803 29 0.003264 TCP 909 > 805 [FIN, ACK] Seq=105 Ack=73 Win=5840 Len=0 TSV=4294748849 TSER=1226883802 30 0.003417 TCP 805 > 909 [ACK] Seq=73 Ack=106 Win=57920 Len=0 TSV=1226883803 TSER=4294748849 31 0.003433 TCP 805 > 909 [FIN, ACK] Seq=73 Ack=106 Win=57920 Len=0 TSV=1226883803 TSER=4294748849 32 0.003480 TCP 909 > 805 [ACK] Seq=106 Ack=74 Win=5840 Len=0 TSV=4294748849 TSER=1226883803 33 0.003881 TCP 798 > 2049 [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=4294748850 TSER=0 WS=2 34 3.004094 TCP 798 > 2049 [SYN] Seq=0 Ack=0 Win=23360 Len=0 MSS=1460 TSV=4294751850 TSER=0 WS=2 35 9.003506 TCP 798 > 2049 [SYN] Seq=0 Ack=0 Win=23360 Len=0 MSS=1460 TSV=4294757850 TSER=0 WS=2 36 21.001319 TCP 798 > 2049 [SYN] Seq=0 Ack=0 Win=23360 Len=0 MSS=1460 TSV=4294769850 TSER=0 WS=2 Is there something I can set on the server (sysctl variable perhaps), to make it accept the SYN packets from the clients ? As an counter-example, here is a trace when the same Linux client, after an unclean shutdown, tries to mount a previously (before the powerfailure) NFS mounted share from a SunOS 5.9 server. The SYN packet is acknowledged by the server (frames 36-37), so the client does not hang mounting the share. No. Time Source Destination Protocol Info 17 0.002257 MOUNT V3 MNT Call (Reply In 19) 18 0.002391 TCP 32785 > 911 [ACK] Seq=1 Ack=93 Win=49140 Len=0 TSV=613133117 TSER=4294753259 19 0.006256 MOUNT V3 MNT Reply (Call In 17) 20 0.006280 TCP 911 > 32785 [ACK] Seq=93 Ack=77 Win=5840 Len=0 TSV=4294753263 TSER=613133117 21 0.006514 TCP 913 > sunrpc [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=4294753264 TSER=0 WS=2 22 0.006670 TCP sunrpc > 913 [SYN, ACK] Seq=0 Ack=1 Win=49232 Len=0 TSV=613133117 TSER=4294753264 MSS=1460 WS=0 23 0.006700 TCP 913 > sunrpc [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSV=4294753264 TSER=613133117 24 0.006838 Portmap V2 GETPORT Call (Reply In 26) 25 0.007020 TCP sunrpc > 913 [ACK] Seq=1 Ack=61 Win=49172 Len=0 TSV=613133117 TSER=4294753264 26 0.007452 Portmap V2 GETPORT Reply (Call In 24) 27 0.007475 TCP 913 > sunrpc [ACK] Seq=61 Ack=33 Win=5840 Len=0 TSV=4294753265 TSER=613133117 28 0.007598 TCP 913 > sunrpc [FIN, ACK] Seq=61 Ack=33 Win=5840 Len=0 TSV=4294753265 TSER=613133117 29 0.007712 TCP 911 > 32785 [FIN, ACK] Seq=93 Ack=77 Win=5840 Len=0 TSV=4294753265 TSER=613133117 30 0.007766 TCP sunrpc > 913 [ACK] Seq=33 Ack=62 Win=49232 Len=0 TSV=613133118 TSER=4294753265 31 0.007816 TCP sunrpc > 913 [FIN, ACK] Seq=33 Ack=62 Win=49232 Len=0 TSV=613133118 TSER=4294753265 32 0.007839 TCP 913 > sunrpc [ACK] Seq=62 Ack=34 Win=5840 Len=0 TSV=4294753265 TSER=613133118 33 0.007893 TCP 32785 > 911 [ACK] Seq=77 Ack=94 Win=49232 Len=0 TSV=613133118 TSER=4294753265 34 0.008012 TCP 32785 > 911 [FIN, ACK] Seq=77 Ack=94 Win=49232 Len=0 TSV=613133118 TSER=4294753265 35 0.008145 TCP 911 > 32785 [ACK] Seq=94 Ack=78 Win=5840 Len=0 TSV=4294753265 TSER=613133118 36 0.008553 TCP 799 > 2049 [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=4294753266 TSER=0 WS=2 37 0.008790 TCP 2049 > 799 [SYN, ACK] Seq=0 Ack=1 Win=49232 Len=0 TSV=613133118 TSER=4294753266 MSS=1460 WS=0 38 0.008836 TCP 799 > 2049 [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSV=4294753266 TSER=613133118 Thanks, -- Nicolas From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 08:46:56 2005 Return-Path: X-Original-To: net@FreeBSD.ORG Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F61C16A41F for ; Fri, 14 Oct 2005 08:46:56 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 158EC43D45 for ; Fri, 14 Oct 2005 08:46:55 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 111C9BC66; Fri, 14 Oct 2005 08:46:53 +0000 (UTC) To: Andrew Gallatin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 13 Oct 2005 19:54:55 EDT." <17230.62415.991707.840932@grasshopper.cs.duke.edu> Date: Fri, 14 Oct 2005 10:46:53 +0200 Message-ID: <12349.1129279613@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Garrett Wollman , net@FreeBSD.ORG Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 08:46:56 -0000 In message <17230.62415.991707.840932@grasshopper.cs.duke.edu>, Andrew Gallatin writes: >Linux already takes care of syncing the TSC between SMP cpus, so we >know it is possible. This seems like a much more doable optimization. >And it is likely to have other benefits.. Validating that the TSC is reliable is a nontrivial task which requires access to a lot of NDA information and an extensive positive/negative list of chips and chipsets. Even in the most recent chips, there are still issues with TSC that makes it unusable as a default timecounter. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 09:01:34 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D29B716A41F for ; Fri, 14 Oct 2005 09:01:34 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DAC643D45 for ; Fri, 14 Oct 2005 09:01:33 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from cs.ait.ac.th (ufo.cs.ait.ac.th [192.41.170.14]) by mail.cs.ait.ac.th (8.12.11/8.12.11) with ESMTP id j9E91SUb049527 for ; Fri, 14 Oct 2005 16:01:28 +0700 (ICT) Received: from proxy8.psu.ac.th (proxy8.psu.ac.th [202.12.74.8]) by wwws.cs.ait.ac.th (Horde MIME library) with HTTP for ; Fri, 14 Oct 2005 16:01:28 +0700 Message-ID: <20051014160128.hev160v52ossokg0@wwws.cs.ait.ac.th> Date: Fri, 14 Oct 2005 16:01:28 +0700 From: on@cs.ait.ac.th To: freebsd-net@freebsd.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) / FreeBSD-5.3 X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) Subject: Re: FreeBSD NFS server not responding to TCP SYN packets from Linux/SunOS clients X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 09:01:35 -0000 Nicolas KOWALSKI wrote: > Our FreeBSD 4.10 NFS server has some problems serving files by NFS on > TCP (no problem with UDP) when the Linux (2.6) or Solaris (5.9) > clients shut down in an unclean manner (power failure). When the > clients try to mount the shares from the server after an > unclean shutdown, the mount process hang during several minutes (delay > is varying), then succeeds. That is just a wild guess, but NFS mounting would happen always at the same stage of the boot, so maybe with the same source port number and you could be facing the problem that the connection is waiting for termination on the server (close_wait or fin_wait or something)... Se source port in working example is 798 and source port in failing example is 799 certainly not random. Olivier From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 09:42:02 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 924A516A41F for ; Fri, 14 Oct 2005 09:42:02 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFC1E43D4C for ; Fri, 14 Oct 2005 09:42:01 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9E9frv8009558; Fri, 14 Oct 2005 19:41:53 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9E9fkDT020104; Fri, 14 Oct 2005 19:41:52 +1000 Date: Fri, 14 Oct 2005 19:41:48 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Poul-Henning Kamp In-Reply-To: <12349.1129279613@critter.freebsd.dk> Message-ID: <20051014192509.F80520@delplex.bde.org> References: <12349.1129279613@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Garrett Wollman , Andrew Gallatin , net@FreeBSD.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 09:42:02 -0000 On Fri, 14 Oct 2005, Poul-Henning Kamp wrote: > In message <17230.62415.991707.840932@grasshopper.cs.duke.edu>, Andrew Gallatin > writes: > >> Linux already takes care of syncing the TSC between SMP cpus, so we >> know it is possible. This seems like a much more doable optimization. >> And it is likely to have other benefits.. The timestamps in mi_switch() are taken on the same CPU and only their differences are used, so they don't even need to be synced. It they use the TSC, then the TSCs just need to have the same almost-constant frequency (or different almost-constant frequencies if timecounters werre per-CPU). > Validating that the TSC is reliable is a nontrivial task which requires > access to a lot of NDA information and an extensive positive/negative > list of chips and chipsets. It only requires comparsion with another time source over a sufficently long enough time and large enough set of operating environments. This is hard to automate. I compare with a local ntp server with a known good TSC. > Even in the most recent chips, there are still issues with TSC that > makes it unusable as a default timecounter. I think newer chipsets are more liketly to have unusable TSCs. Anything with power control is unleky to have an almost-constant frequency. Bruce From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 10:04:34 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF06A16A420 for ; Fri, 14 Oct 2005 10:04:34 +0000 (GMT) (envelope-from silby@silby.com) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id AD11243D5C for ; Fri, 14 Oct 2005 10:04:33 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 12889 invoked from network); 14 Oct 2005 10:04:31 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 14 Oct 2005 10:04:31 -0000 X-pair-Authenticated: 209.68.2.70 Date: Fri, 14 Oct 2005 05:04:29 -0500 (CDT) From: Mike Silbersack To: on@cs.ait.ac.th In-Reply-To: <20051014160128.hev160v52ossokg0@wwws.cs.ait.ac.th> Message-ID: <20051014045824.V5343@odysseus.silby.com> References: <20051014160128.hev160v52ossokg0@wwws.cs.ait.ac.th> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD NFS server not responding to TCP SYN packets from Linux/SunOS clients X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 10:04:34 -0000 On Fri, 14 Oct 2005, on@cs.ait.ac.th wrote: > Nicolas KOWALSKI wrote: >> Our FreeBSD 4.10 NFS server has some problems serving files by NFS on >> TCP (no problem with UDP) when the Linux (2.6) or Solaris (5.9) >> clients shut down in an unclean manner (power failure). When the clients >> try to mount the shares from the server after an >> unclean shutdown, the mount process hang during several minutes (delay >> is varying), then succeeds. > > That is just a wild guess, but NFS mounting would happen always at the same > stage of the boot, so maybe with the same source port number and you could be > facing the problem that the connection is waiting for termination on the > server > (close_wait or fin_wait or something)... Se source port in working example is > 798 and source port in failing example is 799 certainly not random. > > Olivier The socket on the server would still be in the ESTABLISHED state, which is even worse than the close_wait or fin_wait states in this case. The SYN will be accepted if it's greater than the previous sequence number, so that's a 50% chance it'll work. Assuming that port reuse is the problem, there is no quick fix for this, just resetting connections when a SYN comes in would be a really big security problem. Actually, there may be a quick fix for this specific machine. If you set net.inet.tcp.keepidle to 1 minute (60*whatever kern.hz is), that'll cause keepalive packets to be sent every minute to an idle connection, rather than every 2 hours. That would kill the stuck connections much quicker. However, it's also possible that this could cause problems in normal operation if keepalive packets cause problems. So, give it a shot, but be careful. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 10:39:35 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0EF516A41F for ; Fri, 14 Oct 2005 10:39:35 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4273743D48 for ; Fri, 14 Oct 2005 10:39:35 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 41CDFBC66; Fri, 14 Oct 2005 10:39:31 +0000 (UTC) To: Bruce Evans From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 14 Oct 2005 19:41:48 +1000." <20051014192509.F80520@delplex.bde.org> Date: Fri, 14 Oct 2005 12:39:30 +0200 Message-ID: <12907.1129286370@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Garrett Wollman , Andrew Gallatin , net@FreeBSD.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 10:39:35 -0000 In message <20051014192509.F80520@delplex.bde.org>, Bruce Evans writes: >On Fri, 14 Oct 2005, Poul-Henning Kamp wrote: > >> In message <17230.62415.991707.840932@grasshopper.cs.duke.edu>, Andrew Gallatin >> writes: >> >>> Linux already takes care of syncing the TSC between SMP cpus, so we >>> know it is possible. This seems like a much more doable optimization. >>> And it is likely to have other benefits.. > >The timestamps in mi_switch() are taken on the same CPU and only their >differences are used, so they don't even need to be synced. It they >use the TSC, then the TSCs just need to have the same almost-constant >frequency (or different almost-constant frequencies if timecounters >werre per-CPU). Actually, I think we need to go back a step further. The task of the scheduler is to hand out a finite resource according to a set policy. The finite resource is "instructions executed by a CPU". It used to be that CPUs ran at constant clock rates, and therefore implementors made the simplifying assumption that instructions = a * time for some random but constant a and made their scheduling decisions based on time. Today CPUs do not run on constant rates but they have counters which count the number of instruction cycles. Therefore talking about computer effort in terms of "CPU second" is like selling rubber band by the inch. The scheduler has a side job of accounting for CPU usage and the API for accesing this info has unfortunately been specified in terms of time rather than instructions. The best compromise solution therefore is to change the scheduler to make decisions based on the TSC ticks (or equivalent on other archs) and at regular intervals figure out how fast the CPU ran in the last period and convert the TSC ticks accumulated to a time unit suitable for resource accounting. The bad solution is to try to do timekeeping based on hardware counters which are unsuitable for the purpose, the TSC being the primary suspect here, and we will not do that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 11:05:50 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CD6016A421 for ; Fri, 14 Oct 2005 11:05:50 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 821CD43D49 for ; Fri, 14 Oct 2005 11:05:49 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j9EB5lQj031524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Oct 2005 15:05:48 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j9EB5lNQ031523 for net@FreeBSD.org; Fri, 14 Oct 2005 15:05:47 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 14 Oct 2005 15:05:47 +0400 From: Gleb Smirnoff To: net@FreeBSD.org Message-ID: <20051014110547.GR14542@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.6i Cc: Subject: [glebius@FreeBSD.org: cvs commit: src/sys/dev/em if_em.c] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 11:05:50 -0000 Colleagues, since there were a lot of em(4) related discussions on list, I decided to forward this commit mail here. This change should fix a big problem in if_em(), that you may have experienced. If you experience long wedges in receive part, for about minute or more, than you should try this patch, test it and please report to list. The more reports we get, the faster the change will enter RELENG_6_0. Thanks in advance! ----- Forwarded message from Gleb Smirnoff ----- From: Gleb Smirnoff To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/dev/em if_em.c Date: Fri, 14 Oct 2005 11:00:16 +0000 (UTC) Delivered-To: glebius@freebsd.org Delivered-To: src-committers@FreeBSD.org Precedence: bulk glebius 2005-10-14 11:00:16 UTC FreeBSD src repository Modified files: sys/dev/em if_em.c Log: From the PR: The receive function em_process_receive_interrupts() unlocks the adapter while ether_input() processes the packet, and then locks it back. In the meantime, em_init() may be called, either from em_watchdog() from softclock interrupt or from the ifconfig(8) program. The em_init() resets the card, in particular it sets adapter->next_rx_desc_to_check to 0 and resets hardware RX Head and Tail descriptor pointers. The loop in em_process_receive_interrupts() does not expect these things to change, and a mess may result. This fixes long wedges of em(4) interfaces receive part under high load and IP fastforwarding enabled. PR: kern/87418 Submitted by: Dmitrij Tejblum Revision Changes Path 1.77 +14 -14 src/sys/dev/em/if_em.c ----- End forwarded message ----- -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 12:52:31 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 373D416A420 for ; Fri, 14 Oct 2005 12:52:31 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id A01BB43D5C for ; Fri, 14 Oct 2005 12:52:29 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id j9ECqRir025257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Oct 2005 08:52:27 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id j9ECqLGe013276; Fri, 14 Oct 2005 08:52:21 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17231.43525.446450.161986@grasshopper.cs.duke.edu> Date: Fri, 14 Oct 2005 08:52:21 -0400 (EDT) To: "Poul-Henning Kamp" In-Reply-To: <12907.1129286370@critter.freebsd.dk> References: <20051014192509.F80520@delplex.bde.org> <12907.1129286370@critter.freebsd.dk> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: Garrett Wollman , net@FreeBSD.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 12:52:31 -0000 Poul-Henning Kamp writes: > The best compromise solution therefore is to change the scheduler > to make decisions based on the TSC ticks (or equivalent on other > archs) and at regular intervals figure out how fast the CPU ran in > the last period and convert the TSC ticks accumulated to a time > unit suitable for resource accounting. > > > The bad solution is to try to do timekeeping based on hardware > counters which are unsuitable for the purpose, the TSC being > the primary suspect here, and we will not do that. I'll bet that nobody will want to touch the scheduler, so we'll continue be stuck with inflated context switch times on SMP because we use such an expensive time source. What if somebody were to port the linux TSC syncing code, and use it to decide whether or not set kern.timecounter.smp_tsc=1? Would you object to that? Drew From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 13:00:33 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C02B16A41F for ; Fri, 14 Oct 2005 13:00:33 +0000 (GMT) (envelope-from Nicolas.Kowalski@imag.fr) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id D546143D45 for ; Fri, 14 Oct 2005 13:00:32 +0000 (GMT) (envelope-from Nicolas.Kowalski@imag.fr) Received: from mail-veri.imag.fr (mail-veri.imag.fr [129.88.43.52]) by imag.imag.fr (8.13.0/8.13.0) with ESMTP id j9ED0UNV004610 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 14 Oct 2005 15:00:30 +0200 (CEST) Received: from obiou.imag.fr ([129.88.43.2]) by mail-veri.imag.fr with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1EQPAk-0008Rz-Ai for freebsd-net@FreeBSD.org; Fri, 14 Oct 2005 15:00:30 +0200 Received: from kowalski by obiou.imag.fr with local (Exim 4.50) id 1EQPAk-0001oW-5s for freebsd-net@FreeBSD.org; Fri, 14 Oct 2005 15:00:30 +0200 To: freebsd-net@FreeBSD.org References: <20051014160128.hev160v52ossokg0@wwws.cs.ait.ac.th> <20051014045824.V5343@odysseus.silby.com> From: Nicolas KOWALSKI Date: Fri, 14 Oct 2005 15:00:30 +0200 In-Reply-To: <20051014045824.V5343@odysseus.silby.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Nicolas Kowalski X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (imag.imag.fr [129.88.30.1]); Fri, 14 Oct 2005 15:00:30 +0200 (CEST) X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information Cc: Subject: Re: FreeBSD NFS server not responding to TCP SYN packets from Linux/SunOS clients X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 13:00:33 -0000 Mike Silbersack writes: > On Fri, 14 Oct 2005, on@cs.ait.ac.th wrote: > >> Nicolas KOWALSKI wrote: >>> Our FreeBSD 4.10 NFS server has some problems serving files by NFS >>> on TCP (no problem with UDP) when the Linux (2.6) or Solaris (5.9) >>> clients shut down in an unclean manner (power failure). When the >>> clients try to mount the shares from the server after an unclean >>> shutdown, the mount process hang during several minutes (delay is >>> varying), then succeeds. >> >> That is just a wild guess, but NFS mounting would happen always at >> the same stage of the boot, so maybe with the same source port >> number and you could be facing the problem that the connection is >> waiting for termination on the server (close_wait or fin_wait or >> something)... Se source port in working example is 798 and source >> port in failing example is 799 certainly not random. > > The socket on the server would still be in the ESTABLISHED state, > which is even worse than the close_wait or fin_wait states in this > case. The SYN will be accepted if it's greater than the previous > sequence number, so that's a 50% chance it'll work. Thanks for this explanation. > Assuming that port reuse is the problem, there is no quick fix for > this, just resetting connections when a SYN comes in would be a > really big security problem. Really? Are Linux and Solaris that insecure because of this behaviour? > Actually, there may be a quick fix for this specific machine. If you > set net.inet.tcp.keepidle to 1 minute (60*whatever kern.hz is), > that'll cause keepalive packets to be sent every minute to an idle > connection, rather than every 2 hours. That would kill the stuck > connections much quicker. Unfortunately, this does not work as expected. I just tested with my workstation (Linux 2.6), with NFS filesystems mounted with TCP; when the station rebooted abruptely, mounting the same NFS filesystems hung more than 1 minute (15 minutes just now). During this hang, I saw on the server, using netstat, the nfsd process related to my workstation in ESTABLISHED state. Any other tip? Many Thanks in advance, -- Nicolas From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 14:05:36 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 541D416A41F for ; Fri, 14 Oct 2005 14:05:36 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC74643D5E for ; Fri, 14 Oct 2005 14:05:35 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 06572BC66; Fri, 14 Oct 2005 14:05:31 +0000 (UTC) To: Andrew Gallatin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 14 Oct 2005 08:52:21 EDT." <17231.43525.446450.161986@grasshopper.cs.duke.edu> Date: Fri, 14 Oct 2005 16:05:31 +0200 Message-ID: <13600.1129298731@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Garrett Wollman , net@FreeBSD.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 14:05:36 -0000 In message <17231.43525.446450.161986@grasshopper.cs.duke.edu>, Andrew Gallatin writes: > >Poul-Henning Kamp writes: > > The best compromise solution therefore is to change the scheduler > > to make decisions based on the TSC ticks (or equivalent on other > > archs) and at regular intervals figure out how fast the CPU ran in > > the last period and convert the TSC ticks accumulated to a time > > unit suitable for resource accounting. > > > > > > The bad solution is to try to do timekeeping based on hardware > > counters which are unsuitable for the purpose, the TSC being > > the primary suspect here, and we will not do that. > >I'll bet that nobody will want to touch the scheduler, so we'll >continue be stuck with inflated context switch times on SMP because we >use such an expensive time source. > >What if somebody were to port the linux TSC syncing code, and use it >to decide whether or not set kern.timecounter.smp_tsc=1? Would you >object to that? Yes, I would object to that. Even to this day new CPU chips come out where TSC has flaws that prevent it from being used as timecounter, and we do not have (NDA) access to the data that would allow us to build a list of safe hardware. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 14:13:57 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E53E316A41F; Fri, 14 Oct 2005 14:13:57 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 945AB43D4C; Fri, 14 Oct 2005 14:13:57 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id 63F534C602; Fri, 14 Oct 2005 14:12:04 +0000 (GMT) Received: from [192.168.0.3] (ppp157-158.static.internode.on.net [150.101.157.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by p4.roq.com (Postfix) with ESMTP id EAC874C4DD; Fri, 14 Oct 2005 12:59:59 +0000 (GMT) Message-ID: <434FABCC.2060709@roq.com> Date: Fri, 14 Oct 2005 22:59:56 +1000 From: Michael VInce User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.11) Gecko/20050925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: stable@freebsd.org Subject: Network performance 6.0 with netperf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 14:13:58 -0000 Hey all, I been doing some network benchmarking using netperf and just simple 'fetch' on a new network setup to make sure I am getting the most out of the router and servers, I thought I would post some results in case some one can help me with my problems or if others are just interested to see the results. The network is currently like this, where machines A and B are the Dell 1850s and C is the 2850 x 2 CPU (Server C has Apache2 worker MPM on it) and server B is the gateway and A is acting as a client for fetch and netperf tests. A --- B --- C The 2 1850s are running AMD64 Freebsd 6.0rc1 (A and B) while C is running 5.4-stable i386 from Oct 12 My main problem is that if I compile SMP into the machine C (5.4stable) the network speed goes down to a range between 6mbytes/sec to 15mbytes/sec on SMP. If I use GENERIC kernel the performance goes up to what I have show below which is around 65megabytes/sec for a 'fetch' get test from Apache server and 933mbits/sec for netperf. Does any know why why network performance would be so bad on SMP? Does any one think that if I upgrade the i386 SMP server to 6.0RC1 the SMP network performance would improve? This server will be running java so I need it to be stable and is the the reason I am using i386 and Java 1.4 I am happy with performance of direct machine to machine (non SMP) which is pretty much full 1gigabit/sec speeds. Going through the gateway server-B seems to drop its speed down a bit for in and out direction tcp speed tests using netperf I get around 266mbits/sec from server A through gateway Server-B to server-C which is quite adequate for the link I currently have for it. Doing a 'fetch' get for a 1gig file from the Apache server gives good speeds of close to 600mbits/sec but netperf shows its weakness with 266mbits/sec. This is as fast as I need it to be but does any one know the weak points on the router gateway to make it faster? Is this the performance I should expect for FreeBSD as a router with gigabit ethers? I have seen 'net.inet.ip.fastforwarding' in some peoples router setups on the list but nothing about what it does or what it can affect. I haven't done any testing with polling yet but if I can get over 900mbits/sec on the interfaces does polling help with passing packets from one interface to the other? All machines have PF running other then that they don't really have any sysctls or special kernel options. Here are some speed benchmarks using netperf and 'fetch' gets. Server A to server C with server C using SMP kernel and just GENERIC kernel further below B# /usr/local/netperf/netperf -l 10 -H server-C -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 57344 -S 57344 TCP STREAM TEST to server-C : +/-2.5% @ 99% conf. : histogram Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 57344 57344 4096 10.06 155.99 tank# fetch -o - > /dev/null http://server-C/file1gig.iso - 100% of 1055 MB 13 MBps 00m00s ##### Using generic non SMP kernel Server A to server C with server C using GENERIC kernel. A# fetch -o - > /dev/null http://server-C/file1gig.iso - 100% of 1055 MB 59 MBps 00m00s A# ./tcp_stream_script server-C /usr/local/netperf/netperf -l 60 -H server-C -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 57344 -S 57344 Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 57344 57344 4096 60.43 266.92 ------------------------------------ ############################################### Connecting from server-A to B (gateway) A# ./tcp_stream_script server-B ------------------------------------ /usr/local/netperf/netperf -l 60 -H server-B -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 57344 -S 57344 TCP STREAM TEST to server-B : +/-2.5% @ 99% conf. : histogram Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 57344 57344 4096 61.80 926.82 ------------------------------------ ########################################## Connecting from server B (gateway) to server C Fetch and Apache2 test B# fetch -o - > /dev/null http://server-C/file1gig.iso - 100% of 1055 MB 74 MBps 00m00s Netperf test B# /usr/local/netperf/tcp_stream_script server-C /usr/local/netperf/netperf -l 60 -H server-C -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 57344 -S 57344 TCP STREAM TEST to server-C : +/-2.5% @ 99% conf. : histogram Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 57344 57344 4096 62.20 933.94 ------------------------------------ Cheers, Mike From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 14:54:43 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85CE816A41F for ; Fri, 14 Oct 2005 14:54:43 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1331243D5A for ; Fri, 14 Oct 2005 14:54:42 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id j9EEsNKX019416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Oct 2005 10:54:23 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id j9EEsHxM013388; Fri, 14 Oct 2005 10:54:17 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17231.50841.442047.622878@grasshopper.cs.duke.edu> Date: Fri, 14 Oct 2005 10:54:17 -0400 (EDT) To: "Poul-Henning Kamp" In-Reply-To: <13600.1129298731@critter.freebsd.dk> References: <17231.43525.446450.161986@grasshopper.cs.duke.edu> <13600.1129298731@critter.freebsd.dk> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: Garrett Wollman , net@FreeBSD.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 14:54:43 -0000 Poul-Henning Kamp writes: > In message <17231.43525.446450.161986@grasshopper.cs.duke.edu>, Andrew Gallatin > writes: > > > >Poul-Henning Kamp writes: > > > The best compromise solution therefore is to change the scheduler > > > to make decisions based on the TSC ticks (or equivalent on other > > > archs) and at regular intervals figure out how fast the CPU ran in > > > the last period and convert the TSC ticks accumulated to a time > > > unit suitable for resource accounting. > > > > > > > > > The bad solution is to try to do timekeeping based on hardware > > > counters which are unsuitable for the purpose, the TSC being > > > the primary suspect here, and we will not do that. > > > >I'll bet that nobody will want to touch the scheduler, so we'll > >continue be stuck with inflated context switch times on SMP because we > >use such an expensive time source. > > > >What if somebody were to port the linux TSC syncing code, and use it > >to decide whether or not set kern.timecounter.smp_tsc=1? Would you > >object to that? > > Yes, I would object to that. > > Even to this day new CPU chips come out where TSC has flaws that > prevent it from being used as timecounter, and we do not have (NDA) > access to the data that would allow us to build a list of safe > hardware. Bear in mind that I have no clue about timekeeping. I got into this just because I noticed using a TSC timecounter reduces context switch latency by 40% or more on all the SMP platforms I have access to: 1.0GHz dual PIII : 50% reduction vs i8254 3.06GHz 1 HTT P4 : 55% vs ACPI-safe, 70% vs i8254) 2.0GHz dual amd64: 43% vs ACPI-fast, 60% vs i8254) High context switch latency has been problem since FreeBSD 5 in networking due to the context switches for netisr use, and for the context switches required by interrupt threads. I'm sure it is a problem in other parts of the system. I think it is pretty important, and I'd really like to see it fixed. Since I don't know much about timekeeping, all I can do is raise awareness, and offer to port the linux solution (which I think I might be able to understand). However, if the linux solution is not correct, then somebody with timekeeping knowledge needs to get involved. Is this you? BTW, is an algorithm like Solaris' the "best compromise" you mention above? Or is it just keeping the TSC in sync? They seem to maintain a high resolution timer based on tsc, and keep it in sync every second, and fixup drift on different cpus, and the TSC being reset after suspend/resume. http://cvs.opensolaris.org/source/xref/usr/src/uts/i86pc/os/timestamp.c Drew From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 15:13:50 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4243616A496 for ; Fri, 14 Oct 2005 15:13:50 +0000 (GMT) (envelope-from toba@etek.chalmers.se) Received: from anubis.medic.chalmers.se (anubis.medic.chalmers.se [129.16.30.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id C789643D46 for ; Fri, 14 Oct 2005 15:13:49 +0000 (GMT) (envelope-from toba@etek.chalmers.se) X-Medic-Info: 346d.434fcb2b.0 GBriUqV3N34YErHl Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id BFA43E36C for ; Fri, 14 Oct 2005 17:13:47 +0200 (CEST) Received: from 192.138.116.163 (SquirrelMail authenticated user toba); by webmail.chalmers.se with HTTP; Fri, 14 Oct 2005 17:13:47 +0200 (CEST) Message-ID: <39087.192.138.116.163.1129302827.squirrel@webmail.chalmers.se> Date: Fri, 14 Oct 2005 17:13:47 +0200 (CEST) From: "Tobias Abrahamsson" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: using BPF and rawsocket X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 15:13:50 -0000 Hi I have a problem that i hope that someone can help me with. I'm trying to make a computer running a webserver, reachable on a net wich it don't own an address on. In order to let clients reach the server, I use BPF to capture the packets to an address that i have chosen, ( not important wich address, only that it's not on the right net), and then redirect them to my self to reach the webserver. To make the webserver respond to the client I set a static route back to the client ( there is no routers between the clients and the webserver so this works ). I'm using a raw socket to send the capured packets to webserver and there is were I have trouble. When I'm using sendto() it responds with error message: Invalid argument. I can't figure out why that is, but this is the first time I use rawsockets so maby it is easy to fix. Thankful for all ideas. Tobias Abrahamsson PS. the code have testig status so it is not so neat. #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include static void print_pkt( char *pkt_ptr ) { int i, print; char ch; struct ip *ip_hdr; ip_hdr = (struct ip *)pkt_ptr; for( i = 0; i < ntohs(ip_hdr->ip_len); i++ ) { ch = 0x00; ch = *(pkt_ptr + i); if( i%8 == 0 ) printf("\n"); print = (int)ch & 0x000000ff; if( (print & 0x000000f0) == 0 ) printf( "0%x:", print ); else printf( "%x:", print ); } printf( "\n" ); } static void send_pkt( int s, struct ip *ip_hdr ) { char *ptr; ssize_t ss; size_t len; struct sockaddr_in saddr; memset( &saddr, 0, sizeof(saddr) ); saddr.sin_family = AF_INET; saddr.sin_port = 80; inet_aton( "10.0.0.0", saddr.sin_addr ); len = ntohs(ip_hdr->ip_len); ptr = (char *)ip_hdr; if( (ss = sendto( s, ptr, len, 0, (const struct sockaddr *)&saddr, sizeof(saddr) )) < 0 ) perror( "sendto could not write" ); printf( "ip_len: %d sent: %d bytes\n", len, ss ); } int main() { int s, snaplen = 1600; char *device, errbuf[ PCAP_ERRBUF_SIZE ]; const int on = 1; const u_char *pkt_ptr; struct ip *ip_hdr; struct pcap_pkthdr pchdr; pcap_t *pd; if( (device = pcap_lookupdev( errbuf )) == NULL ) fprintf( stderr, errbuf ); pd = pcap_open_live( device, snaplen, 1, 1, errbuf); printf( "device %s\n", device ); if( (s = socket( AF_INET, SOCK_RAW, 0 )) < 0 ) perror( "socket" ); if( setsockopt( s, IPPROTO_IP, IP_HDRINCL, &on, sizeof(on) ) < 0 ) perror( "setsockopt" ); while( 1 ) { while( (pkt_ptr = (char *)pcap_next( pd, &pchdr )) == NULL ); ip_hdr = (struct ip *)(pkt_ptr + ETHER_HDR_LEN); if( ntohs(ip_hdr->ip_len) < 100 ) print_pkt( (char *)ip_hdr ); send_pkt( s, ip_hdr ); } } From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 15:44:38 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7450E16A41F for ; Fri, 14 Oct 2005 15:44:38 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1305143D46 for ; Fri, 14 Oct 2005 15:44:37 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 4ECC4BC84; Fri, 14 Oct 2005 15:44:34 +0000 (UTC) To: Andrew Gallatin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 14 Oct 2005 10:54:17 EDT." <17231.50841.442047.622878@grasshopper.cs.duke.edu> Date: Fri, 14 Oct 2005 17:44:33 +0200 Message-ID: <31823.1129304673@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Garrett Wollman , net@FreeBSD.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 15:44:38 -0000 In message <17231.50841.442047.622878@grasshopper.cs.duke.edu>, Andrew Gallatin writes: > > >What if somebody were to port the linux TSC syncing code, and use it > > >to decide whether or not set kern.timecounter.smp_tsc=1? Would you > > >object to that? > > > > Yes, I would object to that. > > > > Even to this day new CPU chips come out where TSC has flaws that > > prevent it from being used as timecounter, and we do not have (NDA) > > access to the data that would allow us to build a list of safe > > hardware. > >Bear in mind that I have no clue about timekeeping. I got into this >just because I noticed using a TSC timecounter reduces context switch >latency by 40% or more on all the SMP platforms I have access to: > >1.0GHz dual PIII : 50% reduction vs i8254 >3.06GHz 1 HTT P4 : 55% vs ACPI-safe, 70% vs i8254) >2.0GHz dual amd64: 43% vs ACPI-fast, 60% vs i8254) The solution is not faster but less reliable timekeeping, the solution is to move the scheduler(s) away from using time as an approximation of cpu cycles. >However, if the linux solution is not >correct, then somebody with timekeeping knowledge needs to get >involved. Is this you? The linux "solution" is not correct, and timekeeping knowledge I have, but the solution is in the scheduler where my clue is limited. >BTW, is an algorithm like Solaris' the "best compromise" you mention >above? Or is it just keeping the TSC in sync? They seem to maintain >a high resolution timer based on tsc, and keep it in sync every >second, and fixup drift on different cpus, and the TSC >being reset after suspend/resume. >http://cvs.opensolaris.org/source/xref/usr/src/uts/i86pc/os/timestamp.c Solaris don't change the tsc frequency by a factor 8 without giving the OS a chance to know about it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 17:47:20 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1491916A41F for ; Fri, 14 Oct 2005 17:47:20 +0000 (GMT) (envelope-from mreimer@vpop.net) Received: from ring.vpop.net (ring.vpop.net [207.178.248.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB0C843D4C for ; Fri, 14 Oct 2005 17:47:19 +0000 (GMT) (envelope-from mreimer@vpop.net) Received: from bilbo.vpop.net (bilbo.vpop.net [70.56.77.194]) by ring.vpop.net (Postfix) with ESMTP id 2648EAFAA78 for ; Fri, 14 Oct 2005 10:47:14 -0700 (PDT) From: Matthew Reimer Organization: VPOP Technologies, Inc. To: net@freebsd.org Date: Fri, 14 Oct 2005 10:46:11 -0700 User-Agent: KMail/1.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510141046.11620.mreimer@vpop.net> Cc: Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 17:47:20 -0000 Poul-Henning Kamp wrote: > In message <17231.50841.442047.622878@grasshopper.cs.duke.edu>, Andrew > Gallatin > writes: > >> > >What if somebody were to port the linux TSC syncing code, and use it >> > >to decide whether or not set kern.timecounter.smp_tsc=1? Would you >> > >object to that? >> > >> > Yes, I would object to that. >> > >> > Even to this day new CPU chips come out where TSC has flaws that >> > prevent it from being used as timecounter, and we do not have (NDA) >> > access to the data that would allow us to build a list of safe >> > hardware. >> >>Bear in mind that I have no clue about timekeeping. I got into this >>just because I noticed using a TSC timecounter reduces context switch >>latency by 40% or more on all the SMP platforms I have access to: >> >>1.0GHz dual PIII : 50% reduction vs i8254 >>3.06GHz 1 HTT P4 : 55% vs ACPI-safe, 70% vs i8254) >>2.0GHz dual amd64: 43% vs ACPI-fast, 60% vs i8254) > > The solution is not faster but less reliable timekeeping, the > solution is to move the scheduler(s) away from using time as an > approximation of cpu cycles. Would the hardware performance counters be suitable for that, at least on processors that have them? Matt From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 19:15:21 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BB5016A41F for ; Fri, 14 Oct 2005 19:15:21 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDEF743D55 for ; Fri, 14 Oct 2005 19:15:20 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail.ambrisko.com with ESMTP; 14 Oct 2005 12:15:21 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.11/8.12.9) with ESMTP id j9EJFJee059155 for ; Fri, 14 Oct 2005 12:15:19 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.11/8.12.11/Submit) id j9EJFJ8T059154 for freebsd-net@freebsd.org; Fri, 14 Oct 2005 12:15:19 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200510141915.j9EJFJ8T059154@ambrisko.com> To: freebsd-net@freebsd.org Date: Fri, 14 Oct 2005 12:15:19 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Subject: bge BCM5721/BCM5750 fixes to work with IPMI X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 19:15:21 -0000 Here are some first pass patches to make the bge driver not break IPMI. This was tested on a Dell PE850: bge0: mem 0xfe6f0000-0xfe6fffff irq 16 at device 0.0 on pci4 miibus1: on bge0 brgphy0: on miibus1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto It shouldn't break other bge cards and it might work with other Broadcom IPMI capable chips (they seem to have different usages). Please let me know how this goes. I gleaned this info. from the Linux drivers. YMMV. Doug A. Index: if_bge.c =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/dev/bge/if_bge.c,v retrieving revision 1.94 diff -u -p -r1.94 if_bge.c --- if_bge.c 4 Sep 2005 06:35:59 -0000 1.94 +++ if_bge.c 14 Oct 2005 19:11:11 -0000 @@ -264,6 +264,11 @@ static int bge_miibus_readreg (device_t, static int bge_miibus_writereg (device_t, int, int, int); static void bge_miibus_statchg (device_t); +#define BGE_RESET_START 1 +#define BGE_RESET_STOP 2 +static void bge_sig_post_reset(struct bge_softc *, int); +static void bge_sig_legacy(struct bge_softc *, int); +static void bge_sig_pre_reset(struct bge_softc *, int); static void bge_reset (struct bge_softc *); static device_method_t bge_methods[] = { @@ -1187,6 +1192,78 @@ bge_setmulti(sc) return; } +static void +bge_sig_pre_reset(sc, type) + struct bge_softc *sc; + int type; +{ + bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER); + + if (sc->bge_asf_mode & ASF_NEW_HANDSHAKE) { + switch (type) { + case BGE_RESET_START: + bge_writemem_ind(sc, BGE_SDI_STATUS, 0x1); /* START */ + break; + case BGE_RESET_STOP: + bge_writemem_ind(sc, BGE_SDI_STATUS, 0x2); /* UNLOAD */ + break; + } + } +} + +static void +bge_sig_post_reset(sc, type) + struct bge_softc *sc; + int type; +{ + if (sc->bge_asf_mode & ASF_NEW_HANDSHAKE) { + switch (type) { + case BGE_RESET_START: + bge_writemem_ind(sc, BGE_SDI_STATUS, 0x80000001); + /* START DONE */ + break; + case BGE_RESET_STOP: + bge_writemem_ind(sc, BGE_SDI_STATUS, 0x80000002); + break; + } + } +} + +static void +bge_sig_legacy(sc, type) + struct bge_softc *sc; + int type; +{ + if (sc->bge_asf_mode) { + switch (type) { + case BGE_RESET_START: + bge_writemem_ind(sc, BGE_SDI_STATUS, 0x1); /* START */ + break; + case BGE_RESET_STOP: + bge_writemem_ind(sc, BGE_SDI_STATUS, 0x2); /* UNLOAD */ + break; + } + } +} + +void bge_stop_fw(struct bge_softc *); +void +bge_stop_fw(sc) + struct bge_softc *sc; +{ + int i; + + if (sc->bge_asf_mode) { + bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM_FW, BGE_FW_PAUSE); + + for (i = 0; i < 100; i++ ) { + if (!(CSR_READ_4(sc, BGE_CPU_EVENT) & (1 << 14))) + break; + DELAY(10); + } + } +} + /* * Do endian, PCI and DMA initialization. Also check the on-board ROM * self-test results. @@ -1284,10 +1361,13 @@ bge_chipinit(sc) /* * Set up general mode register. */ + CSR_WRITE_4(sc, BGE_MODE_CTL, BGE_MODECTL_WORDSWAP_NONFRAME| BGE_MODECTL_BYTESWAP_DATA|BGE_MODECTL_WORDSWAP_DATA| BGE_MODECTL_MAC_ATTN_INTR|BGE_MODECTL_HOST_SEND_BDS| BGE_MODECTL_TX_NO_PHDR_CSUM|BGE_MODECTL_RX_NO_PHDR_CSUM); + BGE_SETBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP); + /* * Disable memory write invalidate. Apparently it is not supported @@ -2326,8 +2406,28 @@ bge_attach(dev) } } + sc->bge_asf_mode = 0; + if (bge_readmem_ind(sc, BGE_SOFTWARE_GENCOMM_SIG) + == BGE_MAGIC_NUMBER) { + if (bge_readmem_ind(sc, BGE_SOFTWARE_GENCOMM_NICCFG) + & BGE_HWCFG_ASF) { + sc->bge_asf_mode |= ASF_ENABLE; + if (CSR_READ_4(sc, BGE_MODE_CTL) + & BGE_MODECTL_STACKUP ) { + sc->bge_asf_mode |= ASF_STACKUP; + } + if (sc->bge_asicrev == BGE_ASICREV_BCM5750) { + sc->bge_asf_mode |= ASF_NEW_HANDSHAKE; + } + } + } + /* Try to reset the chip. */ + bge_stop_fw(sc); + bge_sig_pre_reset(sc, BGE_RESET_STOP); bge_reset(sc); + bge_sig_legacy(sc, BGE_RESET_STOP); + bge_sig_post_reset(sc, BGE_RESET_STOP); if (bge_chipinit(sc)) { printf("bge%d: chip initialization failed\n", sc->bge_unit); @@ -2636,11 +2736,14 @@ bge_reset(sc) sc->bge_asicrev != BGE_ASICREV_BCM5750) CSR_WRITE_4(sc, BGE_MARB_MODE, BGE_MARBMODE_ENABLE); +#ifdef ASF /* this conflicts with ASF/IPMI and is done in bge_sig_pre_reset*/ /* * Prevent PXE restart: write a magic number to the * general communications memory at 0xB50. */ bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER); +#endif + /* * Poll the value location we just wrote until * we see the 1's complement of the magic number. @@ -2676,6 +2779,8 @@ bge_reset(sc) /* Fix up byte swapping */ CSR_WRITE_4(sc, BGE_MODE_CTL, BGE_MODECTL_BYTESWAP_NONFRAME| BGE_MODECTL_BYTESWAP_DATA); + if (sc->bge_asf_mode & ASF_STACKUP) + BGE_SETBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP); CSR_WRITE_4(sc, BGE_MAC_MODE, 0); @@ -3338,7 +3443,13 @@ bge_init_locked(sc) /* Cancel pending I/O and flush buffers. */ bge_stop(sc); + + bge_stop_fw(sc); + bge_sig_pre_reset(sc, BGE_RESET_START); bge_reset(sc); + bge_sig_legacy(sc, BGE_RESET_START); + bge_sig_post_reset(sc, BGE_RESET_START); + bge_chipinit(sc); /* @@ -3728,7 +3839,16 @@ bge_stop(sc) /* * Tell firmware we're shutting down. */ - BGE_CLRBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP); + + bge_stop_fw(sc); + bge_sig_pre_reset(sc, BGE_RESET_STOP); + bge_reset(sc); + bge_sig_legacy(sc, BGE_RESET_STOP); + bge_sig_post_reset(sc, BGE_RESET_STOP); + if (sc->bge_asf_mode & ASF_STACKUP) + BGE_SETBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP); + else + BGE_CLRBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP); /* Free the RX lists. */ bge_free_rx_ring_std(sc); Index: if_bgereg.h =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/dev/bge/if_bgereg.h,v retrieving revision 1.36 diff -u -p -r1.36 if_bgereg.h --- if_bgereg.h 10 Jun 2005 16:49:05 -0000 1.36 +++ if_bgereg.h 14 Oct 2005 19:11:11 -0000 @@ -74,6 +74,8 @@ #define BGE_SOFTWARE_GENCOMM 0x00000B50 #define BGE_SOFTWARE_GENCOMM_SIG 0x00000B54 #define BGE_SOFTWARE_GENCOMM_NICCFG 0x00000B58 +#define BGE_SOFTWARE_GENCOMM_FW 0x00000B78 +#define BGE_FW_PAUSE 0x00000002 #define BGE_SOFTWARE_GENCOMM_END 0x00000FFF #define BGE_UNMAPPED 0x00001000 #define BGE_UNMAPPED_END 0x00001FFF @@ -1620,6 +1622,7 @@ #define BGE_MODE_CTL 0x6800 #define BGE_MISC_CFG 0x6804 #define BGE_MISC_LOCAL_CTL 0x6808 +#define BGE_CPU_EVENT 0x6810 #define BGE_EE_ADDR 0x6838 #define BGE_EE_DATA 0x683C #define BGE_EE_CTL 0x6840 @@ -1928,6 +1931,7 @@ struct bge_status_block { #define BGE_HWCFG_VOLTAGE 0x00000003 #define BGE_HWCFG_PHYLED_MODE 0x0000000C #define BGE_HWCFG_MEDIA 0x00000030 +#define BGE_HWCFG_ASF 0x00000080 #define BGE_VOLTAGE_1POINT3 0x00000000 #define BGE_VOLTAGE_1POINT8 0x00000001 @@ -2312,6 +2316,10 @@ struct bge_bcom_hack { int val; }; +#define ASF_ENABLE 1 +#define ASF_NEW_HANDSHAKE 2 +#define ASF_STACKUP 4 + struct bge_softc { struct ifnet *bge_ifp; /* interface info */ device_t bge_dev; @@ -2332,6 +2340,7 @@ struct bge_softc { u_int8_t bge_asicrev; u_int8_t bge_chiprev; u_int8_t bge_no_3_led; + u_int8_t bge_asf_mode; u_int8_t bge_pcie; struct bge_ring_data bge_ldata; /* rings */ struct bge_chain_data bge_cdata; /* mbufs */ From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 19:19:32 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E40E16A41F for ; Fri, 14 Oct 2005 19:19:32 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26C6843D53 for ; Fri, 14 Oct 2005 19:19:27 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id j9EJJPj5012542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Oct 2005 15:19:25 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id j9EJJJhL013625; Fri, 14 Oct 2005 15:19:19 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17232.1207.615226.432579@grasshopper.cs.duke.edu> Date: Fri, 14 Oct 2005 15:19:19 -0400 (EDT) To: "Poul-Henning Kamp" In-Reply-To: <31823.1129304673@critter.freebsd.dk> References: <17231.50841.442047.622878@grasshopper.cs.duke.edu> <31823.1129304673@critter.freebsd.dk> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: Garrett Wollman , net@FreeBSD.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 19:19:32 -0000 Poul-Henning Kamp writes: > The solution is not faster but less reliable timekeeping, the > solution is to move the scheduler(s) away from using time as an > approximation of cpu cycles. So you mean rather than use binuptime() in mi_switch(), use some per-cpu cycle counter (like rdtsc)? Heck, why not just use ticks for the scheduler and keep the expensive timekeeping code out of the critical path altogether? Does it really need better than 1ms resolution? Drew From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 19:22:23 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BBA916A41F for ; Fri, 14 Oct 2005 19:22:23 +0000 (GMT) (envelope-from zanecb@midwest-connections.com) Received: from mail.midwest-connections.com (mail.midwest-connections.com [69.148.152.10]) by mx1.FreeBSD.org (Postfix) with SMTP id 07A6343D7D for ; Fri, 14 Oct 2005 19:22:14 +0000 (GMT) (envelope-from zanecb@midwest-connections.com) Received: (qmail 8052 invoked from network); 14 Oct 2005 19:22:11 -0000 Received: from unknown (HELO mwc-acomputer) (zanecb@69.155.32.130) by 0 with SMTP; 14 Oct 2005 19:22:11 -0000 Date: Fri, 14 Oct 2005 14:22:23 -0500 From: "Zane C. B." To: freebsd-net@freebsd.org Message-ID: <20051014142223.000048c8@mwc-acomputer> X-Mailer: Sylpheed-Claws 1.0.4.1 Win32 (GTK+ 1.3.0; Win32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: How would I go about routing something like this? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 19:22:23 -0000 I have a few IP# I want to proxy transparently. There is a machine sitting after the router that I want to use as a proxy. How would I go about routing out going packets through that proxy from the router? Any one have any opinions on this or any thing? From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 19:36:40 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E31516A41F for ; Fri, 14 Oct 2005 19:36:40 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 628AA43D75 for ; Fri, 14 Oct 2005 19:36:33 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id F286FBC66; Fri, 14 Oct 2005 19:36:29 +0000 (UTC) To: Andrew Gallatin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 14 Oct 2005 15:19:19 EDT." <17232.1207.615226.432579@grasshopper.cs.duke.edu> Date: Fri, 14 Oct 2005 21:36:28 +0200 Message-ID: <33011.1129318588@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Garrett Wollman , net@FreeBSD.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 19:36:40 -0000 In message <17232.1207.615226.432579@grasshopper.cs.duke.edu>, Andrew Gallatin writes: > >Poul-Henning Kamp writes: > > The solution is not faster but less reliable timekeeping, the > > solution is to move the scheduler(s) away from using time as an > > approximation of cpu cycles. > >So you mean rather than use binuptime() in mi_switch(), use some >per-cpu cycle counter (like rdtsc)? yes. >Heck, why not just use ticks for the scheduler and keep the expensive >timekeeping code out of the critical path altogether? Does it really >need better than 1ms resolution? Because the resource accounting needs to know how much cpu power each process/thread has used, and the units used assume a constant clockrate (see times(3)) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 19:56:12 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E6EA16A41F; Fri, 14 Oct 2005 19:56:12 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDD5F43D48; Fri, 14 Oct 2005 19:56:11 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 6DC6D46BE3; Fri, 14 Oct 2005 15:56:11 -0400 (EDT) Date: Fri, 14 Oct 2005 20:56:11 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Michael VInce In-Reply-To: <434FABCC.2060709@roq.com> Message-ID: <20051014205434.C66245@fledge.watson.org> References: <434FABCC.2060709@roq.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, stable@freebsd.org Subject: Re: Network performance 6.0 with netperf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 19:56:12 -0000 On Fri, 14 Oct 2005, Michael VInce wrote: > I been doing some network benchmarking using netperf and just simple > 'fetch' on a new network setup to make sure I am getting the most out of > the router and servers, I thought I would post some results in case some > one can help me with my problems or if others are just interested to see > the results. Until recently (or maybe still), netperf was compiled with -DHISTOGRAM by our port/package, which resulted in a significant performance drop. I believe that the port maintainer and others have agreed to change it, but I'm not sure if it's been committed yet, or which packages have been rebuilt. You may want to manually rebuild it to make sure -DHISTOGRAM isn't set. You may want to try setting net.isr.direct=1 and see what performance impact that has for you. Robert N M Watson > > The network is currently like this, where machines A and B are the Dell 1850s > and C is the 2850 x 2 CPU (Server C has Apache2 worker MPM on it) and server > B is the gateway and A is acting as a client for fetch and netperf tests. > A --- B --- C > The 2 1850s are running AMD64 Freebsd 6.0rc1 (A and B) while C is running > 5.4-stable i386 from Oct 12 > > My main problem is that if I compile SMP into the machine C (5.4stable) the > network speed goes down to a range between 6mbytes/sec to 15mbytes/sec on > SMP. > If I use GENERIC kernel the performance goes up to what I have show below > which is around 65megabytes/sec for a 'fetch' get test from Apache server and > 933mbits/sec for netperf. > Does any know why why network performance would be so bad on SMP? > > Does any one think that if I upgrade the i386 SMP server to 6.0RC1 the SMP > network performance would improve? This server will be running java so I need > it to be stable and is the the reason I am using i386 and Java 1.4 > > I am happy with performance of direct machine to machine (non SMP) which is > pretty much full 1gigabit/sec speeds. > Going through the gateway server-B seems to drop its speed down a bit for in > and out direction tcp speed tests using netperf I get around 266mbits/sec > from server A through gateway Server-B to server-C which is quite adequate > for the link I currently have for it. > > Doing a 'fetch' get for a 1gig file from the Apache server gives good speeds > of close to 600mbits/sec but netperf shows its weakness with 266mbits/sec. > This is as fast as I need it to be but does any one know the weak points on > the router gateway to make it faster? Is this the performance I should expect > for FreeBSD as a router with gigabit ethers? > > I have seen 'net.inet.ip.fastforwarding' in some peoples router setups on the > list but nothing about what it does or what it can affect. > I haven't done any testing with polling yet but if I can get over > 900mbits/sec on the interfaces does polling help with passing packets from > one interface to the other? > All machines have PF running other then that they don't really have any > sysctls or special kernel options. > > Here are some speed benchmarks using netperf and 'fetch' gets. > > Server A to server C with server C using SMP kernel and just GENERIC kernel > further below > > B# /usr/local/netperf/netperf -l 10 -H server-C -t TCP_STREAM -i 10,2 -I 99,5 > -- -m 4096 -s 57344 -S 57344 > TCP STREAM TEST to server-C : +/-2.5% @ 99% conf. : histogram > Recv Send Send > Socket Socket Message Elapsed > Size Size Size Time Throughput > bytes bytes bytes secs. 10^6bits/sec > > 57344 57344 4096 10.06 155.99 > tank# fetch -o - > /dev/null http://server-C/file1gig.iso > - 100% of 1055 MB 13 MBps > 00m00s > > ##### Using generic non SMP kernel > Server A to server C with server C using GENERIC kernel. > A# fetch -o - > /dev/null http://server-C/file1gig.iso > - 100% of 1055 MB 59 MBps > 00m00s > > A# ./tcp_stream_script server-C > > /usr/local/netperf/netperf -l 60 -H server-C -t TCP_STREAM -i 10,2 -I 99,5 -- > -m 4096 -s 57344 -S 57344 > > Recv Send Send > Socket Socket Message Elapsed > Size Size Size Time Throughput > bytes bytes bytes secs. 10^6bits/sec > > 57344 57344 4096 60.43 266.92 > > ------------------------------------ > ############################################### > Connecting from server-A to B (gateway) > A# ./tcp_stream_script server-B > > ------------------------------------ > > /usr/local/netperf/netperf -l 60 -H server-B -t TCP_STREAM -i 10,2 -I 99,5 -- > -m 4096 -s 57344 -S 57344 > > TCP STREAM TEST to server-B : +/-2.5% @ 99% conf. : histogram > Recv Send Send > Socket Socket Message Elapsed > Size Size Size Time Throughput > bytes bytes bytes secs. 10^6bits/sec > > 57344 57344 4096 61.80 926.82 > > ------------------------------------ > ########################################## > Connecting from server B (gateway) to server C > Fetch and Apache2 test > B# fetch -o - > /dev/null http://server-C/file1gig.iso > - 100% of 1055 MB 74 MBps > 00m00s > > Netperf test > B# /usr/local/netperf/tcp_stream_script server-C > > /usr/local/netperf/netperf -l 60 -H server-C -t TCP_STREAM -i 10,2 -I 99,5 -- > -m 4096 -s 57344 -S 57344 > > TCP STREAM TEST to server-C : +/-2.5% @ 99% conf. : histogram > Recv Send Send > Socket Socket Message Elapsed > Size Size Size Time Throughput > bytes bytes bytes secs. 10^6bits/sec > > 57344 57344 4096 62.20 933.94 > > ------------------------------------ > > Cheers, > Mike > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 22:28:14 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2E2416A41F for ; Fri, 14 Oct 2005 22:28:14 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0733C43D45 for ; Fri, 14 Oct 2005 22:28:13 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9EMS4SC003614; Sat, 15 Oct 2005 08:28:04 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9EMS2cY017151; Sat, 15 Oct 2005 08:28:03 +1000 Date: Sat, 15 Oct 2005 08:28:04 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Poul-Henning Kamp In-Reply-To: <12907.1129286370@critter.freebsd.dk> Message-ID: <20051015074316.T1260@epsplex.bde.org> References: <12907.1129286370@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Garrett Wollman , Andrew Gallatin , net@freebsd.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 22:28:14 -0000 On Fri, 14 Oct 2005, Poul-Henning Kamp wrote: > In message <20051014192509.F80520@delplex.bde.org>, Bruce Evans writes: >> The timestamps in mi_switch() are taken on the same CPU and only their >> differences are used, so they don't even need to be synced. It they >> use the TSC, then the TSCs just need to have the same almost-constant >> frequency (or different almost-constant frequencies if timecounters >> werre per-CPU). > > Actually, I think we need to go back a step further. > > The task of the scheduler is to hand out a finite resource according > to a set policy. > > The finite resource is "instructions executed by a CPU". > > It used to be that CPUs ran at constant clock rates, and therefore > implementors made the simplifying assumption that > > instructions = a * time > > for some random but constant a and made their scheduling decisions > based on time. This is currently moot for p_runtime. p_runtime is not used for at least kernel scheduling. It is only used by userland (mostly for users to look at?). Schedulers use only ticks set periodically by sched_clock(). They should use p_runtime, given that we already pay the enormous cost of setting it on every normal interrupt. > Today CPUs do not run on constant rates but they have counters which > count the number of instruction cycles. Therefore talking about > computer effort in terms of "CPU second" is like selling rubber > band by the inch. > > The scheduler has a side job of accounting for CPU usage and the > API for accesing this info has unfortunately been specified in > terms of time rather than instructions. I disagree. Time is the only useful metric for users, and scheduling is fuzzy so it doesn't really care. Scheduling needs an approximation resource usage that can be obtained very efficiently. Its tick counts are very efficient and are precise enough even with a 100Hz period, but they aren't accurate enough since applications can hide from statistics clock ticks either accidentallly or intentionally. statclock was supposed to fix this but a never really did, especially with too-large values of HZ like 1000 -- with hz > stathz it is easy to use a periodic itimer to arrange to run about (hz - stathz) / hz of the time without ever seeing a statclock tick. Bruce From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 23:20:35 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7458416A41F for ; Fri, 14 Oct 2005 23:20:35 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE55C43D4C for ; Fri, 14 Oct 2005 23:20:34 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9ENKRNJ010475; Sat, 15 Oct 2005 09:20:27 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9ENKOIE005570; Sat, 15 Oct 2005 09:20:25 +1000 Date: Sat, 15 Oct 2005 09:20:26 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Poul-Henning Kamp In-Reply-To: <13600.1129298731@critter.freebsd.dk> Message-ID: <20051015084425.C1403@epsplex.bde.org> References: <13600.1129298731@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Garrett Wollman , Andrew Gallatin , net@freebsd.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 23:20:35 -0000 On Fri, 14 Oct 2005, Poul-Henning Kamp wrote: > In message <17231.43525.446450.161986@grasshopper.cs.duke.edu>, Andrew Gallatin > writes: >> What if somebody were to port the linux TSC syncing code, and use it >> to decide whether or not set kern.timecounter.smp_tsc=1? Would you >> object to that? > > Yes, I would object to that. > > Even to this day new CPU chips come out where TSC has flaws that > prevent it from being used as timecounter, and we do not have (NDA) > access to the data that would allow us to build a list of safe > hardware. Um, I have already pointed out that NDAs are not necessary. They (and staic lists) are also not sufficient. E.g., on my A7V-266E system (AXP on KT266A motherboard), the following breaks the TSC for timecounting: # Athlon idle hack for my KT266A. pciconf -w -b pci0:0:0 0x92 0xf9 # 79 -> f9 pciconf -w -b pci0:0:0 0x95 0x1a # 18 -> 1a Enough is freely disclosed, and the hardware is perfectly safe, but only if it configured without the (idle == really idle) setting which is set by the above hack but not by the BIOS. This setting reduces the temperature of a mostly-idle AXP system by about 10 degrees C. IIRC, the (idle == really idle) feature is entirely in the CPU and the hack just changes the state of the pins that control this feature. The breakage is much the same for 2 different generations of AXPs (a '1600 and a '2200) -- it causes jumps in the milliseconds per second range where without it there is only temperature-related drift in the nanoseconds per second range. I suspect all AXPs have this feature so they all have a potentially-broken TSC timecounter. Bruce From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 23:46:39 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8678616A41F for ; Fri, 14 Oct 2005 23:46:39 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBE8E43D45 for ; Fri, 14 Oct 2005 23:46:38 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9ENkNv7025410; Sat, 15 Oct 2005 09:46:23 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9ENkK5j002183; Sat, 15 Oct 2005 09:46:21 +1000 Date: Sat, 15 Oct 2005 09:46:22 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Andrew Gallatin In-Reply-To: <17231.50841.442047.622878@grasshopper.cs.duke.edu> Message-ID: <20051015092141.F1403@epsplex.bde.org> References: <17231.43525.446450.161986@grasshopper.cs.duke.edu> <13600.1129298731@critter.freebsd.dk> <17231.50841.442047.622878@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Garrett Wollman , Poul-Henning Kamp , net@freebsd.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 23:46:39 -0000 On Fri, 14 Oct 2005, Andrew Gallatin wrote: > Bear in mind that I have no clue about timekeeping. I got into this > just because I noticed using a TSC timecounter reduces context switch > latency by 40% or more on all the SMP platforms I have access to: > > 1.0GHz dual PIII : 50% reduction vs i8254 > 3.06GHz 1 HTT P4 : 55% vs ACPI-safe, 70% vs i8254) > 2.0GHz dual amd64: 43% vs ACPI-fast, 60% vs i8254) > > High context switch latency has been problem since FreeBSD 5 in > networking due to the context switches for netisr use, and for the > context switches required by interrupt threads. I'm sure it is a > problem in other parts of the system. I think it is pretty important, > and I'd really like to see it fixed. I'm not sure about that. More the reverse. Normal interrupts just don't occur often enough for their context switch time to matter. This is most clear for disk devices. Disk devices are relatively slow and have even slower seeks, so have to talk to them in large (~64K) blocks to get reasonable perfermonace and this results in not many transactions (except with especially braindamaged hardware that does something like interrupting for every 512-block). Network devices have a normal packet size of ~1500 bytes so they have to have interrupt moderation to reduce the interrupt load, and non-braindamaged ones do. However, for netisrs I think it is common to process only 1 packet per context switch, at least in the loopback case. Bruce From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 00:22:06 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 652E716A41F for ; Sat, 15 Oct 2005 00:22:06 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADA5143D46 for ; Sat, 15 Oct 2005 00:22:05 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9F0Lw4n029766; Sat, 15 Oct 2005 10:21:58 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9F0Ltpb010121; Sat, 15 Oct 2005 10:21:56 +1000 Date: Sat, 15 Oct 2005 10:21:56 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Poul-Henning Kamp In-Reply-To: <33011.1129318588@critter.freebsd.dk> Message-ID: <20051015094922.J1586@epsplex.bde.org> References: <33011.1129318588@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Garrett Wollman , Andrew Gallatin , net@freebsd.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2005 00:22:06 -0000 On Fri, 14 Oct 2005, Poul-Henning Kamp wrote: > In message <17232.1207.615226.432579@grasshopper.cs.duke.edu>, Andrew Gallatin > writes: >> >> Poul-Henning Kamp writes: >>> The solution is not faster but less reliable timekeeping, the >>> solution is to move the scheduler(s) away from using time as an >>> approximation of cpu cycles. >> >> So you mean rather than use binuptime() in mi_switch(), use some >> per-cpu cycle counter (like rdtsc)? > > yes. No. This would just break getrusage(2) and friends. >> Heck, why not just use ticks for the scheduler and keep the expensive >> timekeeping code out of the critical path altogether? Does it really >> need better than 1ms resolution? The schedulers already just use ticks (actually dynamic calls from statclock() to count ticks and do other things). Schedulers don't need anywhere near 1ms resolution, and have never used 1ms resolution, and haven't used 1/HZ resolution since FreeBSD-1/Net/3. Use of 1/HZ resolution went away with statclock. statclock normally gives 1/128 seconds resolution, but even this is too high for the algorithm in SCHED_4BSD, and that scheduler now scales it down to 1/16 seconds resolution except for fine tuning. Schedulers do this because a resolution of better than a tick was both unavailable on all hardware and would have been to inefficient if it was back when 1/100 seconds was a long time, and no one churned this part of their algorithm. > Because the resource accounting needs to know how much cpu power > each process/thread has used, and the units used assume a constant > clockrate (see times(3)) I was only thinking of kernel schedulers when I wrote the above. Userland schedulers might have to use times(3) or friends. They would use friends and not times(3) since according to its own man page times(3) was obsoleteted by getrusage(2) about 20 years ago. The main reason that it was obsoleted was that its wrong units are actually ticks. Its ticks used to be hardclock ticks, the same ones that the scheduler used. There were few problems with the rate of these -- the rate was just that of hardclock(), so it was 1/HZ with considerable jitter on old machines (because 1/HZ seconds was a short time on old machines). Now its units are ticks of length 1/CLK_TCK seconds, where CLK_TCK happens to be implemented as a compile-time constant that is always 128. We start with the high resolution units provided by timecounters and lose precision in several layers to support the old times(3) API. There are no real ticks invololved, only virtual ones in the times(3) layer. The constant clock rate for schedulers is still provided by statclock() having a constant rate. I believe it's actually a bug for this rate to be constant -- it is supposed to have jitter so that applications can't hide from statclock ticks. Bruce From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 00:26:00 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4ABE616A41F for ; Sat, 15 Oct 2005 00:26:00 +0000 (GMT) (envelope-from orac000@internet-mail.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id C67C243D55 for ; Sat, 15 Oct 2005 00:25:57 +0000 (GMT) (envelope-from orac000@internet-mail.org) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id 58C06CCF71E for ; Fri, 14 Oct 2005 20:25:55 -0400 (EDT) Received: from web3.messagingengine.com ([10.202.2.212]) by frontend1.internal (MEProxy); Fri, 14 Oct 2005 20:25:55 -0400 Received: by web3.messagingengine.com (Postfix, from userid 99) id 7D5C5C202; Fri, 14 Oct 2005 20:25:56 -0400 (EDT) Message-Id: <1129335956.14067.245211019@webmail.messagingengine.com> X-Sasl-Enc: LaFtUmc73ihogiPoU5dPLY/nACNHH+u2MlzACEulJjPh 1129335956 From: "Aluminium Oxide" To: freebsd-net@freebsd.org Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.5 (F2.73; T1.15; A1.64; B3.05; Q3.03) Date: Sat, 15 Oct 2005 09:55:56 +0930 Subject: ubpf link errer X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2005 00:26:00 -0000 Has anyone else seen this? I received an error on a kernel build during linking, for ubpf.o Just prior to this I had run o a cvsup with RELENG_5_4 and o run make buildworld with CFLAGS+=-O2 -pipe -fforce-mem -fforce-addr -funroll-loops -fcse-follow-jumps CXXFLAGS+= -fconserve-space During a make buildkernel last night, the following occurred. I reran make buildkernel with : CFLAGS+=-O2 -pipe CXXFLAGS+= -fconserve-space [I am now running with CFLAGS+=-O -pipe. I will post the reults when it completes.] but the same problem occurred: linking kernel udbp.o(.text+0x42c): In function `udbp_attach': : undefined reference to `ng_newtype' udbp.o(.text+0x45a): In function `udbp_attach': : undefined reference to `ng_make_node_common' udbp.o(.text+0x4a1): In function `udbp_attach': : undefined reference to `ng_name_node' udbp.o(.text+0x4e0): In function `udbp_attach': : undefined reference to `dumpnode' udbp.o(.text+0x4fc): In function `udbp_attach': : undefined reference to `ng_unref_node' udbp.o(.text+0x54b): In function `udbp_attach': : undefined reference to `dumpnode' udbp.o(.text+0x6b1): In function `udbp_detach': : undefined reference to `ng_rmnode_self' udbp.o(.text+0x6e6): In function `udbp_detach': : undefined reference to `dumpnode' udbp.o(.text+0x736): In function `udbp_detach': : undefined reference to `dumpnode' udbp.o(.text+0x752): In function `udbp_detach': : undefined reference to `ng_unref_node' udbp.o(.text+0x8d7): In function `udbp_in_transfer_cb': : undefined reference to `ng_package_data' udbp.o(.text+0x8fc): In function `udbp_in_transfer_cb': : undefined reference to `ng_address_hook' udbp.o(.text+0x91e): In function `udbp_in_transfer_cb': : undefined reference to `ng_snd_item' udbp.o(.text+0xc33): In function `ng_udbp_newhook': : undefined reference to `dumpnode' udbp.o(.text+0xc9a): In function `ng_udbp_newhook': : undefined reference to `dumphook' udbp.o(.text+0xd10): In function `ng_udbp_rcvmsg': : undefined reference to `dumpnode' udbp.o(.text+0xd53): In function `ng_udbp_rcvmsg': : undefined reference to `dumpitem' udbp.o(.text+0xda9): In function `ng_udbp_rcvmsg': : undefined reference to `M_NETGRAPH_MSG' udbp.o(.text+0xe6f): In function `ng_udbp_rcvmsg': : undefined reference to `dumpitem' udbp.o(.text+0xeaa): In function `ng_udbp_rcvmsg': : undefined reference to `dumpitem' udbp.o(.text+0xeee): In function `ng_udbp_rcvmsg': : undefined reference to `dumpitem' udbp.o(.text+0xf2b): In function `ng_udbp_rcvmsg': : undefined reference to `ng_address_ID' udbp.o(.text+0xf4d): In function `ng_udbp_rcvmsg': : undefined reference to `ng_snd_item' udbp.o(.text+0xf71): In function `ng_udbp_rcvmsg': : undefined reference to `dumpitem' udbp.o(.text+0xf93): In function `ng_udbp_rcvmsg': : undefined reference to `ng_free_item' udbp.o(.text+0xfb9): In function `ng_udbp_rcvmsg': : undefined reference to `dumpitem' udbp.o(.text+0xfe2): In function `ng_udbp_rcvmsg': : undefined reference to `ng_free_item' udbp.o(.text+0xff8): In function `ng_udbp_rcvmsg': : undefined reference to `M_NETGRAPH_MSG' udbp.o(.text+0x104a): In function `ng_udbp_rcvdata': : undefined reference to `dumphook' udbp.o(.text+0x108d): In function `ng_udbp_rcvdata': : undefined reference to `dumpnode' udbp.o(.text+0x10c4): In function `ng_udbp_rcvdata': : undefined reference to `dumpitem' udbp.o(.text+0x1105): In function `ng_udbp_rcvdata': : undefined reference to `dumpitem' udbp.o(.text+0x1127): In function `ng_udbp_rcvdata': : undefined reference to `ng_free_item' udbp.o(.text+0x12ef): In function `ng_udbp_rmnode': : undefined reference to `dumpnode' udbp.o(.text+0x14da): In function `ng_udbp_rmnode': : undefined reference to `dumpnode' udbp.o(.text+0x14f6): In function `ng_udbp_rmnode': : undefined reference to `ng_unref_node' udbp.o(.text+0x1509): In function `ng_udbp_rmnode': : undefined reference to `ng_make_node_common' udbp.o(.text+0x1546): In function `ng_udbp_rmnode': : undefined reference to `ng_name_node' udbp.o(.text+0x1585): In function `ng_udbp_rmnode': : undefined reference to `dumpnode' udbp.o(.text+0x15a7): In function `ng_udbp_rmnode': : undefined reference to `ng_unref_node' udbp.o(.text+0x15ef): In function `ng_udbp_rmnode': : undefined reference to `dumpnode' udbp.o(.text+0x1656): In function `ng_udbp_connect': : undefined reference to `dumphook' udbp.o(.text+0x1696): In function `ng_udbp_connect': : undefined reference to `dumphook' udbp.o(.text+0x16f9): In function `ng_udbp_disconnect' : : undefined reference to `dumphook' udbp.o(.text+0x173c): In function `ng_udbp_disconnect ': : undefined reference to `dumpnode' udbp.o(.text+0x178b): In function `ng_udbp_disconnect': : undefined reference to `dumphook' udbp.o(.text+0x17ce): In function `ng_udbp_disconnect': : undefined reference to `dumpnode' udbp.o(.text+0x181d): In function `ng_udbp_disconnect': : undefined reference to `dumphook' udbp.o(.text+0x1860): In function `ng_udbp_disconnect': : undefined reference to `dumpnode' udbp.o(.text+0x18ab): In function `ng_udbp_disconnect': : undefined reference to `dumphook' udbp.o(.text+0x18c4): In function `ng_udbp_disconnect': : undefined reference to `ng_rmnode_self' udbp.o(.rodata+0x4): undefined reference to `ng_parse_int32_type' udbp.o(.rodata+0x10): undefined reference to `ng_parse_int32_type' udbp.o(.rodata+0x24): undefined reference to `ng_parse_struct_type' udbp.o(.rodata+0x60): undefined reference to `ng_parse_int32_type' *** Error code 1 Stop in /usr/obj/usr/src/sys/H2O. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. H2O# -- Aluminium Oxide orac000@internet-mail.org -- http://www.fastmail.fm - Access your email from home and the web From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 00:35:07 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75F8C16A41F for ; Sat, 15 Oct 2005 00:35:07 +0000 (GMT) (envelope-from caiquanqing@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id C04F643D45 for ; Sat, 15 Oct 2005 00:35:06 +0000 (GMT) (envelope-from caiquanqing@gmail.com) Received: by xproxy.gmail.com with SMTP id t6so30789wxc for ; Fri, 14 Oct 2005 17:35:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=pia/NrAn9DuhABbGXgR5nUZOSU73AtNIUhawMBHVB/AuZYBXSEFN5913zJ0I+/Pi2Ow3h55dyOA/1ObqUHsA7oQZ3ctuZSP9TahROj/seGVS97RO43qoi0nzUYLlkoP3XgbPDxZcLnFa8XR41B6uCiphk/0b3j0JQhPXuEZOCIM= Received: by 10.70.9.10 with SMTP id 10mr1466117wxi; Fri, 14 Oct 2005 17:35:05 -0700 (PDT) Received: by 10.70.11.18 with HTTP; Fri, 14 Oct 2005 17:35:05 -0700 (PDT) Message-ID: <2b22951e0510141735g223a133dy6e1177751f587b0a@mail.gmail.com> Date: Fri, 14 Oct 2005 17:35:05 -0700 From: "Cai, Quanqing" To: Aluminium Oxide In-Reply-To: <1129335956.14067.245211019@webmail.messagingengine.com> MIME-Version: 1.0 References: <1129335956.14067.245211019@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: ubpf link errer X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2005 00:35:07 -0000 Yes, I tried it just now and got the problem at same place too. But My system is 7.0-CURRENT. On 10/14/05, Aluminium Oxide wrote: > > Has anyone else seen this? > > I received an error on a kernel build during linking, for ubpf.o > > > Just prior to this I had run > o a cvsup with > RELENG_5_4 > and > o run make buildworld with > CFLAGS+=3D-O2 -pipe -fforce-mem -fforce-addr -funroll-loops > -fcse-follow-jumps > CXXFLAGS+=3D -fconserve-space > > During a make buildkernel last night, the following occurred. I reran > make buildkernel with : > CFLAGS+=3D-O2 -pipe > CXXFLAGS+=3D -fconserve-space > > [I am now running with CFLAGS+=3D-O -pipe. I will post the reults when > it completes.] > > but the same problem occurred: > > linking kernel > udbp.o(.text+0x42c): In function `udbp_attach': > : undefined reference to `ng_newtype' > udbp.o(.text+0x45a): In function `udbp_attach': > : undefined reference to `ng_make_node_common' > udbp.o(.text+0x4a1): In function `udbp_attach': > : undefined reference to `ng_name_node' > udbp.o(.text+0x4e0): In function `udbp_attach': > : undefined reference to `dumpnode' > udbp.o(.text+0x4fc): In function `udbp_attach': > : undefined reference to `ng_unref_node' > udbp.o(.text+0x54b): In function `udbp_attach': > : undefined reference to `dumpnode' > udbp.o(.text+0x6b1): In function `udbp_detach': > : undefined reference to `ng_rmnode_self' > udbp.o(.text+0x6e6): In function `udbp_detach': > : undefined reference to `dumpnode' > udbp.o(.text+0x736): In function `udbp_detach': > : undefined reference to `dumpnode' > udbp.o(.text+0x752): In function `udbp_detach': > : undefined reference to `ng_unref_node' > udbp.o(.text+0x8d7): In function `udbp_in_transfer_cb': > : undefined reference to `ng_package_data' > udbp.o(.text+0x8fc): In function `udbp_in_transfer_cb': > : undefined reference to `ng_address_hook' > udbp.o(.text+0x91e): In function `udbp_in_transfer_cb': > : undefined reference to `ng_snd_item' > udbp.o(.text+0xc33): In function `ng_udbp_newhook': > : undefined reference to `dumpnode' > udbp.o(.text+0xc9a): In function `ng_udbp_newhook': > : undefined reference to `dumphook' > udbp.o(.text+0xd10): In function `ng_udbp_rcvmsg': > : undefined reference to `dumpnode' > udbp.o(.text+0xd53): In function `ng_udbp_rcvmsg': > : undefined reference to `dumpitem' > udbp.o(.text+0xda9): In function `ng_udbp_rcvmsg': > : undefined reference to `M_NETGRAPH_MSG' > udbp.o(.text+0xe6f): In function `ng_udbp_rcvmsg': > : undefined reference to `dumpitem' > udbp.o(.text+0xeaa): In function `ng_udbp_rcvmsg': > : undefined reference to `dumpitem' > udbp.o(.text+0xeee): In function `ng_udbp_rcvmsg': > : undefined reference to `dumpitem' > udbp.o(.text+0xf2b): In function `ng_udbp_rcvmsg': > : undefined reference to `ng_address_ID' > udbp.o(.text+0xf4d): In function `ng_udbp_rcvmsg': > : undefined reference to `ng_snd_item' > udbp.o(.text+0xf71): In function `ng_udbp_rcvmsg': > : undefined reference to `dumpitem' > udbp.o(.text+0xf93): In function `ng_udbp_rcvmsg': > : undefined reference to `ng_free_item' > udbp.o(.text+0xfb9): In function `ng_udbp_rcvmsg': > : undefined reference to `dumpitem' > udbp.o(.text+0xfe2): In function `ng_udbp_rcvmsg': > : undefined reference to `ng_free_item' > udbp.o(.text+0xff8): In function `ng_udbp_rcvmsg': > : undefined reference to `M_NETGRAPH_MSG' > udbp.o(.text+0x104a): In function `ng_udbp_rcvdata': > : undefined reference to `dumphook' > udbp.o(.text+0x108d): In function `ng_udbp_rcvdata': > : undefined reference to `dumpnode' > udbp.o(.text+0x10c4): In function `ng_udbp_rcvdata': > : undefined reference to `dumpitem' > udbp.o(.text+0x1105): In function `ng_udbp_rcvdata': > : undefined reference to `dumpitem' > udbp.o(.text+0x1127): In function `ng_udbp_rcvdata': > : undefined reference to `ng_free_item' > udbp.o(.text+0x12ef): In function `ng_udbp_rmnode': > : undefined reference to `dumpnode' > udbp.o(.text+0x14da): In function `ng_udbp_rmnode': > : undefined reference to `dumpnode' > udbp.o(.text+0x14f6): In function `ng_udbp_rmnode': > : undefined reference to `ng_unref_node' > udbp.o(.text+0x1509): In function `ng_udbp_rmnode': > : undefined reference to `ng_make_node_common' > udbp.o(.text+0x1546): In function `ng_udbp_rmnode': > : undefined reference to `ng_name_node' > udbp.o(.text+0x1585): In function `ng_udbp_rmnode': > : undefined reference to `dumpnode' > udbp.o(.text+0x15a7): In function `ng_udbp_rmnode': > : undefined reference to `ng_unref_node' > udbp.o(.text+0x15ef): In function `ng_udbp_rmnode': > : undefined reference to `dumpnode' > udbp.o(.text+0x1656): In function `ng_udbp_connect': > : undefined reference to `dumphook' > udbp.o(.text+0x1696): In function `ng_udbp_connect': > : undefined reference to `dumphook' > udbp.o(.text+0x16f9): In function `ng_udbp_disconnect' > : : undefined reference to `dumphook' > udbp.o(.text+0x173c): In function `ng_udbp_disconnect > ': : undefined reference to `dumpnode' > udbp.o(.text+0x178b): In function `ng_udbp_disconnect': > : undefined reference to `dumphook' > udbp.o(.text+0x17ce): In function `ng_udbp_disconnect': > : undefined reference to `dumpnode' > udbp.o(.text+0x181d): In function `ng_udbp_disconnect': > : undefined reference to `dumphook' > udbp.o(.text+0x1860): In function `ng_udbp_disconnect': > : undefined reference to `dumpnode' > udbp.o(.text+0x18ab): In function `ng_udbp_disconnect': > : undefined reference to `dumphook' > udbp.o(.text+0x18c4): In function `ng_udbp_disconnect': > : undefined reference to `ng_rmnode_self' > udbp.o(.rodata+0x4): undefined reference to `ng_parse_int32_type' > udbp.o(.rodata+0x10): undefined reference to `ng_parse_int32_type' > udbp.o(.rodata+0x24): undefined reference to `ng_parse_struct_type' > udbp.o(.rodata+0x60): undefined reference to `ng_parse_int32_type' > *** Error code 1 > > > Stop in /usr/obj/usr/src/sys/H2O. > *** Error code 1 > > > Stop in /usr/src. > *** Error code 1 > > > > Stop in /usr/src. > H2O# > -- > Aluminium Oxide > orac000@internet-mail.org > > -- > http://www.fastmail.fm - Access your email from home and the web > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 00:58:39 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEE1F16A41F for ; Sat, 15 Oct 2005 00:58:39 +0000 (GMT) (envelope-from caiquanqing@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC07843D46 for ; Sat, 15 Oct 2005 00:58:38 +0000 (GMT) (envelope-from caiquanqing@gmail.com) Received: by xproxy.gmail.com with SMTP id t6so32290wxc for ; Fri, 14 Oct 2005 17:58:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=l1U5HrMLfKc1SYL24Fbv1/p90kp5ZKLZhAKv3JQ/ux3MpwrQKfnSZ7cNqGZWLKASRK1P6gJiT7d4eMeSjhMtOkg5er6CKxID6t0BoNDE7nwvkgvI5IpIZt5siOCRYt8G8YJNZSdie7edW/iIa5kXgyX2CxMp1yJvERnwLdv0hsM= Received: by 10.70.40.11 with SMTP id n11mr1474350wxn; Fri, 14 Oct 2005 17:58:38 -0700 (PDT) Received: by 10.70.11.18 with HTTP; Fri, 14 Oct 2005 17:58:38 -0700 (PDT) Message-ID: <2b22951e0510141758x1edef8jf7caf2514c336514@mail.gmail.com> Date: Fri, 14 Oct 2005 17:58:38 -0700 From: "Cai, Quanqing" To: freebsd-firewire@freebsd.org, freebsd-arch@freebsd.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Tai-hwa Liang Subject: fwe -> fwip in GENERIC? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2005 00:58:40 -0000 Hi guys, When I was fixing bug kern/82727: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/82727, I found we use fwe(Ethernet over FireWire) in GENERIC kernel, not fwip(IP over FireWire). But we all know that IP over FireWire is more widely used on other OSes, an= d now this bug is fixed, do we need change fwe to fwip? I talked it with Tai-hwa Liang, he agrees with me. But he suggests me to post here for more advices, since there might be some considerations such like backward compatibility or code size that makes re@ made this decision. Please give you advice or opinion. Best Cai, Quanqing From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 02:14:36 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A377316A41F for ; Sat, 15 Oct 2005 02:14:36 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41FC143D48 for ; Sat, 15 Oct 2005 02:14:35 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id j9F2EY2P028894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Oct 2005 22:14:34 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id j9F2ESdS014512; Fri, 14 Oct 2005 22:14:28 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17232.26116.41070.832908@grasshopper.cs.duke.edu> Date: Fri, 14 Oct 2005 22:14:28 -0400 (EDT) To: Bruce Evans In-Reply-To: <20051015092141.F1403@epsplex.bde.org> References: <17231.43525.446450.161986@grasshopper.cs.duke.edu> <13600.1129298731@critter.freebsd.dk> <17231.50841.442047.622878@grasshopper.cs.duke.edu> <20051015092141.F1403@epsplex.bde.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: Garrett Wollman , Poul-Henning Kamp , net@freebsd.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2005 02:14:36 -0000 Bruce Evans writes: > On Fri, 14 Oct 2005, Andrew Gallatin wrote: > > > Bear in mind that I have no clue about timekeeping. I got into this > > just because I noticed using a TSC timecounter reduces context switch > > latency by 40% or more on all the SMP platforms I have access to: > > > > 1.0GHz dual PIII : 50% reduction vs i8254 > > 3.06GHz 1 HTT P4 : 55% vs ACPI-safe, 70% vs i8254) > > 2.0GHz dual amd64: 43% vs ACPI-fast, 60% vs i8254) > > > > High context switch latency has been problem since FreeBSD 5 in > > networking due to the context switches for netisr use, and for the > > context switches required by interrupt threads. I'm sure it is a > > problem in other parts of the system. I think it is pretty important, > > and I'd really like to see it fixed. > > I'm not sure about that. More the reverse. Normal interrupts just > don't occur often enough for their context switch time to matter. This > is most clear for disk devices. Disk devices are relatively slow and > have even slower seeks, so have to talk to them in large (~64K) blocks > to get reasonable perfermonace and this results in not many transactions > (except with especially braindamaged hardware that does something like > interrupting for every 512-block). Network devices have a normal > packet size of ~1500 bytes so they have to have interrupt moderation > to reduce the interrupt load, and non-braindamaged ones do. However, > for netisrs I think it is common to process only 1 packet per context > switch, at least in the loopback case. At least with our 4Gb Myrinet nics using a 9000 byte mtu, I have seen TCP performance drop off if I interrupt less often than once every 30us. So only so much interrupt moderation is possible. This works out to ~25,000 interrupts per second, when you factor in the delay for the host to ack the interrupt. Even with net.isr.direct, that's 25K context switches per second with the interrupt thread. Then there's latency. If we disable interrupt coalescing, we have a roughly 10us 1/2 rtt TCP latency for our 4Gb PCI-X cards on AMD64 (using linux, I don't have FreeBSD on any AMD64 with PCI-X). I expect this to be a few us lower with our new 10GbE nics. An inflation of the latency by 3.5us due to avoidable context switch latency really hurts. Heck, some people (mostly database users) care enough about latency over sockets to risk using bizzare sockets-offload protocols which offload a TCP connection to other protocols and cut this latency in half (one example is http://www.myri.com/myrinet/performance/Sockets-MX). Drew From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 02:35:59 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AD1616A41F; Sat, 15 Oct 2005 02:35:59 +0000 (GMT) (envelope-from ikob@koganei.wide.ad.jp) Received: from ns.koganei.wide.ad.jp (ns.koganei.wide.ad.jp [202.249.37.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2344443D45; Sat, 15 Oct 2005 02:35:58 +0000 (GMT) (envelope-from ikob@koganei.wide.ad.jp) Received: from [10.0.1.3] (235.pool7.dsl24mtokyo.att.ne.jp [165.76.174.235]) (authenticated bits=0) by ns.koganei.wide.ad.jp (8.12.11/8.12.11) with ESMTP id j9F2ZtRR036190; Sat, 15 Oct 2005 11:35:56 +0900 (JST) (envelope-from ikob@koganei.wide.ad.jp) In-Reply-To: <2b22951e0510141758x1edef8jf7caf2514c336514@mail.gmail.com> References: <2b22951e0510141758x1edef8jf7caf2514c336514@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Katsushi Kobayashi Date: Sat, 15 Oct 2005 11:35:55 +0900 To: "Cai, Quanqing" X-Mailer: Apple Mail (2.734) Cc: freebsd-net@freebsd.org, Tai-hwa Liang , freebsd-firewire@freebsd.org, freebsd-arch@freebsd.org Subject: Re: fwe -> fwip in GENERIC? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2005 02:35:59 -0000 Hi, Although I don't know the detail of fwe technology, I understand the technology is a proprietary one. It is better to provide a compatibility with RFC standard firewire over IP, if some volunteer are there. On 2005/10/15, at 9:58, Cai, Quanqing wrote: > Hi guys, > > When I was fixing bug kern/82727: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/82727, I found we use > fwe(Ethernet over FireWire) in GENERIC kernel, not fwip(IP over > FireWire). > But we all know that IP over FireWire is more widely used on other > OSes, and > now this bug is fixed, do we need change fwe to fwip? > > I talked it with Tai-hwa Liang, he agrees with me. But he suggests > me to > post here for more advices, since there might be some > considerations such > like backward compatibility or code size that makes re@ made this > decision. > > Please give you advice or opinion. > > Best > Cai, Quanqing > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch- > unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 05:12:55 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1B6A16A41F for ; Sat, 15 Oct 2005 05:12:55 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5704843D46 for ; Sat, 15 Oct 2005 05:12:55 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 0CA54BC66; Sat, 15 Oct 2005 05:12:51 +0000 (UTC) To: Bruce Evans From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 15 Oct 2005 09:20:26 +1000." <20051015084425.C1403@epsplex.bde.org> Date: Sat, 15 Oct 2005 07:12:51 +0200 Message-ID: <35063.1129353171@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Garrett Wollman , Andrew Gallatin , net@freebsd.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2005 05:12:55 -0000 In message <20051015084425.C1403@epsplex.bde.org>, Bruce Evans writes: >On Fri, 14 Oct 2005, Poul-Henning Kamp wrote: >> Even to this day new CPU chips come out where TSC has flaws that >> prevent it from being used as timecounter, and we do not have (NDA) >> access to the data that would allow us to build a list of safe >> hardware. > >Um, I have already pointed out that NDAs are not necessary. > >They (and staic lists) are also not sufficient. [...] Which is why I am totally set against using the TSC on SMP machines and only grudingly accept it for UP machines that do not have ACPI counters. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 07:04:30 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFF4816A41F for ; Sat, 15 Oct 2005 07:04:30 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: from ns2.alphaque.com (ns2.alphaque.com [202.75.47.153]) by mx1.FreeBSD.org (Postfix) with SMTP id 0FEB043D49 for ; Sat, 15 Oct 2005 07:04:24 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: (qmail 9475 invoked by uid 0); 15 Oct 2005 07:04:17 -0000 Received: from lucifer.net-gw.com (HELO prophet.alphaque.com) (202.75.47.153) by lucifer.net-gw.com with SMTP; 15 Oct 2005 07:04:17 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by prophet.alphaque.com (8.13.3/8.13.3) with ESMTP id j9F741YI002571; Sat, 15 Oct 2005 15:04:01 +0800 (MYT) (envelope-from dinesh@alphaque.com) Message-ID: <4350A9E0.7060108@alphaque.com> Date: Sat, 15 Oct 2005 15:04:00 +0800 From: Dinesh Nair User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050326 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dinesh Nair References: <434E9769.6010603@alphaque.com> In-Reply-To: <434E9769.6010603@alphaque.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Broadcom NetXtreme BCM5751M Gigabit Ethernet PCI Express and FreeBSD 4.10 [SOLVED] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2005 07:04:31 -0000 On 10/14/05 01:20 Dinesh Nair said the following: > > has anyone got the above gigabit ethernet working with freebsd 4.10 ? upgrading to 4.11-RELEASE solved the problem. there were more special code handling functions to be added, other than just adding in the PCI IDs into if_bge.c and if_bgereg.h. -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.alphaque.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 08:21:35 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F168D16A420 for ; Sat, 15 Oct 2005 08:21:35 +0000 (GMT) (envelope-from gbryant@roamingsolutions.net) Received: from basillia.speedxs.net (basillia.speedxs.net [83.98.255.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A1E143D46 for ; Sat, 15 Oct 2005 08:21:35 +0000 (GMT) (envelope-from gbryant@roamingsolutions.net) Received: from ongers.net (ongers.speedxs.nl [83.98.237.210]) by basillia.speedxs.net (Postfix) with ESMTP id 614A0732C; Sat, 15 Oct 2005 10:09:09 +0200 (CEST) Received: from (66.110.35.16 [66.110.35.16]) by MailEnable Inbound Mail Agent with ESMTP; Sat, 15 Oct 2005 10:27:11 +0200 Message-ID: <4350BC26.6030406@roamingsolutions.net> Date: Sat, 15 Oct 2005 10:21:58 +0200 From: G Bryant User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Zane C. B." References: <20051014142223.000048c8@mwc-acomputer> In-Reply-To: <20051014142223.000048c8@mwc-acomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0541-3, 2005/10/14), Outbound message X-Antivirus-Status: Clean Cc: FreeBSD Subject: Re: How would I go about routing something like this? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2005 08:21:36 -0000 You can either use ipfw fwd command (has to be enabled in the kernel), where you forward all lan incoming packets with destination port 80, to the ip and port that the other proxy is listening on, or (more complicated) you can use squid proxy on your local machine, use ipfw to fwd all lan incoming packets with destination port 80 to the port that squid is listening on (normally 3128), and then you have to specify in the squid config that it must use a different proxy as it's "parent" proxy. You could then either enable caching on this machine, or configure it as a "dummy" proxy. You will probably have to read all the man pages anyway, so use this as a starting point. Regards, Graham Zane C. B. wrote: >I have a few IP# I want to proxy transparently. There is a machine >sitting after the router that I want to use as a proxy. How would I go >about routing out going packets through that proxy from the router? Any >one have any opinions on this or any thing? > > ps. I have opinions on lot's of things :) >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 09:49:29 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BF9D16A41F for ; Sat, 15 Oct 2005 09:49:29 +0000 (GMT) (envelope-from orac000@internet-mail.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFBD843D4C for ; Sat, 15 Oct 2005 09:49:27 +0000 (GMT) (envelope-from orac000@internet-mail.org) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id BC0EDCD12B2; Sat, 15 Oct 2005 05:49:26 -0400 (EDT) Received: from web3.messagingengine.com ([10.202.2.212]) by frontend1.internal (MEProxy); Sat, 15 Oct 2005 05:49:26 -0400 Received: by web3.messagingengine.com (Postfix, from userid 99) id EB6CD157D; Sat, 15 Oct 2005 05:49:26 -0400 (EDT) Message-Id: <1129369766.11295.245225284@webmail.messagingengine.com> X-Sasl-Enc: A/h6RZB1hH4PK7lzeSy1RJc5qtPowXtc40cv5dqTonWF 1129369766 From: "Aluminium Oxide" To: "Cai, Quanqing" Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.5 (F2.73; T1.15; A1.64; B3.05; Q3.03) References: <1129335956.14067.245211019@webmail.messagingengine.com> <2b22951e0510141735g223a133dy6e1177751f587b0a@mail.gmail.com> In-Reply-To: <2b22951e0510141735g223a133dy6e1177751f587b0a@mail.gmail.com> Date: Sat, 15 Oct 2005 19:19:26 +0930 Cc: freebsd-net@freebsd.org Subject: Re: ubpf link errer X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2005 09:49:29 -0000 CORRECTION: that should be udbp.o not ubpf.o -------- -------- : ( Don't know what I was thinking then.. spent too long reading pf rules. On Fri, 14 Oct 2005 17:35:05 -0700, "Cai, Quanqing" said: > Yes, I tried it just now and got the problem at same place too. But My > system is 7.0-CURRENT. > > On 10/14/05, Aluminium Oxide wrote: > > > > Has anyone else seen this? > > > > I received an error on a kernel build during linking, for ubpf.o > > > > > > Just prior to this I had run > > o a cvsup with > > RELENG_5_4 > > and > > o run make buildworld with > > CFLAGS+=-O2 -pipe -fforce-mem -fforce-addr -funroll-loops > > -fcse-follow-jumps > > CXXFLAGS+= -fconserve-space > > > > During a make buildkernel last night, the following occurred. I reran > > make buildkernel with : > > CFLAGS+=-O2 -pipe > > CXXFLAGS+= -fconserve-space > > > > [I am now running with CFLAGS+=-O -pipe. I will post the reults when > > it completes.] > > > > but the same problem occurred: > > > > linking kernel > > udbp.o(.text+0x42c): In function `udbp_attach': > > : undefined reference to `ng_newtype' > > udbp.o(.text+0x45a): In function `udbp_attach': > > : undefined reference to `ng_make_node_common' ............... > > : undefined reference to `dumphook' > > udbp.o(.text+0x18c4): In function `ng_udbp_disconnect': > > : undefined reference to `ng_rmnode_self' > > udbp.o(.rodata+0x4): undefined reference to `ng_parse_int32_type' > > udbp.o(.rodata+0x10): undefined reference to `ng_parse_int32_type' > > udbp.o(.rodata+0x24): undefined reference to `ng_parse_struct_type' > > udbp.o(.rodata+0x60): undefined reference to `ng_parse_int32_type' > > *** Error code 1 > > > > > > Stop in /usr/obj/usr/src/sys/H2O. > > *** Error code 1 > > > > > > Stop in /usr/src. > > *** Error code 1 > > > > > > > > Stop in /usr/src. > > H2O# > > -- > > Aluminium Oxide > > orac000@internet-mail.org > > > > -- > > http://www.fastmail.fm - Access your email from home and the web > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > -- Aluminium Oxide orac000@internet-mail.org -- http://www.fastmail.fm - One of many happy users: http://www.fastmail.fm/docs/quotes.html From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 17:42:27 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E194216A41F for ; Sat, 15 Oct 2005 17:42:27 +0000 (GMT) (envelope-from orac000@internet-mail.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82DDE43D6A for ; Sat, 15 Oct 2005 17:42:27 +0000 (GMT) (envelope-from orac000@internet-mail.org) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id 0A7DBCD1594; Sat, 15 Oct 2005 13:42:26 -0400 (EDT) Received: from web3.messagingengine.com ([10.202.2.212]) by frontend1.internal (MEProxy); Sat, 15 Oct 2005 13:42:26 -0400 Received: by web3.messagingengine.com (Postfix, from userid 99) id C2693CED9; Sat, 15 Oct 2005 13:42:26 -0400 (EDT) Message-Id: <1129398146.7179.245240282@webmail.messagingengine.com> X-Sasl-Enc: GCL44iJhcW9A05wxuA9CGs6FVgex5CY6Gb2R9h221SdQ 1129398146 From: "Aluminium Oxide" To: "Aluminium Oxide" , "Cai, Quanqing" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.5 (F2.73; T1.15; A1.64; B3.05; Q3.03) References: <1129335956.14067.245211019@webmail.messagingengine.com> <2b22951e0510141735g223a133dy6e1177751f587b0a@mail.gmail.com> <1129369766.11295.245225284@webmail.messagingengine.com> In-Reply-To: <1129369766.11295.245225284@webmail.messagingengine.com> Date: Sun, 16 Oct 2005 03:12:26 +0930 Cc: freebsd-net@freebsd.org Subject: Re: ubpf link errer X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2005 17:42:28 -0000 I've moved this to the usb list. Sorry for the inconvenience. --=20 Aluminium Oxide orac000@internet-mail.org --=20 http://www.fastmail.fm - And now for something completely different=85 From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 18:37:19 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CEEC16A420 for ; Sat, 15 Oct 2005 18:37:19 +0000 (GMT) (envelope-from leandrogarber@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB9EF43D67 for ; Sat, 15 Oct 2005 18:37:13 +0000 (GMT) (envelope-from leandrogarber@gmail.com) Received: by zproxy.gmail.com with SMTP id 8so642095nzo for ; Sat, 15 Oct 2005 11:37:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=OYRBxROZ1U68auE/VIcdN097uSrPciXjvWfvily/ya7W2kGmL+CO9zoB+ww2L6hkh8V0ZvAsDm1SbJHRIVeKaFpeUDrABWeWu08wYhiEeDvNJUqGxVLUsEfL/O9nINbqbkfZCjMYaTtuw+SX77q/RxnOzQ3FKn9jaYsngz6Y3QU= Received: by 10.36.139.2 with SMTP id m2mr891645nzd; Sat, 15 Oct 2005 11:37:13 -0700 (PDT) Received: by 10.36.12.3 with HTTP; Sat, 15 Oct 2005 11:37:13 -0700 (PDT) Message-ID: <473ee2630510151137i3d08cc14o8355a41559b9b85b@mail.gmail.com> Date: Sat, 15 Oct 2005 15:37:13 -0300 From: Leandro Garber To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Broadcom Wireless LAN X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2005 18:37:19 -0000 Hi, im new in FreeBSD, and installed it yesterday. I have a problem with my BroadCom Wireless NIC. I'm using the last STABLE branch of FreeBSD, i've make installed ndis and then converted my nic's wxp drivers and make installed if_ndis... i kldloaded those modules, and everything was fine. I ifconfigured ndis0 (the NIC that appear when i kldload if_ndis) and put it UP. NIC's ip is 10.0.0.1 , router's ip is 10.0.0.2.... i ping 10.0.0.2 and its ok... i also can change my router configuration @ 10.0.0.2:80 ... when i ping www.google.com this happens: root@pupulandia# ping www.google.com PING www.l.google.com (64.233.187.104): 56 data bytes ping: sendto: Network is down ping: sendto: Network is down ping: sendto: Network is down ping: sendto: Network is down ping: sendto: Network is down ^C --- www.l.google.com ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss any idea ? From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 18:46:43 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B2BF16A41F for ; Sat, 15 Oct 2005 18:46:43 +0000 (GMT) (envelope-from tenpin784@metrocast.net) Received: from mx0.metrocast.net (coltrane-mx.metrocast.net [65.175.128.144]) by mx1.FreeBSD.org (Postfix) with SMTP id 379C243D46 for ; Sat, 15 Oct 2005 18:46:42 +0000 (GMT) (envelope-from tenpin784@metrocast.net) Received: (qmail 9933 invoked from network); 15 Oct 2005 18:46:42 -0000 Received: from [127.0.0.1] ([65.175.136.163]) by mx0.metrocast.net ([65.175.128.144]) with ESMTP via TCP; 15 Oct 2005 18:46:42 -0000 Message-ID: <43514E8D.3020809@metrocast.net> Date: Sat, 15 Oct 2005 14:46:37 -0400 From: John Barbieri User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Leandro Garber References: <473ee2630510151137i3d08cc14o8355a41559b9b85b@mail.gmail.com> In-Reply-To: <473ee2630510151137i3d08cc14o8355a41559b9b85b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Broadcom Wireless LAN X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2005 18:46:43 -0000 Leandro Garber wrote: >Hi, im new in FreeBSD, and installed it yesterday. I have a problem with my >BroadCom Wireless NIC. > >I'm using the last STABLE branch of FreeBSD, i've make installed ndis and >then converted my nic's wxp drivers and make installed if_ndis... > >i kldloaded those modules, and everything was fine. I ifconfigured ndis0 >(the NIC that appear when i kldload if_ndis) and put it UP. > >NIC's ip is 10.0.0.1 , router's ip is 10.0.0.2.... i ping >10.0.0.2 and its ok... i also can change my router >configuration @ 10.0.0.2:80 ... > >when i ping www.google.com this happens: > >root@pupulandia# ping www.google.com >PING www.l.google.com >(64.233.187.104): >56 data bytes >ping: sendto: Network is down >ping: sendto: Network is down >ping: sendto: Network is down >ping: sendto: Network is down >ping: sendto: Network is down >^C >--- www.l.google.com ping statistics --- >5 packets transmitted, 0 packets received, 100% packet loss > >any idea ? >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > Probably a dumb question, but when you do a netstat -rn, do you have a default gateway? and is it your routers IP? eg: xwing# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 65.175.136.1 UGSc 15 57408426 sis0 except for 65.175.136.1 it should be 10.0.0.2 according to your setup. if it is not, try doing a route add default 10.0.0.2 and then try pinging again. to make the change last through a reboot, check /etc/rc.conf for a line that says: defaultrouter="10.0.0.2" hope this helps john From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 18:49:39 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF56E16A41F for ; Sat, 15 Oct 2005 18:49:39 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C39F43D49 for ; Sat, 15 Oct 2005 18:49:39 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id A8DBB46B91; Sat, 15 Oct 2005 14:49:38 -0400 (EDT) Date: Sat, 15 Oct 2005 19:49:38 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Bruce Evans In-Reply-To: <20051015092141.F1403@epsplex.bde.org> Message-ID: <20051015194738.C66245@fledge.watson.org> References: <17231.43525.446450.161986@grasshopper.cs.duke.edu> <13600.1129298731@critter.freebsd.dk> <17231.50841.442047.622878@grasshopper.cs.duke.edu> <20051015092141.F1403@epsplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Garrett Wollman , Poul-Henning Kamp , Andrew Gallatin , net@freebsd.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2005 18:49:40 -0000 On Sat, 15 Oct 2005, Bruce Evans wrote: > I'm not sure about that. More the reverse. Normal interrupts just > don't occur often enough for their context switch time to matter. This > is most clear for disk devices. Disk devices are relatively slow and > have even slower seeks, so have to talk to them in large (~64K) blocks > to get reasonable perfermonace and this results in not many transactions > (except with especially braindamaged hardware that does something like > interrupting for every 512-block). Network devices have a normal packet > size of ~1500 bytes so they have to have interrupt moderation to reduce > the interrupt load, and non-braindamaged ones do. However, for netisrs > I think it is common to process only 1 packet per context switch, at > least in the loopback case. The Mach scheduler allows deferred wakeups to be issued -- "wake up a thread in the sleep queue -- but when it's convenient" to avoid premature preemtion. This helps avoid immediate preemption where it's unnecessary and/or undesirable: specifically, to avoid preemption when the preempting thread will immediately require a lock held by the signalling thread, as occurs with the netisr and TCP. I've not yet investigated tweaking things, or even a scheduler trace to see for sure that this is happening, but it wouldn't surprise me at all if we're seeing extra context switches due to premature or untimely preemption following wakeup. Robert N M Watson