From owner-freebsd-hackers Wed Feb 2 10:57:42 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.nyct.net (bsd4.nyct.net [204.141.86.6]) by builder.freebsd.org (Postfix) with ESMTP id 1F545411C for ; Wed, 2 Feb 2000 10:57:40 -0800 (PST) Received: from bsd1.nyct.net (mbac@bsd1.nyct.net [204.141.86.3]) by mail.nyct.net (8.8.8/8.8.7) with ESMTP id NAA08480; Wed, 2 Feb 2000 13:54:23 -0500 (EST) (envelope-from mbac@nyct.net) Received: from localhost (mbac@localhost) by bsd1.nyct.net (8.8.8/8.9.3) with ESMTP id NAA18276; Wed, 2 Feb 2000 13:54:22 -0500 (EST) (envelope-from mbac@nyct.net) X-Authentication-Warning: bsd1.nyct.net: mbac owned process doing -bs Date: Wed, 2 Feb 2000 13:54:22 -0500 (EST) From: Michael Bacarella To: Geoff Buckingham Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Re/Fwd: freebsd specific search In-Reply-To: <20000202170822.A12031@chuggalug.clues.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > It's release structure means FreeBSD is a complete operating system (as > opposed to a kernel and one of several distributions) and machines are > maintainable and upgradable in production over long periods of time via > the STABLE branch. I can agree with you here, as our organization has benefitted from said features. Although we aren't having the most pleasant time going from 2.2.8-STABLE to a 3.3.4-STABLE ever since the elfining. But that's probably our own fault for letting some of them get so out of date. :) > The FreeBSD kernel internals seem to have consistantly scaled further than the > Linux kernel over the last few years (though linux has improved lots recently). > This isn't a problem in most production enviroments however in marginal > configurations it can be nasty. I had a very bad day six months ago attemting > to patch a linux kernel to have >2048 file descriptors. Useless Anecdote Warning: For some particular reason (I'll spare the details of what lead up to this) I ping -f'd a FreeBSD box from a Linux box. The FreeBSD box held up very well. Despite this, my coworker (who owns said box) put icmp limits in place to further lessen the load. This attack was barely noticable on a neighboring Linux machine. (In fact, I was so annoyed that it had such a meager effect that I went to several other machines and had them all join in on the ping -f'ing fun). I experimented with variable packet sizes but I never did quite get to lock down the Linux machine as badly as I could the FreeBSD. Maybe I was just equating dropped packets with increased cpu availability as a plus, whereas FreeBSD put more effort into replying to all of the requests. Anyway, coworker also modified his system to dedicate more memory to the mbuf pool as well as some other tweaks which may or may not have done anything. Frustrated with my inability to saturate his FreeBSD box, I switched my attack to UDP. It was a basic UDP packet flood which, evidently, should've justed pushed as many packets onto the wire as the physical medium would allow. My machine is a P166 whereas his is a dual PPro200. The packet flood rendered the machine useless as far as networks go within 10 seconds. He tried it (out of annoyance) on a Linux machine which barely showed signs of struggle. Then, out of curiousity he turned it towards his Indy running Irix (don't remember the version). The machine fell right off the network in less than 3 seconds. Not only that, but when the flood stopped, the machine still wouldn't come back. One week later, the machine is still dead, despite reboots. Hardware damage? Neat! We are both using fairly recent versions of our respective systems, but I don't claim that either of us configured them optimally. Ho hum. If you can find a moral to this story, let me know. :) -MB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message