From owner-freebsd-hackers Sun Dec 30 2:28:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bcfw1d.bridge.com (bcfw1d.ext.bridge.com [167.76.159.31]) by hub.freebsd.org (Postfix) with ESMTP id 75EC437B416 for ; Sun, 30 Dec 2001 02:28:31 -0800 (PST) Received: (from uucp@localhost) by bcfw1d.bridge.com (8.10.2/8.10.2) id fBUATq623800 for ; Sun, 30 Dec 2001 04:29:53 -0600 (CST) Received: from <411generator@charm.net> (unknown [167.76.56.34]) by bcfw1d via smap (V2.1) id xmao23413; Sun, 30 Dec 01 04:29:42 -0600 Received: from bsm1ua.bridge.com (bsm1ua.bridge.com [167.76.56.24]) by mail1srv.bridge.com (8.8.8/8.7.3) with ESMTP id EAA22971 for ; Sun, 30 Dec 2001 04:14:08 -0600 (CST) From: 411generator@charm.net Received: from [159.42.33.76] by bsm1ua.bridge.com (Netscape Mail Server v2.02) with SMTP id EWQ22500 for ; Sun, 30 Dec 2001 04:13:39 -0600 Message-Id: To: freebsd-hackers@freebsd.org Subject: Make a living on the internet! Reply-To: ebook2354@yahoo.com Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Date: Sun, 30 Dec 2001 02:18:24 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG $10K in 30 Days!!

 

I'll Show YOU How To Make At Least....
$10,000 In 30 Days or Less Every Month... NO RISK!!!

 

Would you like to make at least $10,000
(in 30 days or less) every month? 
Here's how you can make that money  
(and more... ) every month, and make  
your first $10,000 in 30 days or less  
- with absolutely no risk!
Click Here For Complete Details!


If you have received this message in error and wish to be
 removed from future mailings CLICK HERE

