Date: Sat, 11 Nov 1995 22:49:46 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: current@freebsd.org Subject: Re: ISP state their FreeBSD concerns Message-ID: <14486.816158986@time.cdrom.com> In-Reply-To: Your message of "Sat, 11 Nov 1995 21:07:00 %2B0700." <m0tEUdy-000J9mC@current>
next in thread | previous in thread | raw e-mail | index | archive | help
First off, I really have to wonder why Frank Durda went to what was obviously a considerable effort to be anonymous. The message had no signature and has been sent with a "From" of -current. C'mon Frank, we don't bite! Valid criticism always has a place in these lists and going out of your way to mask its origin only calls its validity into question unnecessarily. If I didn't know you were the only poster we've ever had from fw.ast.com, I might have thought this was something with a deeper political agenda from one of the other *BSD advocates and ignored it. That said, on to the points raised. > 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. Well, I'll certainly do my best to address these points, as I'm sure will others, but it does beg the question: How do we get the information back to them? If you're willing to act as a conduit, great, otherwise it'll be something of a wasted effort.. > 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 This one really needs some additional context. Suffice it to say that I've not experienced such behavior myself, and that's about all one can say with a fairly subjective report like this. That's not to say that it's totally lacking in validity, but consider what you yourself would do with a user report that "the system seemed slow." You'd naturally want to know how many processes were running, what version of the OS was being used, that kind of thing. In this instance you say that "something starts up" but you don't say what it is. Doing Tape I/O is something that's traditionally had a really bad impact on the performance of *every* UNIX variant I've ever seen, so if you're saying that the event in question is the operator starting a full dump from the console, well, "duh!" :-) No, I'm not flaming you or shooting the messenger, I'm just saying that there are always two categories of bug reports: Ones that give you enough information to go on that you actually have a hope of doing something about them and others more the nature of "Your system sucks, dudes! Make it better!" Issue #1 leans more towards the latter category. > 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 As an OS concern, this is untrue. There were some problems we had with Quantum Grand Prix drives going south in record numbers, but that's hardly something that the FreeBSD project has any control over. Tell your ISPs that not all drives are created equal and that they should find a winning combination before blaming the OS. Also mention that today's winning combo may not necessarily be tomorrow's. I had great luck with the GP drives until Quantum's quality control suddenly took an unexplained nose-dive. As in all things, you just gotta keep your ears open and be willing to investigate problems as thoroughly as possible before pointing any fingers - this stuff isn't that simple anymore! Also, the point should be made right here and now that, as a general rule, PCs hardware sucks dead gophers through miles of steel conduit. There's simply no comparison between a high-end workstation where all components are carefully matched by a single manufacturer and a bastard potpourri of components flung together from 46 different manufacturers in as many countries. If you can afford an SGI Challenge, BUY ONE I say! If you can't, or you're really addicted to having your own sources (one of our few distinct advantages), then go for a PC but go into it with your eyes fully open and wholly aware that you're about to tap-dance through a minefield. It is possible to get to the other side without being blown to bits, but you have to either be a really skilled dancer or a very lucky one. > 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. I think that this one has finally been addressed. It was broken for awhile, but if I'm not mistaken, the current port and OS combination uses mmap() to its fullest potential. If I'm wrong, someone here will no doubt correct me! :-) > 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. DOS filesystem support is broken. I would not be surprised to learn that the ISO9660 support was full of mice as well. Neither of these things will be fixed until either: 1. Somebody volunteers the time. 2. Writes me a check for enough money to pay someone to do it. It's a sad fact, but there you have it. One of the many downsides to trying to do this as a volunteer effort. Sometimes you just gotta say "Yeah, it's broken. Sorry!" as much as it pains you to do so. You might remind the ISPs that this is a FREE product and if they're actively interested in seeing it fixed, maybe they can donate some of the time of one of their programmers to try and fix it? I'm not being catty, this is genuinely one of those areas where some buy-in to the free software ethos is required by the end-user or things just don't move forward. They can either spend their money on BSD/OS, which may indeed be the very best decision to make and not something I can recommend either way, or they can think about what would happen if every ISP donated just one or two hours of programmer time a month to help fix things. Everybody would win, of course, but such advanced ways of thinking about their bottom line is not always easy to impart. > 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 True. See above.. :-) > 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. I use a standard serial port for a 115.2K ISDN connection and it works *great*, even better than a friend of mine who's using a Cisco for the purpose and looks enviously at my 10.5K/sec FTP transfer rates when he's only getting 7K. Not to say that this scales to hundreds of serial ports or anything, but it does work! > 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. It's hard to address this one without specifics, but I think that I can answer the larger concern here by pointing at our -stable and -current branches. We are sensitive to the needs of ISPs and the 2.1.x releases will be almost entirely for people like them. An approach that denied the rocket jockys a chance to advance the state-of-the-art would be equally flawed, and the best you can hope for is to give each interest group its own distinct playground. > 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 1. Linux is hardly unchanging, the FT effort being still mostly on the drawing board. 2. SCO doesn't change because it's been *moribund* for years! They started with a mediocre system and enshrined it. You won't get very far with me by holding them up as any sort of paragon to be emulated. I've done my time with SCO, from both ends of the picture, and all of it was unilaterally horrible. > 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. Well, it's going to take us some time to recover from the 4.4 merge and there's just no getting around it. See my previous comments about donations of time. > 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. It would help if they could percolate this down to some benchmarks that could be easily run by the people responsible for enhancing said performance. It's hard to speed up what you can't reproduce without being on-site with the ISP. > 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 Pilot error. They don't have the cat directories created. I also went to special trouble to make sure that these get created now by default, so this may also be a moot point. > 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 We're working on it, though if some people want to DONATE said high-end hardware to us so that we have a better chance of actually doing it, it would be a great help.w These people don't expect us to go out of pocket for $8K multi-CPU P6 machines now do they? Your ISPs seem to expect a lot if so! :-) > 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. They're all resolvable, but only if someone is willing to put in the time and/or money. I don't have a magic whip that will make all the volunteers work harder and faster, nor would I feel particularly inclined to use it even if I did. These people are putting in a lot of effort for free (yourself included) and they can only work so hard and so fast. Breaking through any additional barriers will require something more, though I'm still not exactly sure what it is. Money? Revitalizing FreeBSD, Inc. and making it a for-profit org that tries to inject some much-needed full time effort by paid programmers? I'm open to suggestions. Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14486.816158986>