From owner-freebsd-chat Sun Aug 26 14:32:11 2001 Delivered-To: freebsd-chat@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 9A0E437B407 for ; Sun, 26 Aug 2001 14:32:08 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.135.64.Dial1.SanJose1.Level3.net [209.245.135.64]) by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id OAA18019; Sun, 26 Aug 2001 14:32:05 -0700 (PDT) Message-ID: <3B896B00.6E40731F@mindspring.com> Date: Sun, 26 Aug 2001 14:32:48 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brett Glass Cc: chat@FreeBSD.ORG Subject: Re: How is 4.4-RELEASE shaping up? References: <4.3.2.7.2.20010826110635.057b5ca0@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Brett Glass wrote: > I haven't been able to follow the progress of the 4.4 release candidates, > but after reading some of the postings on the -STABLE mailing list, I > wonder whether it'll be a good idea to upgrade production machines to > 4.4-RELEASE. What do folks think? Will this release be a good milestone? > Or will it pay to wait until 4.5, or at least a snapshot between 4.4 and > 4.5? Frank feedback on the strong and weak areas of 4.4 as it stands now > would be appreciated. We will be bringing in much of the 4.4-RELEASE into our embedded system, which is currently running 4.3-RELEASE, plus patches. However, we will _NOT_ be bringing in the mbuf code (we are running the more advanced code, from 5.x, which amounts to a back-port of about 5 files), and we will _NOT_ be bringing in the tcptempl removal: it causes a significant performance hit. My original complaint on it was the amount of memory that it too per, not the fact that it took any... it's also convenient for about six different stack performance enhancement technologies, all of which would like around 60 bytes to do their thing; instead, we will just allocate the 60 bytes, instead, using a page-filling "chain" allocator, so not a byte is wasted. There are several other changes we will _NOT_ be bringing in, as well (I've complained about them in other forums, after doing performance testing on them, and finding them lacking). If I could kill /dev/random easily, I'd do that too; I will probably get around to it eventually, since it's "entropy harvesting" hooks significantly and negatively impact interrupt overhead, and unless you take the hit, you "run out" of random numbers when using SSL/SSH, particularly immediatley after a reboot (e.g. right when you need them to remotely administer a system). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message