To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 30 3:10:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mcqueen.wolfsburg.de (pns.wobline.de [212.68.68.5]) by hub.freebsd.org (Postfix) with ESMTP id 601D137B417; Sun, 30 Dec 2001 03:09:40 -0800 (PST) Received: from colt.ncptiddische.net (ppp-304.wobline.de [212.68.71.25]) by mcqueen.wolfsburg.de (8.11.3/8.11.3/tw-20010821) with ESMTP id fBUB9S827705; Sun, 30 Dec 2001 12:09:28 +0100 Received: from tisys.org (jodie.ncptiddische.net [192.168.0.2]) by colt.ncptiddische.net (8.11.6/8.11.6) with ESMTP id fBUB9cX92181; Sun, 30 Dec 2001 12:09:39 +0100 (CET) (envelope-from nils@tisys.org) Received: (from nils@localhost) by tisys.org (8.11.6/8.11.6) id fBUB9PR01633; Sun, 30 Dec 2001 12:09:25 +0100 (CET) (envelope-from nils) Date: Sun, 30 Dec 2001 12:08:50 +0100 From: Nils Holland To: =?iso-8859-1?Q?S=F8ren_Schmidt?= Cc: Matthew Dillon , Mike Silbersack , "Brandon S. Allbery KF8NH" , ian j hart , Matthew Gilbert , freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: 4.4-STABLE crashes - suspects new ata-driver over wd-drivers Message-ID: <20011230120850.A1519@tisys.org> Mail-Followup-To: =?iso-8859-1?Q?S=F8ren_Schmidt?= , Matthew Dillon , Mike Silbersack , "Brandon S. Allbery KF8NH" , ian j hart , Matthew Gilbert , freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG References: <20011230002620.A630@tisys.org> <200112300018.fBU0IjU16002@freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <200112300018.fBU0IjU16002@freebsd.dk>; from sos@freebsd.dk on Sun, Dec 30, 2001 at 01:18:45AM +0100 X-Operating-System: FreeBSD jodie.ncptiddische.net 4.5-PRERELEASE FreeBSD 4.5-PRERELEASE X-Machine-Uptime: 11:58AM up 1:20, 2 users, load averages: 0.00, 0.02, 0.00 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Dec 30, 2001 at 01:18:45AM +0100, Søren Schmidt stood up and spoke: > > Is the 0x03051106 the KT133A? I guess so. Well, since I seem to have the > > KT133 (without the A), I guess my values would be fairly useless... > > However, if I'm wrong and the 0x03051106 *is* the KT133 that I have, I will > > certainly post pciconf output! > > Its the KT133 with or without the A :) its the revid that tells them apart Sounds like another VIA idea ;-) Anyway, here's my pciconf output (which somehow looks different from what you posted yesterday as an example). I've also included my dmesg.boot below once again - I hope that this helps you verify that my chip is indeed the kind of chip from which you wanted the values ;-) root@poison> pciconf -r -b pci0:0:0 0x0:0xff 0x00000006 0x00000011 0x00000005 0x00000003 0x00000006 0x00000000 0x00000010 0x00000022 0x00000003 0x00000000 0x00000000 0x00000006 0x00000000 0x00000008 0x00000000 0x00000000 0x00000008 0x00000000 0x00000000 0x000000d0 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x000000a0 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000016 0x000000f4 0x0000006b 0x000000b4 0x00000047 0x0000000a 0x00000030 0x00000030 0x000000ee 0x00000080 0x00000010 0x00000010 0x00000020 0x00000020 0x00000030 0x00000030 0x0000003f 0x0000003a 0x00000000 0x00000020 0x000000d4 0x000000d4 0x000000d4 0x000000c4 0x00000010 0x0000000c 0x00000065 0x0000002d 0x00000008 0x0000007f 0x00000000 0x00000000 0x000000de 0x00000088 0x000000cc 0x0000000c 0x0000000e 0x00000083 0x000000e2 0x00000000 0x00000001 0x000000b4 0x00000019 0x00000002 0x00000000 0x00000000 0x00000000 0x00000000 0x0000000f 0x000000c0 0x00000000 0x00000000 0x00000080 0x00000000 0x00000000 0x00000000 0x00000002 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000032 0x00000000 0x00000000 0x00000002 0x000000c0 0x00000020 0x00000000 0x00000013 0x00000002 0x00000000 0x0000001f 0x00000000 0x00000000 0x00000000 0x00000000 0x0000006f 0x00000022 0x00000010 0x00000063 0x000000db 0x00000063 0x0000002a 0x00000070 0x00000011 0x000000ff 0x00000010 0x0000000f 0x00000027 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000001 0x00000000 0x00000002 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000003 0x00000003 0x00000000 0x00000022 0x00000000 0x00000000 0x00000000 0x00000000 0x00000080 0x00000000 0x00000000 Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.5-PRERELEASE #0: Sat Dec 29 12:14:04 CET 2001 root@poison.ncptiddische.net:/usr/obj/usr/src/sys/JODIE Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 996633567 Hz CPU: AMD Athlon(tm) processor (996.63-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x642 Stepping = 2 Features=0x183f9ff AMD Features=0xc0440000<,AMIE,DSP,3DNow!> real memory = 805240832 (786368K bytes) avail memory = 779374592 (761108K bytes) Preloaded elf kernel "kernel" at 0xc0366000. Pentium Pro MTRR support enabled Using $PIR table, 8 entries at 0xc00fdba0 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 irq 11 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xd000-0xd00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 7.2 irq 10 pci0: at 7.3 irq 10 chip1: at device 7.4 on pci0 pcm0: port 0xe400-0xe403,0xe000-0xe003,0xdc00-0xdcff irq 5 at device 7.5 on pci0 bktr0: mem 0xdc001000-0xdc001fff irq 10 at device 16.0 on pci0 iicbb0: on bti2c0 iicbus0: on iicbb0 master-only smbus0: on bti2c0 bktr0: Hauppauge Model 44354 C221 bktr0: Detected a MSP3415D-B3 at 0x80 bktr0: Hauppauge WinCast/TV, Philips FR1216 PAL FM tuner, msp3400c stereo, remote control. pci0: (vendor=0x109e, dev=0x0878) at 16.1 irq 10 ed0: port 0xe800-0xe81f irq 11 at device 17.0 on pci0 ed0: address 00:20:18:2f:42:2d, type NE2000 (16 bit) orm0: $10K in 30 Days!!

 

I'll Show YOU How To Make At Least....
$10,000 In 30 Days or Less Every Month... NO RISK!!!

 

Would you like to make at least $10,000
(in 30 days or less) every month? 
Here's how you can make that money  
(and more... ) every month, and make  
your first $10,000 in 30 days or less  
- with absolutely no risk!
Click Here For Complete Details!


If you have received this message in error and wish to be
 removed from future mailings CLICK HERE

