Date: Sun, 12 Nov 1995 09:59:26 -0600 (CST) From: "Karl Denninger, MCSNet" <karl@mcs.com> To: current@freebsd.org Subject: Re: ISP state their FreeBSD concerns Message-ID: <m0tEeoZ-000IDUC@venus.mcs.com> In-Reply-To: <m0tEUdy-000J9mC@current> from "owner-freebsd-current@freebsd.org" at Nov 11, 95 09:07:00 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I have been having a lot of contact with various local ISPs (we seem > to have an excessive number of these guys in this area). All of them > are aware of FreeBSD, but almost universally there is a frame of mind > that says FreeBSD should be avoided. Hi guys. > Naturally, I quizzed them as to what brought them to that conclusion if the > reason wasn't something we can't fix like "Alphas rule, Intels SUCK", etc. > In general each had three to five comments/concerns that were at the > heart of their negative view. I'll comment on these things. > These are generally ordered with the highest concerns first: > > 1. A concern that FreeBSD tends to "bind" for brief periods when > loaded. Here is how it was described to me: You will be doing > something (like skimming news articles in trn or tin) that is > hitting the hard disk perhaps once every five seconds and you > are getting instant response. This is baloney. We run a *NEWS SERVER* here on FreeBSD, and I also have a general public machine online. Someone's got a bad, bad configuration problem if they're seeing this. > 2. A concern that disk I/O on large (4GB or bigger) hard disks or > large numbers of hard disks is not reliable, particularly on > systems with more than 32MB of RAM. If you use EISA or adapters (recommended anyway) this is a non-issue. The 1742A is completely stable under this environment. I understand PCI is as well. There *WAS* a bug in the dump utility that made it impossible to dump filesystems over 4G, but that has been corrected. Bad disks are bad disks, and will fail in mysterious ways on ANY OS. I've seen this "failure" on BSDI -- there are known bad disk drives which cause problems. Micropolis is particularly known for this. > 3. A concern about things in FreeBSD that impact INN performance, or > force them to compile INN special for FreeBSD. They are talking > about MMAP support. Don't use MMAP, and you'll be fine. BTW, FreeBSD-STABLE does run ok with MMAP defined, but it is *slower* with it on than off over time as RAM gets fragmented. > 4. A concern about problems related to filesystem stacks, such as > ISO9660 and DOS. (They may be talking about Samba, and not > the actual mounting of DOS filesystems.) No data one way or the other. I don't do this kind of thing here. > 5. Not at all obvious what system resources to increase for > large and/or heavily loaded systems, and what ratios of > parameter settings are best. This is a general BSD thing - either you understand the BSD system or you do not. Truth is, there isn't much (other than Mbuf clusters) that you usually want to tweak. We have a set of override parameters we use here for heavily loaded systems, and they are nearly identical for BSDI and FreeBSD. > 6. Multi-port serial support and even single-port serial support. No data. > 7. Concern that there is still a lot of "tinkering under the hood" in > FreeBSD in areas that aren't broadening the system as a whole. Huh? > 8. File creation (particularly directories) appears to be slow compared > to other BSD-like systems. They say the stats for INN and CNEWS > for articles processed per second are quite a bit lower than that > on some "other" systems. Wait until you try to actually *use* those other systems. FreeBSD holds up under a heavy multiprocess load MUCH better than BSDI. > 9. A concern that man pages don't stay formatted. They would rather > chew disk space than have newbies constantly reformatting 'ls' and > 'cat'. No big deal one way or the other; this is quibbling with ants. > 10. More support for high-end hardware. I put this last because > it is one of the harder things for FreeBSD to do much about > since hardware vendors don't always want to tell us the tricks > to making their hardware work. They aren't just talking about > plug-in cards. These guys are interested in multiple-processors, > things that make load scale nicely, extremely fast interconnects > between systems, shared disk farms, Video-delivery bandwidths, etc. > Having Support the latest whizzo video cards aren't a big deal to > them, but support for disk controllers, CPUs and network interfaces > are. This makes their priorities different in general from those > that the average FreeBSD user probably has. Most of us aren't > ready to pop down and buy a four-processor P6 system with 256Meg > of RAM and three 100Mbit network interfaces, but these guys are. Yes. That I agree with. The only other issue we have here is the nasty NFS-write problem that makes shared access to remote resources tricky at best. If *THAT* was fixed we would be running FreeBSD exclusively here. I've been using FreeBSD exclusively for news service for quite a while (some clients use NFS, others NNTP to read) and its been fine. What we have a problem with is using it for our web server and general user system farm; the small NFS writes that the httpds do to the log disks cause system lockups and hundreds of processes in a hung state. The problem is understood, but there is no immediate path to a fix from what I've been told. We also can't have general user systems that do this -- people *WILL* exploit that to crash the network once they know about it. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 803-MCS1] | 7 Chicagoland POPs, ISDN, 28.8, much more Fax: [+1 312 248-9865] | Email to "info@mcs.net" WWW: http://www.mcs.net ISDN - Get it here TODAY! | Home of Chicago's *Three STAR A* Clarinet feed!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0tEeoZ-000IDUC>