jbn@wdl1.UUCP (01/16/85)
[Flame. Personal Opinion.]
4.2BSD is an experiment that seems to have failed. I am speaking only of
the kernel, not the rest of the system here. The much-touted ``fast file
system'' does not seem to deliver anything like the promised order of magnitude
performance improvement; in fact, overall 4.1BSD seems to slightly outperform
4.2. 4.2BSD has a huge resident kernel because of the large number of new and
in many cases little used features. There are far more bugs, security holes,
and general problems than with 4.1. The most significant addition was the
support for networking, which may be the last gasp of the networking-inside-
the-operating-system approach. (The state of the art is to use intelligent
networking cards; Excelan and Communications Machinery make cards that
provide IP/TCP services on an Ethernet; these cost about the same as ordinary
dumb Ethernet cards.) Other than networking, it is hard to point to a new
feature in the kernel that is really necessary and is in fact used by any
significant volume of software.
What are other's thoughts? Was all the trouble worth it? Should
further work proceed from a 4.1 base? A system V base? Or what?
John Naglejonab@sdcrdcf.UUCP (Jonathan Biggar) (01/17/85)
In article <182@wdl1.UUCP> jbn@wdl1.UUCP writes:
4.2BSD is an experiment that seems to have failed. I am speaking
only of the kernel, not the rest of the system here.
I think you are reading too much into the intentions of the designers of
4.2bsd. They never planned that 4.2 should be the "be-all and end-all" of
operating systems. If you want that, try VMS. :-) 4.2 is an experiment on
a very large scale. The features that have been added are things that users
have desired for many years. The experiment is to find out how useful these
features are.
The much-touted ``fast file system'' does not seem to deliver
anything like the promised order of magnitude performance
improvement; in fact, overall 4.1BSD seems to slightly outperform
4.2.
The "fast file system" really does give you up to an order of magnitude
improvement. I have seen the entire 4.2bsd kernel compile in about half the
time it took to compile the 4.2 kernel in single user mode. This
improvement comes entirely from the file system because the 4.2 kernel is
not smaller, and the C compiler is not faster. The speed is there, but
supporting other features slowed 4.2 down. There Ain't No Such Thing As A
Free Lunch. Thinks of what 4.2 would be like with a v7 file system.
(Shudder!)
4.2BSD has a huge resident kernel because of the large number of new
and in many cases little used features. There are far more bugs,
security holes, and general problems than with 4.1.
Again, you miss the point. Whenever you add new features, it takes time to
determine all of the reliability and security rammifications. 4.2 was late
anyway, would you have wanted Berkeley to wait 2-3 more years until they got
out "the last bug"? Comparing 4.2 with 4.1 is fallacious. 4.1bsd is the
result of quite a bit of fine tuning over time. The features of the system
did not change much from 3.0bsd to 4.1bsd except job control. Thus 4.1 is a
good balanced, well tuned system that did its job well. 4.2bsd added new
features that no other unix system had. It is going to take a while to tune
4.2 to deliver maximum performance. Some of this work has already been done
and hopefully will be released soon.
The most significant addition was the support for networking, which
may be the last gasp of the networking-inside- the-operating-system
approach. (The state of the art is to use intelligent networking
cards; Excelan and Communications Machinery make cards that provide
IP/TCP services on an Ethernet; these cost about the same as ordinary
dumb Ethernet cards.)
I differ with you here also. Intelligent networking cards in no way make
kernel networking support obsolete. I think if you look, you will find that
kernel packages to support these cards under 4.2bsd are available. This
actually shows how well Berkeley designed the network software. You can
offload the TCP processing to an auxillary processor without changing the
interface that a program sees at all.
Other than networking, it is hard to point to a new feature in the
kernel that is really necessary and is in fact used by any
significant volume of software.
Nothing is "really necessary". Do you want us all to go back to v6. (After
all, who needs files larger than a megabyte or two anyway?) Not much of the
software uses the new features because the software was written before the
new features were available. Eventually this may change but very little
user application code has actually changed since v6. Your definintion of
necessary only includes features that you think YOU might need.
What are other's thoughts? Was all the trouble worth it? Should
further work proceed from a 4.1 base? A system V base? Or what?
Well, you got my thoughts. I thing 4.2 is a good place to continue the work
from. After usng 4.2 for six months, I never want to go back to 4.1. There
are just too many features of 4.2 that I don't want to do without.
Considering that 4.2 is capable of emulating almost all of system V's
features, it is much easier to port programs from system V to 4.2 than vice
versa. Doesn't that seem to say that 4.2 provides a better general base for
the future development of UNIX?
Jon Biggar
{allegra,burdvax,cbosgd,hplabs,ihnp4,sdccsu3}!sdcrdcf!jonabrcd@opus.UUCP (Dick Dunn) (01/18/85)
> 4.2BSD is an experiment that seems to have failed. Careful here. An experiment which fails is one which produces no results or conclusions. I think that 4.2 has given us a wealth of information. Arguably it may have produced more information than code with long-term usefulness, but that's too early to tell. >...I am speaking only of > the kernel, not the rest of the system here. The much-touted ``fast file > system'' does not seem to deliver anything like the promised order of magnitude > performance improvement; in fact, overall 4.1BSD seems to slightly outperform > 4.2. The kernel work was the most ambitious, yet it seems to be the best of the work. There were mistakes in the kernel. My suspicion is that the fast file system actually has some significant improvements which are masked by some screwups and some changes elsewhere. There hasn't been a lot of real-world experience reported (outside of Berkeley, for the sake of non- biased views and replication) to judge by. Still, the kernel work is an both genuinely useful and an order of magnitude better than what went on in other areas--some of it best described as blind hacking that we'll be finding and fixing for the next couple of years at least. >...4.2BSD has a huge resident kernel because of the large number of new and > in many cases little used features... Software development goes in cycles. You try out a bunch of new ideas and cobble something together to see if the ideas will really work. Things get screwed up here and there; the code gets hacked over and balloons on you. Finally someone comes along, extracts the concepts from the mess, makes everything nice and orthogonal and small. Then the cycle starts over, trying new ideas on top of the old ones and making a mess (but learning a lot of new good stuff in the process). Personally, it seems like UNIX became generally known (in the V6/PWB/V7 time frame) when it was a fairly tight, clean system. 4.2 is out on the limb of a lot of experiments. It's time to admit that some of the ideas didn't work and the rest need cleaning up. Perhaps the biggest mistake made with 4.2 is the attempt to treat it, unmodified and not carefully debugged, as a production system. That mistake can hardly be laid completely at Berkeley's door, by the way. People who just port 4.2 to their machine without any tuneup, cleanup, or bug fixing are asking to be seriously embarrassed. > What are other's thoughts? Was all the trouble worth it? Should > further work proceed from a 4.1 base? A system V base? Or what? If any more Research systems see the light of day, we might find another base for development there. Someone MIGHT even consider taking the concepts and starting over from scratch. It's been done before:-) -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...A friend of the devil is a friend of mine.
Mike@brl-tgr.UUCP (01/19/85)
No, it's not a failure. BRL has measured filesystem performance improvements of 7X for various graphics applications, and it REALLY HELPS. I regularly see DELIVERED USER DATA in excess of 500 Kbytes/sec sustained for > 10second bursts off of our Eagles on the SBI on a 780. No complaints here. I submit that Doug Gwyn's relative ease of implementing his System V-under-4.2 BSD package tells you quite a bit about the relative differences. SUMMARY. Both System V and 4.2 are still UNIX. System V has lots of emphasis on good user utilities and massive user documentation. 4.2 has emphasis on performance and networking. If you don't need networking or performance, System V is the clear winner. If you have more than a few machines, networking is hard to live without. NOW LETS CANCEL THIS DISCUSSION -- net.unix-wizards IS FOR MORE SERIOUS TOPICS THAN THESE INTERMINABLE PHILOSOPHICAL DISCUSSIONS. -Mike Muuss UNIX-WIZARDS Moderator
jbn@wdl1.UUCP (01/22/85)
4.1BSD is a very stable system. Below is our /usr/adm/shutdownlog for
the last six months or so, all on an original-release 4.1BSD system with
UNET networking. No panics other than machine checks; most of the the
shutdowns shown below are for scheduled hardware or software service.
The machine is a 4MB VAX 11/780 with four CDC9766 disk spindles, supporting
about twenty users at a time. (This is host FORD-WDL1.ARPA on the Internet.)
Is anyone getting this level of stability with a 4.2BSD system?
Reports on ULTRIX would especially be appreciated.
Perhaps there should be a newsgroup for exchanging uptime/downtime
data.
09:07 Mon Aug 13, 1984. Reboot
09:28 Mon Aug 13, 1984. Reboot
16:00 Fri Aug 17, 1984. Shutdown: Going down for network fixing. Back up in 1/2 hour (by jrb)
16:00 Fri Aug 17, 1984. Halted.
16:19 Fri Aug 17, 1984. Reboot
00:04 Sun Aug 26, 1984. Reboot
16:00 Mon Aug 27, 1984. Shutdown: system is going down for DEC repair (by root)
16:00 Mon Aug 27, 1984. Halted.
16:56 Mon Aug 27, 1984. Reboot
22:49 Mon Aug 27, 1984. Shutdown: Reboot for network system (by root)
22:49 Mon Aug 27, 1984. Halted.
23:10 Mon Aug 27, 1984. Reboot
14:07 Thu Sep 6, 1984. Reboot
09:18 Mon Sep 10, 1984. Shutdown: DEC PM service (by root)
09:18 Mon Sep 10, 1984. Halted.
10:39 Mon Sep 10, 1984. Reboot
17:59 Mon Sep 10, 1984. Shutdown: SYSTEM TROUBLE (by root)
17:59 Mon Sep 10, 1984. Halted.
11:29 Tue Sep 11, 1984. Shutdown: Going down for memory testitg (by root)
11:29 Tue Sep 11, 1984. Halted.
12:39 Tue Sep 11, 1984. Reboot
04:06 Wed Sep 19, 1984. Reboot
12:56 Tue Sep 25, 1984. Shutdown: (by root)
12:56 Tue Sep 25, 1984. Halted.
13:14 Tue Sep 25, 1984. Reboot
09:36 Sat Oct 6, 1984. Shutdown: For System Maintenance (by root)
09:36 Sat Oct 6, 1984. Halted.
00:50 Sun Mar 10, 1985. Reboot
21:46 Sun Oct 7, 1984. Shutdown: New Unet system (by root)
21:46 Sun Oct 7, 1984. Halted.
22:04 Sun Oct 7, 1984. Reboot
09:32 Mon Oct 8, 1984. Shutdown: DEC PM (by root)
09:32 Mon Oct 8, 1984. Halted.
10:01 Mon Oct 8, 1984. Reboot
10:03 Mon Oct 8, 1984. Shutdown: (by root)
10:03 Mon Oct 8, 1984. Halted.
11:38 Mon Oct 8, 1984. Reboot
06:51 Thu Oct 11, 1984. Reboot
21:08 Fri Oct 19, 1984. Shutdown: Tape drive hung (by root)
21:08 Fri Oct 19, 1984. Halted.
21:27 Fri Oct 19, 1984. Reboot after panic: mchk
08:41 Mon Oct 22, 1984. Shutdown: DEC Maintenance (by root)
08:41 Mon Oct 22, 1984. Halted.
02:33 Sun Mar 10, 1985. Reboot after panic: mchk
09:05 Tue Nov 20, 1984. Shutdown: (by root)
09:05 Tue Nov 20, 1984. Halted.
12:22 Tue Nov 20, 1984. Reboot after panic: mchk
13:36 Tue Nov 20, 1984. Reboot
13:35 Wed Dec 5, 1984. Reboot
02:29 Thu Dec 6, 1984. Reboot
09:33 Mon Dec 10, 1984. Reboot
11:59 Mon Dec 17, 1984. Reboot after panic: mchk
11:21 Wed Jan 16, 1985. Reboot
23:58 Thu Jan 17, 1985. Shutdown: Reboot with larger system (by root)
23:58 Thu Jan 17, 1985. Halted.preece@ccvaxa.UUCP (01/23/85)
> ... The most significant addition was the > support for networking, which may be the last gasp of the > networking-inside-the-operating-system approach. (The state of the > art is to use intelligent networking cards; Excelan and Communications > Machinery make cards that provide IP/TCP services on an Ethernet; > these cost about the same as ordinary dumb Ethernet cards.) ---------- Leaving aside thoughts of how nice it would be to be able to afford to replace all our equipment with state of the art boards, how about those of us with machines other than Vaxen? Curiously enough, the board manufacturers don't hit the street with boards for every machine all at the same time. The Berkeley networking code allows access to generic sorts of ethernet controllers which may be easier to put together for another machine. The next generation will have intelligent components, but for now it's nice that all our little machines (and our big ones) have been able to talk to each other through the Berkeley code. scott preece ihnp4!uiucdcs!ccvaxa!preece
wls@astrovax.UUCP (William L. Sebok) (01/24/85)
> > 4.1BSD is a very stable system. Below is our /usr/adm/shutdownlog for > the last six months or so, all on an original-release 4.1BSD system with > UNET networking. No panics other than machine checks; most of the the > shutdowns shown below are for scheduled hardware or software service. > The machine is a 4MB VAX 11/780 with four CDC9766 disk spindles, supporting > about twenty users at a time. (This is host FORD-WDL1.ARPA on the Internet.) > Is anyone getting this level of stability with a 4.2BSD system? > Reports on ULTRIX would especially be appreciated. We are. We have much less software related crashes now under 4.2 BSD than when we were running 4.1 BSD a year ago. -- Bill Sebok Princeton University, Astrophysics {allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wls
pedz@smu.UUCP (01/25/85)
Re Intellegent Ethernet boards: How does two boards of possible different vendors know about each other? How do gateways get implemented? I do not know but it just seems to me that the OS must be the supervisor of all the networking. Besides, it provides a more transparent method of communicating to another process. Simply open a socket and start talking. The other process may be on the same machine or on a different machine several gateways away. If networking can be done with intellegent controllers and keep this transparancy and flexibility, then I am all for it. I just do not see how it is possible. Perry
gertjan@txsil.UUCP (01/26/85)
The next release of 4.2 (4.2+?) is promised to be 30% faster as announced on a BOF evening during USENIX.
bass@dmsd.UUCP (John Bass) (01/26/85)
Is 4.x a failure ... NO IS 4.x a high performance system ... MAYBE YES and MAYBE NO People forget that 4.1 and 4.2 were paid for and tuned for AI Vision and CAD/CAM projects sponsored by ARPA and various compainies. For the job mix that 4.x systems are tuned for it is the ONLY way to do those jobs on a UNIX machine with any cost effectiveness. Many tradeoffs that go into 4.x systems are directly counter the best ways to tune UNIX systems for development environments ... but they were the only way to make things work for the target applications. The converse is also true to a large extent ... V7/SIII/S5 kernels don't handle large applications well or at all --- try running a 6mb application on an older bell system with swapping .... it takes many seconds for a single swap in/out. But exactly the same problem arises out of blindly using a paging system for the typical mail/news/editor/compiler type support or development machine. In this environment the typical job size is 5-50 pages with an 75-95% working set ... when the total working set for the virtual address space approaches the real memory size on a 4.x system running these small jobs the system goes unstable causing any program doing disk I/O loose one or more critical pages from it's working set while it waits for its disk i/o (either requested via a system call ... or just from page faulting). The result is a step degradation in system throughput and an interesting non-linear load curve with LOTS of hysterisis AND a sharp load limit at about 150-250% of real memory. In comparison a swap based system linearly degrades smoothly at 1/#users for most systems ... up to a limit. On Swap based systems if the swap in + swap out time excedes the scheduling quantum (several seconds on most unix systems) then even a swap based system can trash and show a simular step degradation, non-linear load curve, hysterisis, and the load limit. This was evident on ONYX because the burst disk thruput was limited by the z80 controller to a 3:1 interleave or about 180kb/sec .... memory was relatively cheap compared to fast disks in 1980 so we sold lots of memory. This was evident on the Fortune VAX running 4.1 after several months of intensive load analysis tracking load factor results and instrumenting the disk subsystem. 4.1's favorite trick is to have a step increase in load factors from between 1-4 to 10-20 with little time any where in between. On the Fortune Vax this was caused by an interaction between paging and filesystem traffic on the root spindle when the average service time in the disk queue exceded the memory reapers quantum. A careful policy of relayout of the filesystems and regular dump/restore of filesystems to keep them sequential and optimally packed kept teh filesystem (read disk subsystem) thruput high enough the step degadation (step increase in load factors) would not occur and we then seldom saw load factors of 10-20, and only then with a linear rise in load. I have seen the same problem on most other 4.1 systems ... particularly those with a single spindle and small memory configurations (less than 2mb). Most vax systems run 35-50 transactions per second average to the entire disk subsystem ... a swap system handling a 40k process will typically take one/two transactions ... a paging system 40 or more depending on the thrashing level. The working set theory CORRECTLY predicts such poor behavior for such small programs with large percentages of active pages. If it is required to run several very large images (CAD/CAM, vision or other high res graphical application) with 2-8 mbyte arrays ... then the working set theory combined with processor speed/memory size predictors make paging a clear choice. Much of the speed difference of 4.1 over v7 and SIII/S5 was simply the 1k filesystem. For older PDP11's the per block processing time for most 512 byte sectors was several times the transaction period .... IE ... it took several 6-10 milliseconds of cpu time to digest a block which was tradedoff against filesystem thruput and memory constraints of 256kb max system size. The advent of much faster processors and much larger system memory made using 1k blocks necessary and practical where your system didn't have the cycles or space before. For those of us mothering 11/45's in the 70's this was a very difficult tradeoff ... we had kernels of about 70kb leaving less than 180kb to support 2-6 incore processes/users ... or in todays terms ... nor more than 2/3 happy vi users. increasing the filesystem size to 1k would increase memory overhead by 6-10k in the kernel and 2-4k in each process ... or ONE LESS VI DATA/STACK segment --- a major reduction in the number or incore jobs 30-50% and much more swapping and response time delays. Today with relatively cheap ram ... only the smallest systems need worry this problem ... and then a mix of swapping (for jobs less than 150-500kb) and paging (for jobs greater than 150-500kb) will make most of these problems go away. As for the 4.2 "fast filesystem" ... it was again tuned to make large file transaction run at an acceptable rate .... try to load/process a 4mb vision or cad/cam file at 30-50 1k block transactions per second -- it will run SLOW compared to a production system with contigous files. A number of tradeoffs were made to help large file I/O and improve the transaction rates on very loaded systems (LIKE ucb ernie ... the slowest UNIX system I have ever used .... even my 11/23 running on floppies was faster). But for most of us -- particularly us small machine types .. PDP11/23's, 11/73's, ONYX's, Fortune's, Tandy 16B's ... and a number of other commercial systems (including VAX 11/730, 11/750, and micro vaxs) which run 1-8 users ... the 4.2 filesystem is VERY SLOW and gets SLOWER much faster over time than a v7/4.1 filesystem. The tradeoff here is that "locality of reference" is much smaller and well defined on smaller systems ... on larger systems (like ernie) the disk queue has a large number of requests spread across the entire disk with a much broader locality of reference. The 4.2 filesystem attempts to remove certain bimodal or n-modal access patterns based on the FACT it doesn't much mater where the data is for reading ... but it is better to write it without generating a seek .... for systems with large disk request queues. This doesn't hold up on small systems where much of the time there is a single active reader using the disk subsystem. On the small system locality of reference is the entire key to throughput, thus randomly allocating files wherever is a great loss. I have spent most of my 10 years of UNIX systems hacking, porting and tuning on smaller systems. Other than CAD markets I don't see much use for paging systems, and as a result view 4.1/4.2 as only a hinderance due to the tendancy of some firms to put all the bells and toys into their system. This has been a disaster for several firms who got side tracked by Berkeley grads and hangers on. But in the big system markets ... particularly CAD/CAM, highres graphics, large multiuser system (30-200 users), and AI/Lisp markets 4.2 may be the only alternative ... it would be a mistake to drag the standard unix blindly down the 4.2 path ... 99.99% of the unix systems either delivered today or built in the next couple years would be hurt badly by it. It would make the number one alternative to UNIX on smaller systems ONLY MSDOS -- not such a bad system ... but lets keep it in its place too. I have a lot of interesting numbers and recomendations in performance areas ... I was going to give them in a talk at Dallas but they saw fit to cancel it after requireing a formal paper for the unplanned proceedings without any notice ... and then having a two page draft lost in the mail. I don't feel to bad about it since appearently 8 other speakers were also accepted and dropped because they couldn't get papers written and approved in the several day to 2week window. I hope that next time they put out a call for presentations USENIX lets people know in advance papers are required and don't change the rules in the 11th hour if they say they are not. Most of us can't write a GOOD 5-10 page paper with a 24 hour deadline which is basiclly what they asked of speakers this time -- other than those who had already done a paper for some reason. Good nite ... have fun John Bass Systems Consultant (408)996-0557
avolio@grendel.UUCP (Frederick M. Avolio) (01/26/85)
> Is anyone getting this level of stability with a 4.2BSD system? > Reports on ULTRIX would especially be appreciated. Yes, we are on our Ultrix-32 system on a VAX-11/750. We throw away the up/down log periodically, so from memory -- in the 6 or 7 months I have been using the system (it has been around longer than I) it has crashed 5 or 6 times when the power went out due to thunderstorms (each time it rebooted, fixed the file system errors, and came up on its own). It also crashed twice due to hardware errors in the disk controller causing hard errors all over the disks. (This was fixed by powering them all the way down and then back up again. I don't claim to understand it...:-)) -- Fred Avolio 301/731-4100 x4227 UUCP: {seismo,decvax}!grendel!avolio ARPA: grendel!avolio@seismo.ARPA
steveh@hammer.UUCP (Stephen Hemminger) (01/28/85)
<47500007@ccvaxa.UUCP> > ... The most significant addition was the > support for networking, which may be the last gasp of the > networking-inside-the-operating-system approach. False. The socket model (or stream I/O system) is necessary for several reasons. 1) There are other network protocols that often need to be added, would you prefer each vendor add his/her own system calls? 2) Not all protocols will have smart boards. How about workstations where putting a $5K board in to do networking is economic suicide. 3) Even the smart TCP/IP boards don't know how to do IP forwarding so they won't work on gatways (last I heard anyway). 4) With 4.2Bsd there are fairly clean "object oriented" interface points to allow hooking up network devices that work at higher levels.
henry@utzoo.UUCP (Henry Spencer) (02/03/85)
Actually, we came up with a rather different idea about why 4.2BSD's
"fast file system" gives such disappointing results in practice. It
expends quite a bit of effort to try to keep related blocks on the same
cylinder (or nearby). However, note that related blocks are seldom
accessed simultaneously; there is usually some processing delay in
between. Keeping related blocks near each other is a win *only* if
the disk heads will probably still be in the vicinity when the next
access occurs. And... the 4.2BSD filesystem benchmarks were all run
*single-user*!!! So of course it's nowhere near that good when a
dozen other processes are competing for the disk heads. The speed
improvements that *are* seen are probably mostly just a result of
bigger blocks. We conjecture that the "cylinder group" approach
is of little or no benefit for orthodox multi-user time-sharing.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry