Date: Sat, 11 Nov 95 21:07 WET From: owner-freebsd-current@freebsd.org To: current@freebsd.org Subject: ISP state their FreeBSD concerns Message-ID: <m0tEUdy-000J9mC@current>
next 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. 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've compiled a list of the "top ten" things that bug these guys that we should consider correcting, or perhaps improving the documentation to dispell a falsehood or explain-away a concern. It is also entirely possible that these people had exposure to older releases and that the problems that worry them no longer exist. These aren't my own opinions, so don't flame me if you don't agree with them. Nobody reading this should spread these "concerns" like an urban folklore or anything. Some of these things may have been resolved a long time ago or may never have been true. The people who specialize in these areas of the system who respond should be the people who you listen to for an authoritative answer. Ok? 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. Then something else starts up, like tind, and the hard disk is now extremely busy (it was practically idle before tind started). Now, your disk requests aren't getting through for some reason and trn/tin seems to be dead. After fifteen or twenty seconds, the single disk read from tin/trn finally gets through and the next news article or the next page finally appears on the screen. You continue getting reasonable response (under a second delays), for a minute or so, and then disk I/O seems to "bind" again. They say that almost any disk intensive process does this, even if it is Niced into the floor. Dump and tar are said to be very bad and showing this. As described, it sounds like a process scheduling problem. I think I have seen this occur on 2.0.5 and 2.1.0-SNAP1026, and this was on reasonably fast systems. They were talking about this over lines connected via networked terminal servers, but I have seen it on a one-user system sitting at the console so no network delays were involved. There was a lessor complaint of mystery panics and lockups but this only came from someone who played with 2.0.0. 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. There has been a lot of traffic in the mailing lists on the subject of big disk stability and functionality, but it usually seemed the problems were limited to certain combinations of drives and controllers. Even Walnut Creek stated they had hard disk troubles with certain brands earlier this year. Perhaps a FAQ of known good/bad combinations would solve this, ie Grand Prix + NCRs is good/bad/etc. 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. Although some have stated in the mailing lists that not using MMAP on FreeBSD doesn't have a penalty, these guys are almost universally convinced that not using MMAP defeats the purpose of all the RAM they bought or will yield slower performance than some other system, probably because on a lot of other operating systems this is very true. 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.) One of the ISO9660 issues is the one I reported last week where a plain user can easily break all mounted ISO9660 access and hang all processes that attempt to access the ISO filesystems. (We discovered this on one of the local ISPs archive server - they were not pleased.) These guys with lots of CD-ROMs mounted on their systems don't like the sound of that remaining broken for any period of time, particularly when it ripples to other systems via NFS. 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. Apparently SUN, SCO and even Linux have a lot of documentation in this area and FreeBSDs is limited, missing or not obvious. I know SCO used to have little tables that said "if you increase this, this other value should be probably increased according to this formula...". FreeBSD is different enough apparently that the rules of thumb for BSD 4.x aren't valid here. So documentation or the much-beamoned but absent "book" on FreeBSD. 6. Multi-port serial support and even single-port serial support. Seems they feel hardware flow control doesn't work or isn't enabled when it should be (or can't be) or both. This may actually be an issue with the 16550 drivers not setting silo depth to a reasonable level. Most of these guys use terminal servers for the actual users where these local serial ports are used for UPS, router control, serial printers, and other in-house controls. They complain of seeing problems with lost data outbound when flow control was in use, including during UUCP sessions. 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. They would rather have more compatibility (run Linux / SCO stuff), or even more native applications working rather than have somebodys new spiffy-internal-choclate-covered-paging-allocation-widget- thingy-that-has-no-trailing-whitespace-in-any-of-the-source-files, etc. There was a plea for longer periods of stability, ie don't feel FreeBSD has to have a "stable" version followed by an unstable one, just because the next "." number is even and someone did releases that way accidentally ten years ago. They point to Linux, where the core seems to be going through few changes (what about the "FT" guys?), or a purchased system (SUN/SCO) which sees a maintenance release that only alters a small percentage of the system each year. It is hard to argue this point as FreeBSD still struggles to get its 4.4lite issues completely cleaned up and major architectural changes are still pretty common. They also cry out against further changes to executable headers and password file formats. Changes made in these areas in the past are not popular to these guys as it requires far to much work to uprade accounts and such. They also don't like include files changing around too much, because FreeBSD doesn't provide ports for everything, and now code that used to compile may not just because someone made something "tidy". Changes like this in the name of POSIX are considered "stupid". Apparently POSIX isn't the Holy Grail it once was, particularly nowdays when you can just claim to be somewhat POSIX compliant (if viewed in a dim light on the 5th Tuesday of even years) and still get government contracts, as in Windows NT. POSIX just isn't a concern for ISPs. This whole area is a very religious issue (boy do I know) and there are many people volunteering on FreeBSD that are very good at working on particular things (like down in one specific part of the kernel) and getting them to work instead on DOSEMU or whatever the hot item is that month probably isn't practical (they may hate doing it and go away). On the other hand, I understand why these ISPs want a stable core. Tweaking a few microseconds out of memory allocation or something is not interesting or relevant to them since they can get a faster system by spending money on faster hardware. What they want from the software is robustness. Code speed is secondary. Also, apps, utilities and higher-level stuff that is flakey can be worked-around, but only if that stuff exists at all. 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. They say that file deletion seems to be a bit slower than BSDI, but not by much. I think they are talking 2.0.5 on this item, although one ISP was experimenting with 1026 SNAP. 9. A concern that man pages don't stay formatted. They would rather chew disk space than have newbies constantly reformatting 'ls' and 'cat'. They seem to want the old BSD-style arrangement where the first time a page is accessed it gets formatted and then that copy hangs around for future reference. This seemed like something they could fix themselves, but they responded that there are dozens of things like this that they would have to re-tweak everytime the system was updated. To me this didn't seem to important, but they mentioned it. Listen to your customer... 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. That was just about it. Again, take it as the concerns of some people who are using or would like to use FreeBSD, but see peril or limitations lurking that they are not willing to justify or risk. We can't convert everybody, but perhaps some of these issues are resolvable in the near future. Whew! Replies to current@freebsd.org please. :r sig
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0tEUdy-000J9mC>