From owner-freebsd-net Sun Nov 28 12:27:15 1999 Delivered-To: freebsd-net@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 9F5C214F04 for ; Sun, 28 Nov 1999 12:27:09 -0800 (PST) (envelope-from aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id OAA04627 for freebsd-net@freebsd.org; Sun, 28 Nov 1999 14:27:08 -0600 (CST) Date: Sun, 28 Nov 1999 14:27:08 -0600 (CST) From: Mohit Aron Message-Id: <199911282027.OAA04627@cs.rice.edu> To: freebsd-net@freebsd.org Subject: interaction between Nagle's algorithm and TCP delayed ACKs Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, FreeBSD-2.2.6 had a macro called ACK_HACK in /sys/netinet/tcp_input.c that was effective in avoiding the undesirable interactions between the TCP Nagle's algorithm and the delayed ACKs. Basically, if the PUSH flag on a packet was set, this macro forced TCP to send an acknowledgment immediately. Since the PUSH flag is usually set on small packets that trigger Nagle's algorithm, this macro was effective. I checked the code for FreeBSD-3.3 and this macro is no longer there in /sys/netinet/tcp_input.c. Can this feature be re-added in later releases. In fact, I'd even like it to be turned on by default (it wasn't enabled in FreeBSD-2.2.6 by default). - Mohit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 28 15: 6:30 1999 Delivered-To: freebsd-net@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 8826114A2A for ; Sun, 28 Nov 1999 15:06:25 -0800 (PST) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id PAA24795; Sun, 28 Nov 1999 15:06:08 -0800 (PST) Message-Id: <199911282306.PAA24795@implode.root.com> To: Mohit Aron Cc: freebsd-net@FreeBSD.ORG Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs In-reply-to: Your message of "Sun, 28 Nov 1999 14:27:08 CST." <199911282027.OAA04627@cs.rice.edu> From: David Greenman Reply-To: dg@root.com Date: Sun, 28 Nov 1999 15:06:08 -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > FreeBSD-2.2.6 had a macro called ACK_HACK in /sys/netinet/tcp_input.c >that was effective in avoiding the undesirable interactions between the >TCP Nagle's algorithm and the delayed ACKs. Basically, if the PUSH flag >on a packet was set, this macro forced TCP to send an acknowledgment >immediately. Since the PUSH flag is usually set on small packets that trigger >Nagle's algorithm, this macro was effective. > >I checked the code for FreeBSD-3.3 and this macro is no longer there in >/sys/netinet/tcp_input.c. Can this feature be re-added in later releases. >In fact, I'd even like it to be turned on by default (it wasn't enabled in >FreeBSD-2.2.6 by default). I was the one who originally added it and then later removed it. I don't recall the reason I removed, except perhaps that I thought it wasn't being used by anyone and was also not something that should be optional. Probably not a bad idea to just make it the standard behavior. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 28 15:41:54 1999 Delivered-To: freebsd-net@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 2360415610 for ; Sun, 28 Nov 1999 15:41:50 -0800 (PST) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id PAA24893; Sun, 28 Nov 1999 15:41:48 -0800 (PST) Message-Id: <199911282341.PAA24893@implode.root.com> To: Mohit Aron Cc: freebsd-net@FreeBSD.ORG Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs In-reply-to: Your message of "Sun, 28 Nov 1999 14:27:08 CST." <199911282027.OAA04627@cs.rice.edu> From: David Greenman Reply-To: dg@root.com Date: Sun, 28 Nov 1999 15:41:48 -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > FreeBSD-2.2.6 had a macro called ACK_HACK in /sys/netinet/tcp_input.c >that was effective in avoiding the undesirable interactions between the >TCP Nagle's algorithm and the delayed ACKs. Basically, if the PUSH flag I just remembered why I removed it: One of the original purposes behind delayed ACKs was to delay the ACK so that it could be combined with the character echo in the telnet/login session case. Since PUSH will usually always be set by the sender when he's typing along, the above TCP_ACK_HACK would effectively disable delayed ACKs for the case that they were created for in the first place - to aggregate the ACK with the character echo. At the time I thought that this was a bad idea. I've since changed my opinion on the usefulness of delayed ACKs, however, and now think that they cause more problems then they solve and should be shut off by default (i.e. change net.inet.tcp.delayed_ack default from 1 to 0)...which is what I do on all of the servers that I've built. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 28 16: 5:49 1999 Delivered-To: freebsd-net@freebsd.org Received: from pail.ircache.net (pail.scd.ucar.edu [128.117.28.5]) by hub.freebsd.org (Postfix) with ESMTP id 6927E153BF for ; Sun, 28 Nov 1999 16:05:46 -0800 (PST) (envelope-from rousskov@ircache.net) Received: from localhost (rousskov@localhost) by pail.ircache.net (8.9.2/8.8.7) with ESMTP id RAA12521; Sun, 28 Nov 1999 17:05:13 -0700 (MST) (envelope-from rousskov@ircache.net) Date: Sun, 28 Nov 1999 17:05:13 -0700 (MST) From: Alex Rousskov To: David Greenman Cc: freebsd-net@FreeBSD.ORG Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs In-Reply-To: <199911282341.PAA24893@implode.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 28 Nov 1999, David Greenman wrote: > ... I've since changed my opinion > on the usefulness of delayed ACKs, however, and now think that they cause > more problems then they solve and should be shut off by default (i.e. change > net.inet.tcp.delayed_ack default from 1 to 0)...which is what I do on all > of the servers that I've built. Interesting! In our benchmarking environment we disable delayed ACKs as well. However, we were recently attacked by several vendors of the products we test. The vendors claim that turning delayed ACKs off produces too many ACK packets compared to a "real" TCP stream they observe in practice. Those "extra" ACKs might overflow their NICs/adapters when they are close to their performance capacity. The vendors also say that Linux TCP stack does not emit that many ACKs while not suffering from extra delays that default FreeBSD settings create (i.e., Linux folks allegedly found some magic "golden middle" that satisfies everybody). We have not verified these claims. Now we are considering enabling delayed ACKs (the default) to stop vendor complains. Would be great if anybody out there could provide an "independent" statistics (or at least an opinion) on the real TCP streams and the presence of delayed ACKs in other TCP stacks. Any comments? Thanks, Alex. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 29 6:10:26 1999 Delivered-To: freebsd-net@freebsd.org Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110]) by hub.freebsd.org (Postfix) with ESMTP id 8E83414C26 for ; Mon, 29 Nov 1999 06:10:22 -0800 (PST) (envelope-from cristalg@rc.bel.alcatel.be) Received: from btmq9s.rc.bel.alcatel.be (btmq9s.rc.bel.alcatel.be [138.203.65.182]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id PAA20387 for ; Mon, 29 Nov 1999 15:10:15 +0100 (MET) Received: from btmq9z.rc.bel.alcatel.be (btmq9z [138.203.65.192]) by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8) with ESMTP id PAA05420 for ; Mon, 29 Nov 1999 15:12:00 +0100 (MET) Subject: Check_Subject Received: from btmq9z.rc.bel.alcatel.be (btmq9z.rc.bel.alcatel.be [138.203.65.192]) by btmq9z.rc.bel.alcatel.be (8.8.8+Sun/8.8.8) with SMTP id PAA08703 for ; Mon, 29 Nov 1999 15:10:13 +0100 (MET) Message-Id: <199911291410.PAA08703@btmq9z.rc.bel.alcatel.be> Date: Mon, 29 Nov 1999 15:10:13 +0100 (MET) From: Cristallo Geoffrey Reply-To: Cristallo Geoffrey To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: bRm3dUfFK9ysbUmFIMFjzQ== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org hi, I need information about the output queue of each interface. This info is in the ifnet structure (in struct ifnet: struct ifqueue if_snd). How can I obtain this from user space ? If i do a sysctl for the interface list (NET_RT_IFLIST), it returns a list of struct if_msghdr, but this struct does not contain the struct ifqueue. many thanks in advance Geoffrey Cristallo mailto:cristalg@rc.bel.alcatel.be To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 29 9:58:23 1999 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id EC436152A0 for ; Mon, 29 Nov 1999 09:58:21 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id MAA35330; Mon, 29 Nov 1999 12:58:15 -0500 (EST) (envelope-from wollman) Date: Mon, 29 Nov 1999 12:58:15 -0500 (EST) From: Garrett Wollman Message-Id: <199911291758.MAA35330@khavrinen.lcs.mit.edu> To: Cristallo Geoffrey Cc: freebsd-net@FreeBSD.ORG Subject: Check_Subject In-Reply-To: <199911291410.PAA08703@btmq9z.rc.bel.alcatel.be> References: <199911291410.PAA08703@btmq9z.rc.bel.alcatel.be> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > I need information about the output queue of each interface. This > info is in the ifnet structure (in struct ifnet: struct ifqueue > if_snd). How can I obtain this from user space ? man 3 kvm -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 29 14:50:18 1999 Delivered-To: freebsd-net@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id B19421548D for ; Mon, 29 Nov 1999 14:50:15 -0800 (PST) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id OAA27538; Mon, 29 Nov 1999 14:49:36 -0800 (PST) Message-Id: <199911292249.OAA27538@implode.root.com> To: Alex Rousskov Cc: freebsd-net@FreeBSD.ORG Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs In-reply-to: Your message of "Sun, 28 Nov 1999 17:05:13 MST." From: David Greenman Reply-To: dg@root.com Date: Mon, 29 Nov 1999 14:49:36 -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >On Sun, 28 Nov 1999, David Greenman wrote: > >> ... I've since changed my opinion >> on the usefulness of delayed ACKs, however, and now think that they cause >> more problems then they solve and should be shut off by default (i.e. change >> net.inet.tcp.delayed_ack default from 1 to 0)...which is what I do on all >> of the servers that I've built. > >Interesting! In our benchmarking environment we disable delayed ACKs as >well. However, we were recently attacked by several vendors of the >products we test. The vendors claim that turning delayed ACKs off >produces too many ACK packets compared to a "real" TCP stream they >observe in practice. Those "extra" ACKs might overflow their >NICs/adapters when they are close to their performance capacity. That sounds very lame. >The vendors also say that Linux TCP stack does not emit that many ACKs >while not suffering from extra delays that default FreeBSD settings >create (i.e., Linux folks allegedly found some magic "golden middle" >that satisfies everybody). We have not verified these claims. It could be that delayed ACKs aren't delayed as long in Linux. We could do the same thing in FreeBSD by shortening it down to say 10ms or something. That would allow the ACKs to be aggregrated with the character echoes while still keeping the response time fairly quick. Delayed ACKs are evil in other ways, however. For one thing they add noise and additional delay to the estimated RTT. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 29 15:53:57 1999 Delivered-To: freebsd-net@freebsd.org Received: from mullian.ee.mu.OZ.AU (mullian.ee.mu.OZ.AU [128.250.80.1]) by hub.freebsd.org (Postfix) with ESMTP id 80AD915592 for ; Mon, 29 Nov 1999 15:53:24 -0800 (PST) (envelope-from m.summerfield@ee.mu.oz.au) Received: from m-summerfield.ee.mu.oz.au (m-summerfield.ee.mu.OZ.AU [128.250.79.188]) by mullian.ee.mu.OZ.AU (8.9.1a/8.9.1) with SMTP id KAA02746; Tue, 30 Nov 1999 10:53:01 +1100 (EST) Message-Id: <199911292353.KAA02746@mullian.ee.mu.OZ.AU> X-Sender: summer@mullian.ee.mu.oz.au X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 30 Nov 1999 10:54:11 +1100 To: dg@root.com, Alex Rousskov From: Mark Summerfield Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs Cc: freebsd-net@FreeBSD.ORG In-Reply-To: <199911292249.OAA27538@implode.root.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 14:49 29/11/99 -0800, David Greenman wrote: >>Interesting! In our benchmarking environment we disable delayed ACKs as >>well. However, we were recently attacked by several vendors of the >>products we test. The vendors claim that turning delayed ACKs off >>produces too many ACK packets compared to a "real" TCP stream they >>observe in practice. Those "extra" ACKs might overflow their >>NICs/adapters when they are close to their performance capacity. > > That sounds very lame. It *is* very lame. If you want an authority to quote, how about John Nagle? Earlier this year there was one of the periodic mild flame-fests that erupt in comp.protocols.tcp-ip when someone seeking improved performance suggests that the Nagle algorithm is a liability. The discussion, as archived on deja.com (search for the subject "Turning off Nagles [sic] algorithm") contains 87 posts, of which the most succinct and informative is the single contribution from John Nagle himself. It can be found at http://x32.deja.com/=dnc/getdoc.xp?AN=477899304 . You can read the full text for yourself, but to summarise: 1) The thing that bites people is the nasty interaction that can occur between delayed ACKs and Nagle. 2) This happened because the two algorithms were developed independently and contemporaneously -- i.e. Nagle developed his algorithm on a network which did not have delayed ACKs. 3) Delayed ACKs are a nasty hack which are unnecessary, and John Nagle would like to see them removed from the TCP spec. 4) Nonetheless, if you do see poor performance due to the interaction, it does mean that your application is probably not well-designed, and you *should* be able to fix it with some judicious modification to the code. >>The vendors also say that Linux TCP stack does not emit that many ACKs >>while not suffering from extra delays that default FreeBSD settings >>create (i.e., Linux folks allegedly found some magic "golden middle" >>that satisfies everybody). We have not verified these claims. > > It could be that delayed ACKs aren't delayed as long in Linux. We could do >the same thing in FreeBSD by shortening it down to say 10ms or something. The host requirements RFC (1122) says that TCP SHOULD implement a delayed ACK of less than 500ms in duration. It is therefore perfectly legal to reduce it to 10ms. It's also legal not to do it. You might ask your vendors why their products can't handle perfectly legal behaviour, if they claim this is a problem. Perhaps you are exposing them to "worst case" conditions, but even so, Nagle alone should be sufficient to prevent congestion collapse unless the vendors' equipment is brain-damaged (and you'd think they'd want to know if it is?!) Mark ---- Dr. Mark Summerfield Australian Photonics Cooperative Research Centre Photonics Research Laboratory Dept. of Electrical and Electronic Engineering The University of Melbourne Parkville, 3052 AUSTRALIA Phone: +61 3 9344 7419 Fax: +61 3 9344 6678 Email: m.summerfield@ieee.org WWW: http://www.ee.mu.oz.au/staff/summer/index.htm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 29 16:36:26 1999 Delivered-To: freebsd-net@freebsd.org Received: from netcom.com (netcom4.netcom.com [199.183.9.104]) by hub.freebsd.org (Postfix) with ESMTP id 7B4C515503 for ; Mon, 29 Nov 1999 16:36:18 -0800 (PST) (envelope-from stanb@netcom.com) Received: (from stanb@localhost) by netcom.com (8.9.3/8.9.3) id QAA02441 for freebsd-net@FreeBSD.ORG; Mon, 29 Nov 1999 16:36:16 -0800 (PST) From: Stan Brown Message-Id: <199911300036.QAA02441@netcom.com> Subject: doain name registration? and DNS services? To: freebsd-net@FreeBSD.ORG Date: Mon, 29 Nov 1999 19:34:55 -0500 (EST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In an effort to be able to continue to use the fine FreeBSD mailing lists, it appears tha I will have to establishh my own domain name, since the FreeBSD mail hub now does reverse DNS lookups. Has anyone done this? Any sugsetionsas to the cheapest way to do this? I am conected to the internet via a cablemodem, and have a fixed IP address. Hopefully this will make it possible? -- Stan Brown stanb@netcom.com 404-996-6955 Factory Automation Systems Atlanta Ga. -- Look, look, see Windows 95. Buy, lemmings, buy! Pay no attention to that cliff ahead... Henry Spencer (c) 1998 Stan Brown. Redistribution via the Microsoft Network is prohibited. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 29 17: 4:40 1999 Delivered-To: freebsd-net@freebsd.org Received: from pail.ircache.net (pail.scd.ucar.edu [128.117.28.5]) by hub.freebsd.org (Postfix) with ESMTP id EFA021563A for ; Mon, 29 Nov 1999 17:04:36 -0800 (PST) (envelope-from rousskov@ircache.net) Received: from localhost (rousskov@localhost) by pail.ircache.net (8.9.2/8.8.7) with ESMTP id SAA18923; Mon, 29 Nov 1999 18:03:59 -0700 (MST) (envelope-from rousskov@ircache.net) Date: Mon, 29 Nov 1999 18:03:59 -0700 (MST) From: Alex Rousskov To: Mark Summerfield Cc: freebsd-net@FreeBSD.ORG Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mark, Thanks for a great overview! We will certainly use your opinion and the sources you quote in our discussions with the vendors. I should mention that in our tests we disable Nagle as well. IIRC, the original motivation for disabling Nagle algorithm was, again, avoiding extra delays, especially on persistent HTTP connections. A single persistent connection is limited to about 5 requests per second with Nagle enabled due to 200msec delays (recall that HTTP requests are usually small).. Out ultimate goal is to simulate a realistic TCP stream with FreeBSD (within the performance constrains that we have). Based on David Greenman's and your opinion, delayed ACKs should be disabled (and that is our current setting). Thanks again, Alex. On Tue, 30 Nov 1999, Mark Summerfield wrote: > If you want an authority to quote, how about John Nagle? Earlier this > year there was one of the periodic mild flame-fests that erupt in > comp.protocols.tcp-ip when someone seeking improved performance > suggests that the Nagle algorithm is a liability. The discussion, > as archived on deja.com (search for the subject "Turning off Nagles [sic] > algorithm") contains 87 posts, of which the most succinct and informative > is the single contribution from John Nagle himself. > > It can be found at http://x32.deja.com/=dnc/getdoc.xp?AN=477899304 . > > You can read the full text for yourself, but to summarise: > > 1) The thing that bites people is the nasty interaction that can occur > between delayed ACKs and Nagle. > 2) This happened because the two algorithms were developed independently > and contemporaneously -- i.e. Nagle developed his algorithm on a network > which did not have delayed ACKs. > 3) Delayed ACKs are a nasty hack which are unnecessary, and John Nagle would > like to see them removed from the TCP spec. > 4) Nonetheless, if you do see poor performance due to the interaction, it > does mean that your application is probably not well-designed, and you > *should* be able to fix it with some judicious modification to the > code. > > The host requirements RFC (1122) says that TCP SHOULD implement a delayed ACK > of less than 500ms in duration. It is therefore perfectly legal to reduce > it to 10ms. It's also legal not to do it. You might ask your vendors > why their products can't handle perfectly legal behaviour, if they claim > this is a problem. Perhaps you are exposing them to "worst case" conditions, > but even so, Nagle alone should be sufficient to prevent congestion > collapse unless the vendors' equipment is brain-damaged (and you'd think > they'd want to know if it is?!) > > Mark > ---- > Dr. Mark Summerfield > Australian Photonics Cooperative Research Centre > Photonics Research Laboratory > Dept. of Electrical and Electronic Engineering > The University of Melbourne > Parkville, 3052 AUSTRALIA > Phone: +61 3 9344 7419 > Fax: +61 3 9344 6678 > Email: m.summerfield@ieee.org > WWW: http://www.ee.mu.oz.au/staff/summer/index.htm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 29 17:16:16 1999 Delivered-To: freebsd-net@freebsd.org Received: from c99946-a.spokn1.wa.home.com (c99946-a.spokn1.wa.home.com [24.1.30.98]) by hub.freebsd.org (Postfix) with ESMTP id 64F79154A1 for ; Mon, 29 Nov 1999 17:16:11 -0800 (PST) (envelope-from ted@stargate.org) Received: from localhost (ted@localhost) by c99946-a.spokn1.wa.home.com (8.9.3/8.9.3) with ESMTP id VAA18841; Mon, 29 Nov 1999 21:02:18 -0800 Date: Mon, 29 Nov 1999 21:02:18 -0800 (PST) From: "T.D. Brace" To: Stan Brown Cc: freebsd-net@FreeBSD.ORG Subject: Re: doain name registration? and DNS services? In-Reply-To: <199911300036.QAA02441@netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If you are connected via cablemodem, your cable modem provider will need to update their dns in order for reverse lookup to work. hth. On Mon, 29 Nov 1999, Stan Brown wrote: > In an effort to be able to continue to use the fine FreeBSD mailing > lists, it appears tha I will have to establishh my own domain name, > since the FreeBSD mail hub now does reverse DNS lookups. > > Has anyone done this? Any sugsetionsas to the cheapest way to do this? > > I am conected to the internet via a cablemodem, and have a fixed IP > address. Hopefully this will make it possible? > > > -- > Stan Brown stanb@netcom.com 404-996-6955 > Factory Automation Systems > Atlanta Ga. > -- > Look, look, see Windows 95. Buy, lemmings, buy! > Pay no attention to that cliff ahead... Henry Spencer > (c) 1998 Stan Brown. Redistribution via the Microsoft Network is prohibited. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 29 17:38:42 1999 Delivered-To: freebsd-net@freebsd.org Received: from mullian.ee.mu.OZ.AU (mullian.ee.mu.OZ.AU [128.250.80.1]) by hub.freebsd.org (Postfix) with ESMTP id 20CCA15667 for ; Mon, 29 Nov 1999 17:35:50 -0800 (PST) (envelope-from m.summerfield@ee.mu.oz.au) Received: from m-summerfield.ee.mu.oz.au (m-summerfield.ee.mu.OZ.AU [128.250.79.188]) by mullian.ee.mu.OZ.AU (8.9.1a/8.9.1) with SMTP id MAA10058; Tue, 30 Nov 1999 12:35:37 +1100 (EST) Message-Id: <199911300135.MAA10058@mullian.ee.mu.OZ.AU> X-Sender: summer@mullian.ee.mu.oz.au X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 30 Nov 1999 12:36:47 +1100 To: Alex Rousskov From: Mark Summerfield Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs Cc: freebsd-net@FreeBSD.ORG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 18:03 29/11/99 -0700, Alex Rousskov wrote: >I should mention that in our tests we disable Nagle as well. IIRC, the >original motivation for disabling Nagle algorithm was, again, avoiding >extra delays, especially on persistent HTTP connections. A single >persistent connection is limited to about 5 requests per second with >Nagle enabled due to 200msec delays (recall that HTTP requests are >usually small).. Well, if you're going to quote my opinion, I want to make it clear that I'm opposed to the blanket disabling of Nagle by default -- that's what TCP_NODELAY is there for (ideally to be used only in those applications that really need it, in the opinion of well-informed programmers - hah!) As the newsgroup thread I referenced before shows, there is some debate regarding the need for Nagle. My opinion is that those opposed to it do not fully understand what it is for, and its impact on the NETWORK (as opposed to individual apps). I said in that thread (in a posting entitled "We need Internet police" http://x21.deja.com/=dnc/getdoc.xp?AN=475043248): "It does seem to me that the whole debate is the result of people having completely different views of what's important. On the one hand, the pro-Nagle lobby make the very valid point that Nagle is designed to avoid the kind of congestion problems that can occur if large amounts of data are sent in lots of small packets instead of a smaller number of large packets. The anti-Nagle lobby contends that in practice there are many situations in which certain applications inherently generate small transactions over TCP which are going to get sent in small packets anyway, whether they go immediately or after a "Nagle-delay" and which are therefore taking a pointless performance hit. "The solution is *not* to have Nagle disabled by default, because then many badly-designed or implemented applications may just congest the network, and make life more miserable for the rest of us." I went on to propose a fairly draconian solution (which was really just a modified version of what's actually proposed for networks -- e.g. ATM -- which must maintain "real" quality-of-service guarantees). However, my opinion is that if everyone disabled Nagle by default, the Internet (or parts of it) would be at risk of regular congestion collapse. The fact that this does not happen suggests that Nagle is generally not disabled by default. I have no idea how much traffic is generated by applications that do set TCP_NODELAY (or do the equivalent). RFC1122 says that Nagle SHOULD be implemented, and that where it is, it MUST be possible for applications to selectively turn it off. >Out ultimate goal is to simulate a realistic TCP stream with FreeBSD >(within the performance constrains that we have). Based on David >Greenman's and your opinion, delayed ACKs should be disabled (and that >is our current setting). Depends what you mean by "realistic" -- perhaps we have been a bit unfair on your vendors. If they are telling you that the distribution of ACKs they are seeing in your simulated environment is different from that observed in the wild, maybe you should listen to them? If, on the other hand, you are telling them that their equipment performs poorly in the presence of entirely plausible (and possibly representative) traffic, maybe they should be listening to you? Maybe both? If you want to be sure that your traffic is "realistic" you will need actual measured statistics from those parts of the Internet in which your vendors' equipment is used, for comparison. Otherwise you're just making stuff up ;-) Mark ---- Dr. Mark Summerfield Australian Photonics Cooperative Research Centre Photonics Research Laboratory Dept. of Electrical and Electronic Engineering The University of Melbourne Parkville, 3052 AUSTRALIA Phone: +61 3 9344 7419 Fax: +61 3 9344 6678 Email: m.summerfield@ieee.org WWW: http://www.ee.mu.oz.au/staff/summer/index.htm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 30 15:52:17 1999 Delivered-To: freebsd-net@freebsd.org Received: from awfulhak.org (dynamic-3.max4-du-ws.dialnetwork.pavilion.co.uk [212.74.9.131]) by hub.freebsd.org (Postfix) with ESMTP id 39BBA159D9 for ; Tue, 30 Nov 1999 15:52:07 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by awfulhak.org (8.9.3/8.9.3) with ESMTP id XAA02195; Tue, 30 Nov 1999 23:48:55 GMT (envelope-from brian@lan.awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost.lan.Awfulhak.org [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id HAA19330; Tue, 30 Nov 1999 07:49:15 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <199911300749.HAA19330@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.0 09/18/1999 To: "T.D. Brace" Cc: Stan Brown , freebsd-net@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: doain name registration? and DNS services? In-Reply-To: Message from "T.D. Brace" of "Mon, 29 Nov 1999 21:02:18 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Nov 1999 07:49:13 +0000 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > If you are connected via cablemodem, your cable modem provider will need > to update their dns in order for reverse lookup to work. ^^^^^^ You mean fix. > hth. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 30 16:27: 7 1999 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 87E531561D for ; Tue, 30 Nov 1999 16:26:50 -0800 (PST) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id QAA34701; Tue, 30 Nov 1999 16:25:43 -0800 (PST) From: Archie Cobbs Message-Id: <199912010025.QAA34701@bubba.whistle.com> Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs In-Reply-To: <199911292249.OAA27538@implode.root.com> from David Greenman at "Nov 29, 1999 02:49:36 pm" To: dg@root.com Date: Tue, 30 Nov 1999 16:25:43 -0800 (PST) Cc: rousskov@ircache.net (Alex Rousskov), freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org David Greenman writes: > >The vendors also say that Linux TCP stack does not emit that many ACKs > >while not suffering from extra delays that default FreeBSD settings > >create (i.e., Linux folks allegedly found some magic "golden middle" > >that satisfies everybody). We have not verified these claims. > > It could be that delayed ACKs aren't delayed as long in Linux. We could do > the same thing in FreeBSD by shortening it down to say 10ms or something. That > would allow the ACKs to be aggregrated with the character echoes while still > keeping the response time fairly quick. Delayed ACKs are evil in other ways, > however. For one thing they add noise and additional delay to the estimated > RTT. Do the delayed ACK's have a fixed timeout, or is it proportional to the estimated RTT? It seems like in the former case, you're always going to find a situation where the timeout is too long. To avoid this the delayed ACK timeout should be some percentage of the estimated RTT. And as long as the ACK timeout is not much more than the variance in the estimated RTT, then how can you get into that much trouble with Nagle? Moreover, in practice, when a packet comes in there is often an immediate reply or no reply, so short timeouts shouldn't 'just miss out' too often (in effect, only if by coincidence). I'm curious because I just went through all this while implementing PPTP, which uses GRE and a similar RTT estimate, delayed ACK, etc. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 30 16:37:52 1999 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 6C64014D70 for ; Tue, 30 Nov 1999 16:37:43 -0800 (PST) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id QAA34742; Tue, 30 Nov 1999 16:37:40 -0800 (PST) From: Archie Cobbs Message-Id: <199912010037.QAA34742@bubba.whistle.com> Subject: Re: netgraph'd enet nics anyone? In-Reply-To: from Vern Nichols at "Nov 23, 1999 10:09:12 am" To: nichols@roundview.com (Vern Nichols) Date: Tue, 30 Nov 1999 16:37:40 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Vern Nichols writes: > I'm currenlty working on 3.2 with the netgraph 3.0 patches applied. I > see netgraph appears to be integrated into 4.0. Is it worth moving up > to 4.0 before I start getting too deep in netgraph? I would move up to 4.0 if possible because of the delay in MFC'ing changes and updates. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 30 17:26:28 1999 Delivered-To: freebsd-net@freebsd.org Received: from web3005.mail.yahoo.com (web3005.mail.yahoo.com [204.71.202.168]) by hub.freebsd.org (Postfix) with SMTP id 3A98314DEE for ; Tue, 30 Nov 1999 17:26:24 -0800 (PST) (envelope-from mark_morsi@yahoo.ca) Received: (qmail 2005 invoked by uid 60001); 1 Dec 1999 01:25:47 -0000 Message-ID: <19991201012547.2004.qmail@web3005.mail.yahoo.com> Received: from [206.47.244.61] by web3005.mail.yahoo.com; Tue, 30 Nov 1999 20:25:47 EST Date: Tue, 30 Nov 1999 20:25:47 -0500 (EST) From: Mark Morsi Subject: PPPoE problems To: freebsd-net@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In addition to PPPoE problems, my ISP (Sympatico) is having mail server problems. I think they are also on the MAPS RBL list too. This is the third time i've sent this message, as I don't think it made it through the first time. If this message shows up multiple times, please accept my apologies. With that said: I seem to be having problems establishing a connection to my ISP via PPPoE and was wondering (actually hoping) if anyone had any suggestions. My setup is as follows: FreeBSD version: 3.3-Stable (1999-11-16) PPP version: 1999-11-25 I'm using files from /sys/netgraph/* AND /sys/net/if_ethersubr.c from around 1999-11-27 below is the contents of /var/log/ppp.log (my real password & User id have been altered) To me it looks as though I get succesfuly authenticated by the ISP's server, but the whole thing fails in the next step when I get passed a host name (maybe it expects a IP address?) Any ideas would be appreciated. Mark. Nov 29 23:32:20 clunker ppp[415]: Phase: Using interface: tun0 Nov 29 23:32:20 clunker ppp[415]: Phase: deflink: Created in closed state Nov 29 23:32:20 clunker ppp[415]: tun0: Command: default: set timeout 60 Nov 29 23:32:20 clunker ppp[415]: tun0: Command: default: set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 Nov 29 23:32:20 clunker ppp[415]: tun0: Command: default: set cd 5 Nov 29 23:32:20 clunker ppp[415]: tun0: Command: default: enable PAP Nov 29 23:32:20 clunker ppp[415]: tun0: Command: default: add default HISADDR Nov 29 23:32:20 clunker ppp[415]: tun0: Command: default: set authname XXXXXX@sympatico.ca Nov 29 23:32:20 clunker ppp[415]: tun0: Command: default: set authkey ******** Nov 29 23:32:20 clunker ppp[415]: tun0: Phase: PPP Started (background mode). Nov 29 23:32:21 clunker ppp[415]: tun0: Phase: bundle: Establish Nov 29 23:32:21 clunker ppp[415]: tun0: Phase: deflink: closed -> opening Nov 29 23:32:21 clunker ppp[415]: tun0: Warning: deflink: Reducing MRU to 1492 Nov 29 23:32:21 clunker ppp[415]: tun0: Phase: deflink: Connected! Nov 29 23:32:21 clunker ppp[415]: tun0: Phase: deflink: opening -> dial Nov 29 23:32:21 clunker ppp[415]: tun0: Chat: deflink: Dial attempt 1 of 1 Nov 29 23:32:21 clunker ppp[415]: tun0: Phase: deflink: dial -> carrier Nov 29 23:32:23 clunker ppp[415]: tun0: Phase: Received NGM_PPPOE_SUCCESS (hook "tun0") Nov 29 23:32:23 clunker ppp[415]: tun0: Phase: deflink: carrier -> login Nov 29 23:32:23 clunker ppp[415]: tun0: Phase: deflink: login -> lcp Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: FSM: Using "deflink" as a transport Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: deflink: State change Initial --> Closed Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: deflink: State change Closed --> Stopped Nov 29 23:32:23 clunker ppp[415]: tun0: Physical: read Nov 29 23:32:23 clunker ppp[415]: tun0: Physical: c0 21 01 5a 00 12 01 04 05 d4 03 04 c0 23 05 06 .!.Z.........#.. Nov 29 23:32:23 clunker ppp[415]: tun0: Physical: 02 b4 8b 51 ...Q Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: deflink: RecvConfigReq(90) state = Stopped Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: MRU[4] 1492 Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: MAGICNUM[6] 0x02b48b51 Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: deflink: SendConfigReq(1) state = Stopped Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: ACFCOMP[2] Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: PROTOCOMP[2] Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: ACCMAP[6] 0x00000000 Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: MRU[4] 1492 Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: MAGICNUM[6] 0x54516074 Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: deflink: SendConfigAck(90) state = Stopped Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: MRU[4] 1492 Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: MAGICNUM[6] 0x02b48b51 Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: deflink: LayerStart Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: deflink: State change Stopped --> Ack-Sent Nov 29 23:32:23 clunker ppp[415]: tun0: Physical: write Nov 29 23:32:23 clunker ppp[415]: tun0: Physical: c0 21 01 01 00 1c 08 02 07 02 02 06 00 00 00 00 .!.............. Nov 29 23:32:23 clunker ppp[415]: tun0: Physical: 01 04 05 d4 05 06 54 51 60 74 03 04 c0 23 ......TQ`t...# Nov 29 23:32:23 clunker ppp[415]: tun0: Physical: write Nov 29 23:32:23 clunker ppp[415]: tun0: Physical: c0 21 02 5a 00 12 01 04 05 d4 03 04 c0 23 05 06 .!.Z.........#.. Nov 29 23:32:23 clunker ppp[415]: tun0: Physical: 02 b4 8b 51 ...Q Nov 29 23:32:23 clunker ppp[415]: tun0: Physical: read Nov 29 23:32:23 clunker ppp[415]: tun0: Physical: c0 21 04 01 00 0e 08 02 07 02 02 06 00 00 00 00 .!.............. Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: deflink: RecvConfigRej(1) state = Ack-Sent Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: ACFCOMP[2] Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: PROTOCOMP[2] Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: ACCMAP[6] 0x00000000 Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: deflink: SendConfigReq(2) state = Ack-Sent Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: MRU[4] 1492 Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: MAGICNUM[6] 0x54516074 Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Nov 29 23:32:23 clunker ppp[415]: tun0: Physical: write Nov 29 23:32:23 clunker ppp[415]: tun0: Physical: c0 21 01 02 00 12 01 04 05 d4 05 06 54 51 60 74 .!..........TQ`t Nov 29 23:32:23 clunker ppp[415]: tun0: Physical: 03 04 c0 23 ...# Nov 29 23:32:23 clunker ppp[415]: tun0: Physical: read Nov 29 23:32:23 clunker ppp[415]: tun0: Physical: c0 21 02 02 00 12 01 04 05 d4 05 06 54 51 60 74 .!..........TQ`t Nov 29 23:32:23 clunker ppp[415]: tun0: Physical: 03 04 c0 23 ...# Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: deflink: RecvConfigAck(2) state = Ack-Sent Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: deflink: State change Ack-Sent --> Opened Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: deflink: LayerUp Nov 29 23:32:23 clunker ppp[415]: tun0: Phase: bundle: Authenticate Nov 29 23:32:23 clunker ppp[415]: tun0: Phase: deflink: his = PAP, mine = PAP Nov 29 23:32:23 clunker ppp[415]: tun0: Phase: Pap Output: b1jyom14@sympatico.ca ******** Nov 29 23:32:23 clunker ppp[415]: tun0: Physical: write Nov 29 23:32:23 clunker ppp[415]: tun0: Physical: c0 23 01 01 00 23 15 62 31 6a 79 00 00 00 00 00 .#...#.XXXXXXX@ Nov 29 23:32:23 clunker ppp[415]: tun0: Physical: 73 79 6d 70 61 74 69 63 6f 2e 63 61 08 00 00 00 sympatico.ca.XXX Nov 29 23:32:23 clunker ppp[415]: tun0: Physical: 00 00 00 00 00 XXXX Nov 29 23:32:25 clunker ppp[415]: tun0: Physical: read Nov 29 23:32:25 clunker ppp[415]: tun0: Physical: c0 23 02 01 00 05 00 .#..... Nov 29 23:32:25 clunker ppp[415]: tun0: Phase: Pap Input: SUCCESS () Nov 29 23:32:25 clunker ppp[415]: tun0: Physical: read Nov 29 23:32:25 clunker ppp[415]: tun0: Physical: c0 23 01 01 00 22 0e 73 6d 73 32 2d 74 6f 72 6f .#...".sms2-toro Nov 29 23:32:25 clunker ppp[415]: tun0: Physical: 6e 74 6f 36 33 0e 5f 4e 6f 74 41 52 65 61 6c 50 nto63._NotARealP Nov 29 23:32:25 clunker ppp[415]: tun0: Physical: 61 73 73 5f ass_ Nov 29 23:32:25 clunker ppp[415]: tun0: Phase: Pap Input: REQUEST (sms2-toronto63) Nov 29 23:32:25 clunker ppp[415]: tun0: Phase: Pap Output: FAILURE Nov 29 23:32:25 clunker ppp[415]: tun0: LCP: deflink: LayerDown Nov 29 23:32:25 clunker ppp[415]: tun0: LCP: deflink: SendTerminateReq(3) state = Opened Nov 29 23:32:25 clunker ppp[415]: tun0: LCP: deflink: State change Opened --> Closing Nov 29 23:32:25 clunker ppp[415]: tun0: Physical: write Nov 29 23:32:25 clunker ppp[415]: tun0: Physical: c0 23 03 01 00 14 0f 4c 6f 67 69 6e 20 69 6e 63 .#.....Login inc Nov 29 23:32:25 clunker ppp[415]: tun0: Physical: 6f 72 72 65 63 74 orrect Nov 29 23:32:25 clunker ppp[415]: tun0: Physical: write Nov 29 23:32:25 clunker ppp[415]: tun0: Physical: c0 21 05 03 00 04 .!.... Nov 29 23:32:25 clunker ppp[415]: tun0: Physical: read Nov 29 23:32:25 clunker ppp[415]: tun0: Physical: c0 21 06 03 00 04 .!.... Nov 29 23:32:25 clunker ppp[415]: tun0: LCP: deflink: RecvTerminateAck(3) state = Closing Nov 29 23:32:25 clunker ppp[415]: tun0: LCP: deflink: LayerFinish Nov 29 23:32:25 clunker ppp[415]: tun0: LCP: deflink: State change Closing --> Closed Nov 29 23:32:25 clunker ppp[415]: tun0: LCP: deflink: State change Closed --> Initial Nov 29 23:32:25 clunker ppp[415]: tun0: Phase: deflink: Disconnected! Nov 29 23:32:25 clunker ppp[415]: tun0: Phase: deflink: lcp -> logout Nov 29 23:32:25 clunker ppp[415]: tun0: Phase: deflink: logout -> hangup Nov 29 23:32:25 clunker ppp[415]: tun0: Phase: deflink: Disconnected! Nov 29 23:32:25 clunker ppp[415]: tun0: Phase: deflink: Connect time: 4 secs: 105 octets in, 135 octets out Nov 29 23:32:25 clunker ppp[415]: tun0: Phase: total 60 bytes/sec, peak 40 bytes/sec on Mon Nov 29 23:32:25 1999 Nov 29 23:32:25 clunker ppp[415]: tun0: Phase: deflink: hangup -> closed Nov 29 23:32:25 clunker ppp[415]: tun0: Phase: bundle: Dead Nov 29 23:32:55 clunker ppp[415]: tun0: Phase: PPP Terminated (normal). _______________________________________________________ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 30 18:57:26 1999 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (prism.flugsvamp.com [208.139.222.230]) by hub.freebsd.org (Postfix) with ESMTP id 0CDFD15980 for ; Tue, 30 Nov 1999 18:57:23 -0800 (PST) (envelope-from jlemon@prism.flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id UAA66651; Tue, 30 Nov 1999 20:58:02 -0600 (CST) (envelope-from jlemon) Date: Tue, 30 Nov 1999 20:58:02 -0600 From: Jonathan Lemon To: freebsd-net@FreeBSD.ORG Cc: archie@whistle.com, dg@root.com, rousskov@ircache.net Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs Message-ID: <19991130205802.A66619@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Archie Cobbs writes: > David Greenman writes: > > >The vendors also say that Linux TCP stack does not emit that many ACKs > > >while not suffering from extra delays that default FreeBSD settings > > >create (i.e., Linux folks allegedly found some magic "golden middle" > > >that satisfies everybody). We have not verified these claims. > > > > It could be that delayed ACKs aren't delayed as long in Linux. We > > could do the same thing in FreeBSD by shortening it down to say 10ms > > or something. That would allow the ACKs to be aggregrated with the > > character echoes while still keeping the response time fairly quick. > > Delayed ACKs are evil in other ways, however. For one thing they add > > noise and additional delay to the estimated RTT. > > Do the delayed ACK's have a fixed timeout, or is it proportional to > the estimated RTT? It seems like in the former case, you're always > going to find a situation where the timeout is too long. To avoid > this the delayed ACK timeout should be some percentage of the > estimated RTT. Well, in -current, at least, the delack time is under a sysctl, so you can change it to anything you want. In -current, the time that the ACK is delayed is exactly this much (assuming no other traffic that it can be piggybacked on). On -stable, it uses a fixed 200ms timer, so the delay for a specific ACK can vary from 0 - 200 ms. Linux uses a "quick ack" timer at the beginning of the connection to coerce the other side to leave slow start quickly. This probably does wreak some havoc with RTT estimates, and I'm not convinced it's the right thing to do. A pronounced example of the delack problem is FTP transfers; after the data channel opens, information flows only one way. So on startup, the sender sends one packet (as allowed by it's congestion window), but the receiver delays its ACK in hopes that it can piggyback the ACK on some (nonexistent) data flowing back to the sender. So after the ftp data session starts and after the first packet is transmitted, absolutely nothing is happening on the network. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 30 20:48:51 1999 Delivered-To: freebsd-net@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 90B5814E4C for ; Tue, 30 Nov 1999 20:48:48 -0800 (PST) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id UAA01534; Tue, 30 Nov 1999 20:47:59 -0800 (PST) Message-Id: <199912010447.UAA01534@implode.root.com> To: Jonathan Lemon Cc: freebsd-net@FreeBSD.ORG Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs In-reply-to: Your message of "Tue, 30 Nov 1999 20:58:02 CST." <19991130205802.A66619@prism.flugsvamp.com> From: David Greenman Reply-To: dg@root.com Date: Tue, 30 Nov 1999 20:47:59 -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Archie Cobbs writes: >> David Greenman writes: >> > >The vendors also say that Linux TCP stack does not emit that many ACKs >> > >while not suffering from extra delays that default FreeBSD settings >> > >create (i.e., Linux folks allegedly found some magic "golden middle" >> > >that satisfies everybody). We have not verified these claims. >> > >> > It could be that delayed ACKs aren't delayed as long in Linux. We >> > could do the same thing in FreeBSD by shortening it down to say 10ms >> > or something. That would allow the ACKs to be aggregrated with the >> > character echoes while still keeping the response time fairly quick. >> > Delayed ACKs are evil in other ways, however. For one thing they add >> > noise and additional delay to the estimated RTT. >> >> Do the delayed ACK's have a fixed timeout, or is it proportional to >> the estimated RTT? It seems like in the former case, you're always >> going to find a situation where the timeout is too long. To avoid >> this the delayed ACK timeout should be some percentage of the >> estimated RTT. > >Well, in -current, at least, the delack time is under a sysctl, so you >can change it to anything you want. In -current, the time that the >ACK is delayed is exactly this much (assuming no other traffic that it >can be piggybacked on). On -stable, it uses a fixed 200ms timer, so >the delay for a specific ACK can vary from 0 - 200 ms. One thing that has changed in -current is the average delay. It used to be 100ms and it is now 200ms. We should at least change the default to be 100ms, and I think even much lower (see below). >Linux uses a "quick ack" timer at the beginning of the connection to >coerce the other side to leave slow start quickly. This probably does >wreak some havoc with RTT estimates, and I'm not convinced it's the >right thing to do. > >A pronounced example of the delack problem is FTP transfers; after the >data channel opens, information flows only one way. So on startup, the >sender sends one packet (as allowed by it's congestion window), but the >receiver delays its ACK in hopes that it can piggyback the ACK on some >(nonexistent) data flowing back to the sender. So after the ftp data >session starts and after the first packet is transmitted, absolutely >nothing is happening on the network. Agreed. The purpose of the delayed ACK is to give a process a chance to respond with something and thus piggyback the ACK. Computers these days are very fast and I see no good reason to not lower the delay to 20ms (more accurately, two clock ticks). I'd say 10ms (next clock tick) except that due to lack of timer resolution, we'd end up with 0-10ms with an average of 5ms, and I'd rather it was 10-20ms with an average of 15ms. In any case, this would seem to me to settle the issue about untimely delayed ACKs while preserving the ACK aggregation capability and also improving the accuracy of the RTT estimate. Note that prior to Jonathan's new tcp_timer code, lowering the timeout that low would have had serious CPU overhead problems on server systems, but this is no longer a significant concern. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 1 6:30:16 1999 Delivered-To: freebsd-net@freebsd.org Received: from hqsmtp.mks.com (hqsmtp.mks.com [198.73.192.3]) by hub.freebsd.org (Postfix) with ESMTP id 5574214FEE for ; Wed, 1 Dec 1999 06:30:13 -0800 (PST) (envelope-from djfiande@julian.uwo.ca) Received: from hqntexch.mks.com (hqntexch.mks.com [1.0.0.105]) by hqsmtp.mks.com (Postfix) with ESMTP id 5CBD95900E; Wed, 1 Dec 1999 09:24:19 -0500 (EST) Received: from pc-419.pc.mks.com ([1.0.3.163]) by hqntexch.mks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id W6LF5C5B; Wed, 1 Dec 1999 09:29:59 -0500 Date: Wed, 1 Dec 1999 09:29:59 -0500 (Eastern Standard Time) From: "David J. Fiander" To: Mark Morsi Cc: freebsd-net@FreeBSD.ORG Subject: Re: PPPoE problems In-Reply-To: <19991201012547.2004.qmail@web3005.mail.yahoo.com> Message-ID: X-X-Sender: djfiande@julian.uwo.ca MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 30 Nov 1999, Mark Morsi wrote: > I seem to be having problems establishing a connection to my ISP via PPPoE > and was wondering (actually hoping) if anyone had any suggestions. First, I'd like to thank you for telling me how to fix the problems I was having connecting. I am now fully connected to Sympatico from FreeBSD 3.3-release. I was not sending 'username@sympatico.ca', but just 'username' as my PAP authname. > Ack-Sent --> Opened > Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: deflink: LayerUp > Nov 29 23:32:23 clunker ppp[415]: tun0: Phase: bundle: Authenticate > Nov 29 23:32:23 clunker ppp[415]: tun0: Phase: deflink: his = PAP, mine = > PAP My trace says 'his = PAP, mine = none'. I'm willing to bet a small amount of money that you have 'enable pap' in your ppp.conf file, and your ppp is expecting sympatico to authenticate to you. Just change it to 'accept pap' and see what happens. - David -- David J. Fiander | Where is the wisdom we have lost in knowledge? Incipient Librarian | Where is the knowledge we have lost in | information? | - T.S. Eliot, 1934 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 1 8:43:25 1999 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (prism.flugsvamp.com [208.139.222.230]) by hub.freebsd.org (Postfix) with ESMTP id 9237214DCB for ; Wed, 1 Dec 1999 08:43:20 -0800 (PST) (envelope-from jlemon@prism.flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id KAA67534; Wed, 1 Dec 1999 10:43:05 -0600 (CST) (envelope-from jlemon) Date: Wed, 1 Dec 1999 10:43:05 -0600 From: Jonathan Lemon To: David Greenman Cc: freebsd-net@FreeBSD.ORG Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs Message-ID: <19991201104305.D67400@prism.flugsvamp.com> References: <19991130205802.A66619@prism.flugsvamp.com> <199912010447.UAA01534@implode.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <199912010447.UAA01534@implode.root.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Nov 30, 1999 at 08:47:59PM -0800, David Greenman wrote: > >Well, in -current, at least, the delack time is under a sysctl, so you > >can change it to anything you want. In -current, the time that the > >ACK is delayed is exactly this much (assuming no other traffic that it > >can be piggybacked on). On -stable, it uses a fixed 200ms timer, so > >the delay for a specific ACK can vary from 0 - 200 ms. > > One thing that has changed in -current is the average delay. It used to > be 100ms and it is now 200ms. We should at least change the default to be > 100ms, and I think even much lower (see below). [ snip ] > >A pronounced example of the delack problem is FTP transfers; after the > >data channel opens, information flows only one way. So on startup, the > >sender sends one packet (as allowed by it's congestion window), but the > >receiver delays its ACK in hopes that it can piggyback the ACK on some > >(nonexistent) data flowing back to the sender. So after the ftp data > >session starts and after the first packet is transmitted, absolutely > >nothing is happening on the network. > > Agreed. The purpose of the delayed ACK is to give a process a chance to > respond with something and thus piggyback the ACK. Computers these days are > very fast and I see no good reason to not lower the delay to 20ms (more > accurately, two clock ticks). I'd say 10ms (next clock tick) except that due > to lack of timer resolution, we'd end up with 0-10ms with an average of 5ms, > and I'd rather it was 10-20ms with an average of 15ms. In any case, this > would seem to me to settle the issue about untimely delayed ACKs while > preserving the ACK aggregation capability and also improving the accuracy > of the RTT estimate. Note that prior to Jonathan's new tcp_timer code, > lowering the timeout that low would have had serious CPU overhead problems > on server systems, but this is no longer a significant concern. > I agree that the value should probably be lowered to at least 100ms, as this was the statistical average of the previous implementation. However, I'm not sure that lowering it further will provide much of a benefit in some situations as opposed to just turning it off completely. The reason for this is that when you turn off delayed acks, then you get one ack for every incoming packet, while normally (with the delay), TCP will attempt to ack every other packet. Now, if the delayed ack time is reduced to a value which is smaller than the spacing between the incoming packets, you still get one ACK per segment, but it is delayed, probably causing an inflated RTT estimate. As an example, I ftp'd a file from the WC server. The incoming inter-packet packet spacing that I normally see is roughly 35ms. When I lower the delayed ack timer to 20ms, this causes an ack to be sent for each segment, but which is delayed 20ms. So in this particular situation, we lose, as there is neither any ACK aggregation nor a lower RTT. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 1 16:34:41 1999 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 4D58115034 for ; Wed, 1 Dec 1999 16:34:38 -0800 (PST) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id QAA45401; Wed, 1 Dec 1999 16:32:05 -0800 (PST) From: Archie Cobbs Message-Id: <199912020032.QAA45401@bubba.whistle.com> Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs In-Reply-To: <19991201104305.D67400@prism.flugsvamp.com> from Jonathan Lemon at "Dec 1, 1999 10:43:05 am" To: jlemon@flugsvamp.com (Jonathan Lemon) Date: Wed, 1 Dec 1999 16:32:05 -0800 (PST) Cc: dg@root.com (David Greenman), freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Does anyone else agree with my (mostly theoretical) claim that the delayed ACK time should not be a global constant, but rather somehow roughly proportional to the estimated RTT?? Imagine N years from now when FreeBSD machines run at 100000MHz over 10000Gbit links. Then 10ms is going to look pretty long, etc. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 1 18:24: 3 1999 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (prism.flugsvamp.com [208.139.222.230]) by hub.freebsd.org (Postfix) with ESMTP id EF32014A2B for ; Wed, 1 Dec 1999 18:24:01 -0800 (PST) (envelope-from jlemon@prism.flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id UAA68155; Wed, 1 Dec 1999 20:23:34 -0600 (CST) (envelope-from jlemon) Date: Wed, 1 Dec 1999 20:23:34 -0600 From: Jonathan Lemon To: Archie Cobbs Cc: David Greenman , freebsd-net@FreeBSD.ORG Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs Message-ID: <19991201202334.A68139@prism.flugsvamp.com> References: <19991201104305.D67400@prism.flugsvamp.com> <199912020032.QAA45401@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <199912020032.QAA45401@bubba.whistle.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Dec 01, 1999 at 04:32:05PM -0800, Archie Cobbs wrote: > Does anyone else agree with my (mostly theoretical) claim that > the delayed ACK time should not be a global constant, but rather > somehow roughly proportional to the estimated RTT?? In theory, I think that it sounds promising. I also suspect that an optimal delayed ack time may also be a function of the congestion window, but that's more of a feeling than a solid theory. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 1 21:19:20 1999 Delivered-To: freebsd-net@freebsd.org Received: from web3001.mail.yahoo.com (web3001.mail.yahoo.com [204.71.202.164]) by hub.freebsd.org (Postfix) with SMTP id F1B291506C for ; Wed, 1 Dec 1999 21:19:17 -0800 (PST) (envelope-from mark_morsi@yahoo.ca) Received: (qmail 17157 invoked by uid 60001); 2 Dec 1999 05:16:45 -0000 Message-ID: <19991202051645.17156.qmail@web3001.mail.yahoo.com> Received: from [206.47.244.61] by web3001.mail.yahoo.com; Thu, 02 Dec 1999 00:16:45 EST Date: Thu, 2 Dec 1999 00:16:45 -0500 (EST) From: Mark Morsi Subject: Re: PPPoE problems To: "David J. Fiander" Cc: freebsd-net@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Glad to here I could be of help. Also, thank you very much. Looks like 'accept pap' did the trick(!). In case it is of any help to anyone else, below is the contents of my ppp.conf file: -------------BEGIN ppp.conf-------------------------------- set device PPPoE:ed1 set log Error Alert Warning Phase Chat IPCP CCP tun command set dial set timeout 60 set ifaddr 0.0.0.0 set cd 5 enable dns accept PAP set speed sync add 0 0 HISADDR enable lqr Sympatico: set authname XXXXXXX@sympatico.ca set authkey XXXXXXX ----------END------------------------- -Mark --- "David J. Fiander" wrote: > On Tue, 30 Nov 1999, Mark Morsi wrote: > > > I seem to be having problems establishing a connection to my ISP via PPPoE > > and was wondering (actually hoping) if anyone had any suggestions. > > First, I'd like to thank you for telling me how to fix the > problems I was having connecting. I am now fully connected to > Sympatico from FreeBSD 3.3-release. I was not sending > 'username@sympatico.ca', but just 'username' as my PAP authname. > > > Ack-Sent --> Opened > > Nov 29 23:32:23 clunker ppp[415]: tun0: LCP: deflink: LayerUp > > Nov 29 23:32:23 clunker ppp[415]: tun0: Phase: bundle: Authenticate > > Nov 29 23:32:23 clunker ppp[415]: tun0: Phase: deflink: his = PAP, mine = > > PAP > > My trace says 'his = PAP, mine = none'. I'm willing to bet a > small amount of money that you have 'enable pap' in your ppp.conf > file, and your ppp is expecting sympatico to authenticate to you. > Just change it to 'accept pap' and see what happens. > > - David _______________________________________________________ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 3 6:37:53 1999 Delivered-To: freebsd-net@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id 180ED15196 for ; Fri, 3 Dec 1999 06:37:50 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id JAA89571; Fri, 3 Dec 1999 09:36:19 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14407.54627.227163.613498@trooper.velocet.net> Date: Fri, 3 Dec 1999 09:36:19 -0500 (EST) To: freebsd-net@freebsd.org Subject: de question. X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Under heavy use, my de devices (both on cards with a single de and on cards with 4 de's) will all give the following message de0: abnormal interrupt: transmit underflow (raising TX threshold to 96|256) de0: abnormal interrupt: transmit underflow (raising TX threshold to 128|512) de0: abnormal interrupt: transmit underflow (raising TX threshold to 160|1024) de0: abnormal interrupt: transmit underflow (switching to store-and-forward mode) this sounds to me like we're degrading to a less efficient mode. Is it desireable to have some different behaviour? What flow of events is causing this? Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message