To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 31 14:15:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from imo-d09.mx.aol.com (imo-d09.mx.aol.com [205.188.157.41]) by hub.freebsd.org (Postfix) with ESMTP id 22E7E37B42A for ; Mon, 31 Dec 2001 14:15:05 -0800 (PST) Received: from TD790@aol.com by imo-d09.mx.aol.com (mail_out_v31_r1.9.) id n.16f.67b33e8 (3314); Mon, 31 Dec 2001 17:14:58 -0500 (EST) From: TD790@aol.com Message-ID: <16f.67b33e8.29623d61@aol.com> Date: Mon, 31 Dec 2001 17:14:57 EST Subject: PRO/1000 vs PRO/100 Performance To: hackers@freebsd.org Cc: jlemon@flugsvamp.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 139 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Does anyone have a feel for how the PRO/1000 XT card/driver compares to the eepro100/fxp driver as a 100Mb/s solution? Thanks, Dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 31 14:33:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 2E47E37B419 for ; Mon, 31 Dec 2001 14:33:56 -0800 (PST) Received: from pool0372.cvx40-bradley.dialup.earthlink.net ([216.244.43.117] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16LAzr-0006Hv-00; Mon, 31 Dec 2001 14:33:31 -0800 Message-ID: <3C30E7B9.96EFA40F@mindspring.com> Date: Mon, 31 Dec 2001 14:33:29 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Julian Elischer , Mike Silbersack , Josef Karthauser , Tomas Svensson , freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD performing worse than Linux? References: <200112311941.fBVJfvc25822@apollo.backplane.com> <3C30C5F9.BCC1BAE8@mindspring.com> <200112312017.fBVKHTs26004@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > Terry, I don't think you quite understand the problem. From the server's > point of view NOTHING IS WRONG. Any non-USB-ethernet client would have > no problem whatsoever with the large number of small packets that the > server is sending, nor can the server just arbitrarily decide that 8 > packets is too much, because doing so screws up bandwidth over long-haul > links. The server can not arbitrarily limit its window size because > the problem only occurs with small packets. So how is the server > supposed to figure out the difference between between normal packet > loss and packet loss due to the client having a USB adapter and not > being able to handle lots of tiny packets? Uh, Matt, the window size is a negotiated value between the server and the client. What the server wants is irrelevant, if the client wants a smaller window, since the value is MIN(server_wants,client_wants). So if the problem is that the FreeBSD USB<->ethernet connected client can't handle that many outstanding packets, then the place to fix it is _obviously_ the FreeBSD USB<->ethernet driver. Julian did similar work already in the InterJet in order to control the advertised window size on the client, and therefore do what the AltQ code is supposed to do, but without congesting the intermediate router. > New-Reno might be able to help but it would have to be hacked up a bit > to send a double ack to the server to force the server to reduce its > congestion window. New-Reno is a mess and I am not volunteering to > hack it up more. The Rate-Halving algorithm is used with FACK in order to halve the window size in the presence of failures (like the one being seen here). Again, the place that this should happen is on the client, not the server. I don't understand why you think this is a server problem, when it is not the server hardware where the failure is occuring? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 31 14:44:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id B67E837B416 for ; Mon, 31 Dec 2001 14:44:44 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBVMigK35786; Mon, 31 Dec 2001 14:44:42 -0800 (PST) (envelope-from dillon) Date: Mon, 31 Dec 2001 14:44:42 -0800 (PST) From: Matthew Dillon Message-Id: <200112312244.fBVMigK35786@apollo.backplane.com> To: Terry Lambert Cc: Julian Elischer , Mike Silbersack , Josef Karthauser , Tomas Svensson , freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD performing worse than Linux? References: <200112311941.fBVJfvc25822@apollo.backplane.com> <3C30C5F9.BCC1BAE8@mindspring.com> <200112312017.fBVKHTs26004@apollo.backplane.com> <3C30E7B9.96EFA40F@mindspring.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry, I give up. Maybe if you actually tried to go in and fix it you would see what I'm talking about. For your information: * Julian's work has nothing to do with this particular problem. It has to do with constricted bandwidth. This issue has nothing to do with USB's bandwidth limitations. * The window size is not negotiated between client and server (other then whether window scaling is used or not, which is non-applicable). Each side's TCP protocol receiver controls the window size it advertises. * The window size has no bearing on the number of in-transit packets, unless you make assumptions in regards to the packet size. That's the crux of the problem faced by the receiver in this case. * If you think reducing the receive window on the fly is easy, try it and you will find out that it isn't as easy as you might have thought. * And if you think you can handle that, now try figuring out, in the receiver, how to dynamically increase and reduce the window based on the size of the packets being received and try to discern the difference between packet loss and a driver problem, to then limit the number of in-transit packets (through a massive window reduction). Good luck! * I never said the server was the problem. To the contrary, I've been saying that the client is the problem.. USB ethernet is broken, period. As I have said, it may be possible to make new-reno on the client (receiver) side to cause the transmit side to close its congestion window (and to keep it closed, or fairly closed). But I aint gonna be the one to try to do it. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 31 15:18:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 386A137B416; Mon, 31 Dec 2001 15:18:40 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBVNRAj02362; Mon, 31 Dec 2001 15:27:11 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112312327.fBVNRAj02362@mass.dis.org> To: Mike Barcroft Cc: Mike Smith , hackers@freebsd.org, msmith@mass.dis.org Subject: Re: loadable aio In-Reply-To: Message from Mike Barcroft of "Mon, 31 Dec 2001 03:48:07 EST." <20011231034807.D45114@espresso.q9media.com> Date: Mon, 31 Dec 2001 15:27:10 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > What part of searching a path for a matching file is "black magic"? > > > > Shells have been doing this for decades... > > %%% > /* > * Load /boot/kernel/procfs.ko > * XXX: why does this work? > */ > chdir("/"); > kldload("procfs"); You should only need the last kldload call. Any other magic is probably left over from times when kldload didn't work properly. > If that's not black magic, I'd like to know what is. I'd like to > refer you to the kldload(2) manual, but unfortunately it doesn't > document how kldload(2) works. :( The synopsis for kldload(2) should be "find and load the named kernel module". In essence, it takes either a module name and searches the "right" places for it, or it takes a fully-qualified pathname and loads exactly that module. That's all; anything else is a bug in the implementation and should be fixed. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 31 15:28: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id EAACD37B42C for ; Mon, 31 Dec 2001 15:27:51 -0800 (PST) Received: from pool0372.cvx40-bradley.dialup.earthlink.net ([216.244.43.117] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16LBq8-0001SJ-00; Mon, 31 Dec 2001 15:27:32 -0800 Message-ID: <3C30F45D.88A9EAE2@mindspring.com> Date: Mon, 31 Dec 2001 15:27:25 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Julian Elischer , Mike Silbersack , Josef Karthauser , Tomas Svensson , freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD performing worse than Linux? References: <200112311941.fBVJfvc25822@apollo.backplane.com> <3C30C5F9.BCC1BAE8@mindspring.com> <200112312017.fBVKHTs26004@apollo.backplane.com> <3C30E7B9.96EFA40F@mindspring.com> <200112312244.fBVMigK35786@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > Terry, I give up. Maybe if you actually tried to go in and fix it > you would see what I'm talking about. For your information: I don't have a USB/Ethernet adapter. > * Julian's work has nothing to do with this particular problem. It > has to do with constricted bandwidth. This issue has nothing to do > with USB's bandwidth limitations. The specific work in question is rate limiting the *other end* of a TCP connection. This would let a client with a problem like this *slow the server down*, without any code changes on the server, and without buffer congestion on the server. You have not seen this work, I think. > * The window size is not negotiated between client and server (other > then whether window scaling is used or not, which is non-applicable). > Each side's TCP protocol receiver controls the window size it > advertises. So you are saying that if the client advertised a smaller TCP window, then the server would have less simultaneously oustanding packets in flight before an ACK was required. I think you and I are just using different definitions of "negotiated": the client controls the transmit window which is available to the server. So we are agreed: If the client with the USB bogosity were to advertise a smaller window, then the server would have less packets in flight; and since the problem appears (to me) to be that there are more packets in flight from the server than the USB<->ethernet dongle is capable of buffering to send down the slow (USB) side of the link, then this would prevent the server from buffer-overflowing the dongle into losing packets. It seems to me that this is a clear case of impedence mismatch, with a fast link trying to jam more packets down a slow link than is possible, with the ACKs being sent by the dongle, rather than delayed until it has sufficient buffer space available. > * The window size has no bearing on the number of in-transit packets, > unless you make assumptions in regards to the packet size. That's > the crux of the problem faced by the receiver in this case. This is why I suggested that the PSC rate-halving algorithm would probably be useful. The real problem here is that more data is being sent to the dongle than it is able to forward. The packet trace bears this conclusion out. > * If you think reducing the receive window on the fly is easy, > try it and you will find out that it isn't as easy as you > might have thought. Both Julian's code and the PSC code do this. I wasn't suggesting writing the code from scratch. However, I have to say that I've implicitly done this sort of limitation in a commercial product, before, anolg with Jeffrey Hsu, by controlling transmit and receive window sizes in a proxy server. Clearly, a web server on a 1G link talking to a client on the other end of a 28.8k link would quickly overrun a proxy server's transmit buffers, otherwise, as the received data is shoved out at a much slower rate. This failure mode is consistant with the use of a much slower USB link on the other side of a USB<->ethernet dongle. The problem here is that the don'e itself is not going to do the necessary flow rate limiting (it doesn't, or this discussion would have never happened in the first place), so you have to trigger it as a secondary effect, like the PSC rate halving, or the code Julian did to force the advertised window sizes smaller over time. Julian's code was exactly analogous to the "dongle" situation, except the "dongle" was a CISCO router on the other end of a slow link from an InterJet, where we wanted a single flow to not monopolize all the transmit buffers on the router, so that we would stil be able to get data through. This basically meant controlling the amount of the pool taken up, times the pool retention time, on the router, for any given set of flows. As a side effect, you could intentionally reduce the limit on the advertised window size, until the flow rate dropped. This is basically the balance the TCP Rate Halving code seeks to achieve (the balance between buffer congestion losses and the overall throughput). Please see: http://www.psc.edu/networking/rate_halving.html > * And if you think you can handle that, now try figuring out, in the > receiver, how to dynamically increase and reduce the window based on > the size of the packets being received and try to discern the difference > between packet loss and a driver problem, to then limit the number > of in-transit packets (through a massive window reduction). Good luck! Julian already did this, as I stated. > * I never said the server was the problem. To the contrary, I've > been saying that the client is the problem.. USB ethernet is > broken, period. > > As I have said, it may be possible to make new-reno on the client > (receiver) side to cause the transmit side to close its congestion > window (and to keep it closed, or fairly closed). But I aint gonna > be the one to try to do it. The PSC Rate Halving code, which was first implemented on BSD (NetBSD 1.3.2): http://www.psc.edu/networking/ftp/tools/netbsd132_rh_10.tgz Already does this. Here is a partial excerpt: Hoe [Hoe95] suggested that during Fast Recovery the TCP data sender space out retransmissions and new data on alternate acknowledgements across the entire recovery RTT. (Note that this eliminates the half RTT lull in sending which occurs in Reno TCP.) [ We could, in other words, turn New Reno back on without the performance loss we were seeing that caused us to turn it off ] The Rate-Halving algorithm implements Hoe's idea. The algorithm may be implemented in NewReno, SACK, and ECN-style TCP implementations. Rate-Halving has a number of other useful properties as well. It results in a slightly lower final value for cwnd following recovery, which has been suggested by Floyd and others as the more correct value. The Rate-Halving algorithm provides proper adjustments to the congestion window in response to congestion signals such as a lost segment or an ECN-Echo bit [RFC2481]. These [ We are particularly interested in the "lost segment" case here ] adjustments are largely independent of the strategy used to retransmit missing segments, allowing Rate-Halving to be extended for use in other TCP implementations or even non-TCP transport protocols. See also RFC 3148 (we are, in effect, talking about "last hop" congestion here). - Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 31 15:28:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 34E1637B42B for ; Mon, 31 Dec 2001 15:28:05 -0800 (PST) Received: from whizzo.transsys.com (#6@localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.6/8.11.6) with ESMTP id fBVNRt719835; Mon, 31 Dec 2001 18:27:55 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200112312327.fBVNRt719835@whizzo.transsys.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Julian Elischer Cc: Terry Lambert , Matthew Dillon , Mike Silbersack , Josef Karthauser , Tomas Svensson , freebsd-hackers@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: FreeBSD performing worse than Linux? References: In-reply-to: Your message of "Mon, 31 Dec 2001 12:27:17 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 31 Dec 2001 18:27:55 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG An underlying issue here is why applications decide to set TCP_NODELAY options on sockets, rather than just letting Nagle's algorithm do the right thing. I recall some handwaving about this in the X server some years ago to make mouse movements "smoother". For the problem at hand, if both the client and server machines didn't do TCP_NODLEAY, then there'd only be one packet smaller than the TCP MSS in flight between the transmitter and receiver at any one time. I think that poking OpenSSH to not set the TCP_NODELAY option "fixed" this problem. I was just pondering the TCP implementation in 4.5-PRERELEASE, and it doesn't look like there's any explicit delay after a write going on, other than Nagle's algorithm, in the TCP packetization code. So setting TCP_NODELAY is almost certain the Wrong Thing for most applications to do. Perhaps there ought to be a warning in the man page about being a poor network citizen, flooding the Internet with tinygrams and otherwise making the performance of your application generally suck. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 31 15:28:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by hub.freebsd.org (Postfix) with ESMTP id 6F81037B429 for ; Mon, 31 Dec 2001 15:28:16 -0800 (PST) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.11.1/8.11.1) id fBVNS9K45361; Mon, 31 Dec 2001 18:28:09 -0500 (EST) (envelope-from bicknell) Date: Mon, 31 Dec 2001 18:28:09 -0500 From: Leo Bicknell To: Matthew Dillon Cc: Terry Lambert , Julian Elischer , Mike Silbersack , Josef Karthauser , Tomas Svensson , freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD performing worse than Linux? Message-ID: <20011231232809.GA45295@ussenterprise.ufp.org> Mail-Followup-To: Matthew Dillon , Terry Lambert , Julian Elischer , Mike Silbersack , Josef Karthauser , Tomas Svensson , freebsd-hackers@FreeBSD.ORG References: <200112311941.fBVJfvc25822@apollo.backplane.com> <3C30C5F9.BCC1BAE8@mindspring.com> <200112312017.fBVKHTs26004@apollo.backplane.com> <3C30E7B9.96EFA40F@mindspring.com> <200112312244.fBVMigK35786@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112312244.fBVMigK35786@apollo.backplane.com> Organization: United Federation of Planets Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In a message written on Mon, Dec 31, 2001 at 02:44:42PM -0800, Matthew Dillon wrote: > * I never said the server was the problem. To the contrary, I've > been saying that the client is the problem.. USB ethernet is > broken, period. I think several people are trying to say the same thing off this point but not saying it the same way, so: * Hacking TCP (or pretty much anything else) is the _wrong_ solution to this problem. The solution is to "fix" USB ethernet and/or not use it. * Since this is a fairly well defined, easy to reproduce packet loss situation that TCP seems to not handle particularly well, it might be worth using it to investigate if there is a generic TCP improvment that could be made. Fair enough? -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 31 15:53:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 7231F37B425 for ; Mon, 31 Dec 2001 15:53:38 -0800 (PST) Received: from pool0372.cvx40-bradley.dialup.earthlink.net ([216.244.43.117] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16LCFD-0001pN-00; Mon, 31 Dec 2001 15:53:27 -0800 Message-ID: <3C30FA6E.231CCE0C@mindspring.com> Date: Mon, 31 Dec 2001 15:53:18 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Louis A. Mamakos" Cc: Julian Elischer , Matthew Dillon , Mike Silbersack , Josef Karthauser , Tomas Svensson , freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD performing worse than Linux? References: <200112312327.fBVNRt719835@whizzo.transsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Louis A. Mamakos" wrote: > > An underlying issue here is why applications decide to set TCP_NODELAY > options on sockets, rather than just letting Nagle's algorithm do > the right thing. I recall some handwaving about this in the X server > some years ago to make mouse movements "smoother". OK, I've been making an assumption here that is perhaps incorrect, but is consistant with the traces posted so far: I've assumed that the data is lost between the ethernet side of the dongle and the USB side of the dongle. If the FreeBSD USB driver is really a dog (I have a hard time buying that) or the dongle USB hardware is superior to that in the PC being used (I have a hard time buying that one, either), then it's just possible that the data losses are FreeBSD's, and not a result of dongle buffer overrun. You'd need a breakout box for USB, and a USB system without the problem (Linux?) to prove it via dumps, though. That said: There is no problem with turning on TCP_NODELAY. If anything, the resulting data sent through the dongle would be *less* bursty (being application paced), and tend to be *less* likely to fill up any pool in the middle to the point of overflow. This really has all the earmarks of a pool congestion (not a link congestion) problem in the dongle, to my mind. > For the problem at hand, if both the client and server machines didn't > do TCP_NODLEAY, then there'd only be one packet smaller than the > TCP MSS in flight between the transmitter and receiver at any one > time. I think that poking OpenSSH to not set the TCP_NODELAY option > "fixed" this problem. I think it masked it. If you had a less CPU-intensive test application, I think you would see that you can still overrun the buffer. The masking is a natural effect of decreasing the overall payload encapsulation overhead. But increase the amount of payload, and you should still see the problem rear its ugly head, since the link rate differential is so large on either side of the dongle. A fugly way of handling the problem would be to initiate a flow control mechanism between the dongle and the FreeBSD ethernet driver. This is tantamount to the hardware flow control required for the MNP modem knock-offs by Microcomm competitors who used flow control as a means of keeping the pool size manageable, so that they could really cheap out on putting RAM in the modem, and undercut Microcomm's prices. For this to work, you'd have to have cooperative firmware in the dongles; I think that taking that approach is a lost cause, unless we are downloading our own firmware. I think we will have to tackle it another way. Teaching the driver about TCP windows, and delaying transmissions until 50% of the receive window is satisfied would probably work, but is a very unsatisfactory approach (even though we know that transmit over the link is not going to have the same problem as receive, due to the speed differential across the dongle). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 31 16:43:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 7E46A37B417 for ; Mon, 31 Dec 2001 16:43:09 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g010h0i36281; Mon, 31 Dec 2001 16:43:00 -0800 (PST) (envelope-from dillon) Date: Mon, 31 Dec 2001 16:43:00 -0800 (PST) From: Matthew Dillon Message-Id: <200201010043.g010h0i36281@apollo.backplane.com> To: "Louis A. Mamakos" Cc: Julian Elischer , Terry Lambert , Mike Silbersack , Josef Karthauser , Tomas Svensson , freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD performing worse than Linux? References: <200112312327.fBVNRt719835@whizzo.transsys.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :An underlying issue here is why applications decide to set TCP_NODELAY :options on sockets, rather than just letting Nagle's algorithm do :the right thing. I recall some handwaving about this in the X server :some years ago to make mouse movements "smoother". : :For the problem at hand, if both the client and server machines didn't :do TCP_NODLEAY, then there'd only be one packet smaller than the :TCP MSS in flight between the transmitter and receiver at any one :time. I think that poking OpenSSH to not set the TCP_NODELAY option :"fixed" this problem. : :I was just pondering the TCP implementation in 4.5-PRERELEASE, and :it doesn't look like there's any explicit delay after a write going :on, other than Nagle's algorithm, in the TCP packetization code. So :setting TCP_NODELAY is almost certain the Wrong Thing for most :applications to do. Perhaps there ought to be a warning in the :man page about being a poor network citizen, flooding the Internet :with tinygrams and otherwise making the performance of your application :generally suck. : :louie Yes, you are correct. There is no real reason for ssh to set TCP_NODELAY on FreeBSD and, in fact, I believe it didn't used to. We should just turn it off. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 31 18:11:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id D9C5237B428 for ; Mon, 31 Dec 2001 18:11:29 -0800 (PST) Received: from pool0168.cvx40-bradley.dialup.earthlink.net ([216.244.42.168] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16LEOd-0004Zv-00; Mon, 31 Dec 2001 18:11:19 -0800 Message-ID: <3C311AC9.99B5FC9C@mindspring.com> Date: Mon, 31 Dec 2001 18:11:21 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: "Louis A. Mamakos" , Julian Elischer , Mike Silbersack , Josef Karthauser , Tomas Svensson , freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD performing worse than Linux? References: <200112312327.fBVNRt719835@whizzo.transsys.com> <200201010043.g010h0i36281@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > Yes, you are correct. There is no real reason for ssh to set > TCP_NODELAY on FreeBSD and, in fact, I believe it didn't used to. > We should just turn it off. FWIW, I agree that it should not be set. Setting socket options has the unfortunate side effect of grabbing more per connection memory than would otherwise be necessary. Still, it's legal to set the option, even if it's not really a sane thing to do in many cases, so disallowing it is not a "fix" for anything. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 31 18:47: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id B9C3C37B41D for ; Mon, 31 Dec 2001 18:46:56 -0800 (PST) Received: from whizzo.transsys.com (#6@localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.6/8.11.6) with ESMTP id g012ko721041; Mon, 31 Dec 2001 21:46:51 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200201010246.g012ko721041@whizzo.transsys.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert Cc: Matthew Dillon , Julian Elischer , Mike Silbersack , Josef Karthauser , Tomas Svensson , freebsd-hackers@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: FreeBSD performing worse than Linux? References: <200112312327.fBVNRt719835@whizzo.transsys.com> <200201010043.g010h0i36281@apollo.backplane.com> <3C311AC9.99B5FC9C@mindspring.com> In-reply-to: Your message of "Mon, 31 Dec 2001 18:11:21 PST." <3C311AC9.99B5FC9C@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 31 Dec 2001 21:46:50 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Disabling Nagle's algorithm for no good reason has very poor scaling behavior. This is what happens when TCP_NODELAY is enabled on a socket. If you look at the work function for most network elements, the part that runs out of gas first is per-packet forwarding performance. Sure, you need to have adequate bus bandwidth to move stuff through a box, but it's performing per-packet forwarding operations and policy which is the resource that's most difficult to make more of. I think this is true for toy routers based on PC platform as well as high-end boxes like the Cisco 12000 series. Juniper managed adequate forwarding performance using specialized ASIC implementions in the forwarding path. Of this statement, I'm sure; in my day job at UUNET, I talk to all the major backbone router vendors, and forwarding performance (and also reasonable routing protocol implementions) is a show-stopper requirement they labor mightily over. So here was have a mechanism with wonderful properties - it's a trivial yet clever implementation of a self tuning mechanism to prevent tinygrams from being generated by a TCP without all manner of complicated timers. It give great performance on LAN and other high-speed interconnects where remote echo type applications are demanding, yet over long delay paths where remote echo is gonna suck no matter what you do, it automatically aggregates packets. Nagle's algorithm and Van Jacobson's slow-start algorithm allowed the Internet to survive over congested paths. And they did so with a bunch of self-tuning behavior independent of the bandwidth*delay product of the path the connection was running over. It was and is amazing stuff. Likewise, the original problem in this thread is likely caused by some part of the USB Ethernet implementation having inadequate per-packet resources. It's probably not about the number of bytes, but the number of transactions. You see here a modern reimplementation of essentially the same problem that the 3COM 3C501 ISA ethernet card had 15 years ago - back to back packets were consistantly dropped because of the poor per-packet buffering implementation. It was absolutely repeatable. Sure, it's "legal" to generate streams of tinygrams and not use Nagle's algorithm to aggregate the sender's traffic, but it's just plain rude and on low bandwidth links, it sucks because of all the extra 40 byte headers you're carrying around. I'm sure TCP_NODELAY got added because it sounds REALLY C00L to make the interactive thing go better. But clearly people don't understand the impact of turning on the cleverly named option and how it probably doesn't really improve things. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 31 20:52:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from artemis.drwilco.net (artemis.drwilco.net [209.167.6.62]) by hub.freebsd.org (Postfix) with ESMTP id 89B1C37B433 for ; Mon, 31 Dec 2001 20:52:11 -0800 (PST) Received: from ceres.drwilco.net (docwilco.xs4all.nl [213.84.68.230]) by artemis.drwilco.net (8.11.6/8.11.6) with ESMTP id g014qDR23432 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Mon, 31 Dec 2001 23:52:16 -0500 (EST) (envelope-from drwilco@drwilco.net) Message-Id: <5.1.0.14.0.20020101054451.00b35370@mail.drwilco.net> X-Sender: drwilco@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 01 Jan 2002 06:00:54 +0100 To: freebsd-hackers@freebsd.org From: "Rogier R. Mulhuijzen" Subject: Running out of bufferspace Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, First of all happy new year, etc. =) My problem: I'm writing a device driver kernel module that uses kernel level sosend() from the d_write write() function. But it runs out of bufferspace (error 55) when I really stress it (sending 15 megs in 3-4 secs over UDP with 32 or 60K packets). Thing is, my mbufs are fine, peak is 1/3rd of max. I also use sowriteable() to check if it's safe to send, and sbspace() tells me I have the full 128K sndbuf that I configured available. So I have 2 questions... 1) which buffers are there that I can run out of here and where can I check their status? 2) Should I free() the uio I get from userspace after I have passed it to the sosend? Side note on 1): after I run out of bufferspace with my little driver the box continues to function fine as far as I can tell, except that mount_smbfs has trouble: [ root@hera:~ ] # truss mount -t smbfs //drwilco@ceres/D$ /ceres/d_drive/ readlink("/etc/malloc.conf",0xbfbffa94,63) ERR#2 'No such file or directory' mmap(0x0,4096,0x3,0x1002,-1,0x0) = 671551488 (0x28071000) break(0x807c000) = 0 (0x0) break(0x807d000) = 0 (0x0) open(".",0,00) = 3 (0x3) chdir(0xbfbff090) = 0 (0x0) sigaction(SIGSYS,0xbfbfeaac,0xbfbfea94) = 0 (0x0) __getcwd(0xbfbff090,0x400) = 0 (0x0) sigaction(SIGSYS,0xbfbfea94,0x0) = 0 (0x0) fchdir(0x3) = 0 (0x0) close(3) = 0 (0x0) stat("/ceres/d_drive",0xbfbfeff4) = 0 (0x0) fork() = 3331 (0xd03) smbfs: can't get server address: syserr = No buffer space available SIGNAL 20 wait4(0xd03,0xbfbff088,0x0,0x0) = 3331 (0xd03) exit(0x1) process exit, rval = 256 A different tactic could be that I pull a m_devget() or some other mbuf creation stunt and copy the data from the uio into the mbuf. Do I have to clear the mbuf and/or uio after passing that mbuf to sosend? Any pointers (even to some docs, though I've done heavy googling) or hints would be greatly appreciated. DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 31 22:26:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id C2BA337B421 for ; Mon, 31 Dec 2001 22:26:09 -0800 (PST) Received: (from dg@localhost) by root.com (8.11.2/8.11.2) id g016G1A56458; Mon, 31 Dec 2001 22:16:01 -0800 (PST) (envelope-from dg) Date: Mon, 31 Dec 2001 22:16:01 -0800 From: David Greenman To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD performing worse than Linux? Message-ID: <20011231221601.A54679@nexus.root.com> References: <200112312327.fBVNRt719835@whizzo.transsys.com> <200201010043.g010h0i36281@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201010043.g010h0i36281@apollo.backplane.com>; from dillon@apollo.backplane.com on Mon, Dec 31, 2001 at 04:43:00PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Yes, you are correct. There is no real reason for ssh to set > TCP_NODELAY on FreeBSD and, in fact, I believe it didn't used to. > We should just turn it off. Nagle + delayed acks don't really get along all that well, and often result in character echoes lagging .25-.5 seconds behind the keystrokes (due to round trip + 200ms). This really makes editing files and other interactive jobs rather painful. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com President, Download Technologies, Inc. - http://www.downloadtech.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 31 22:36:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id AEAA137B41F for ; Mon, 31 Dec 2001 22:36:32 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g016aLC37133; Mon, 31 Dec 2001 22:36:21 -0800 (PST) (envelope-from dillon) Date: Mon, 31 Dec 2001 22:36:21 -0800 (PST) From: Matthew Dillon Message-Id: <200201010636.g016aLC37133@apollo.backplane.com> To: David Greenman Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD performing worse than Linux? References: <200112312327.fBVNRt719835@whizzo.transsys.com> <200201010043.g010h0i36281@apollo.backplane.com> <20011231221601.A54679@nexus.root.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> TCP_NODELAY on FreeBSD and, in fact, I believe it didn't used to. :> We should just turn it off. : : Nagle + delayed acks don't really get along all that well, and often :result in character echoes lagging .25-.5 seconds behind the keystrokes (due :to round trip + 200ms). This really makes editing files and other interactive :jobs rather painful. : :-DG : :David Greenman I think that has been fixed. Try it. It doesn't lag for me. The turn-around echo of the keystroke should be pushed out instantly. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message