André Oppermann has held a presentation on new things and changes in the 5.3-FreeBSD Network Stack at the SUNCON 04 in Zurich yesterday. His very informative summary is available here. The original announcement can be found here.
Summary of network changes in FreeBSD 5.3
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
It’s great to see this kind of optimization activity going on. The BSDs have always had great TCP stacks, and this only makes them better. Add in the fact that the code is available, and you have an extremely useful advance in the state of the art.
What’s even more impressive is the fact that the DragonFly developers (Jeffrey Hsu mostly) have almost completely multithreaded thier network stack to the point of running free of the Big Giant Lock in roughly a one month period, whereas the FreeBSD folks have still not managed to do the same with their OS in the nearly three years since it branched from 4.x (DragonFly only forked from 4.x just over a year ago).
It’d be mighty sweet were the FreeBSD folks to adopt more DragonFly code than they currently are as I’m sure that they’d be much better off for it.
It’d be mighty sweet were the FreeBSD folks to adopt more DragonFly code than they currently are as I’m sure that they’d be much better off for it.
This would be neat, and it would appear that some fbsd dev are open to this – but they’re reserving judgement until dfly code has been thoroughly tested. Which is a reasonable stance. Politics aside, I think there have been some good developments in both dfly and fbsd, but the lack of a tride and true maintainer for ULE and various IPI and ACPI issues have really made 5.3 and -current a pain in the butt. Also – re@ is apparently discussing the future of ULE as a default (IOW, maybe switching back to 4BSD as the default). We’ll see!
From Andre’s post:
PS: Linux guys where pretty much floored that FreeBSD 5.3 can route 1Mpps and
they can’t do much more than 100kpps. 😉 Yes, way to go!
the post’s here:
http://lists.freebsd.org/pipermail/freebsd-net/2004-September/00484…
While Linux is a fairly good kernel/OS, it’s really nice to see that the BSD projects (FreeBSD above all, but also OpenBSD, NetBSD, & last but not least DragonFlyBSD) are achieving these results.
I especially appreciate them because of their academic spirit and their commitment to technical excellence, without any political BS involved.
It’s nice to see that this choice pays off. Way to go, guys!
🙂
ACPI is being worked on by a few developers. Because of poor ACPI implementations by a lot of (worthless) manufacterors this is a bit of a pain in the rear-end. They’ll get it done eventually, but it’s just taking time.
It’s very good to see that Fbsd can notice if the ethernet link state changes. (This has been implemented in w2k years ago)
My question is: if the link breaks, does the system show me a warning/put a line into the log, or how does it tell me the problem?
Anyway.. There are lot of things to do in 5.3 (as the TODO list is very huge and contains basic problems) so i dont think they can eliminate all of them till october (remember removing GIANT since years, said before). For me, 4.X will remain the stable for a long period.
May be huge, but it will get there. And a nice chunk of the systems I have tried 5.2.1 on it runs nice. That so far seems to also be the case of 5.3.
Basic problems? Those really exist in a case like this any ways?
That is easy to do on any UNIX system… just involves a small script that does occasional polling…
This would be neat, and it would appear that some fbsd dev are open to this – but they’re reserving judgement until dfly code has been thoroughly tested. Which is a reasonable stance.
Yeah, but when you considder that the new code in DragonFly is no less tested than the new code in FreeBSD 5.x, it’s kind of a moot point. Also, many if not most of the ideas employed in DragonFly have been done before, and have been known for *ages* so there’s no mystery as to wether or not they are good ideas.
Politics aside, I think there have been some good developments in both dfly and fbsd, but the lack of a tride and true maintainer for ULE and various IPI and ACPI issues have really made 5.3 and -current a pain in the butt.
This has been one of the biggest reasons why DragonFly forked in the first place, because Matt thought that the 5.x codebase would be a nightmare to maintain in the long run. He has seriously suggested on a number of occasions that the simplest things that the FreeBSD folks could do to improve their situation would be to port DF’s “IPI messaging” subsystem, which would replace the dozen or so different IPI mechanisms currently in FreeBSD, with one, simpler, more flexible and less troublesome mechanism, but most people in the FreeBSD camp either think he is joking, or just plain anti-FreeBSD, neither of which is true.
I am not by any meas a kernel guru, but I’m an avid reader, and I ask many questions to those who are in a better position to know things than I am, and from my experiences, DragonFly’s new architechture is *much* cleaner, more extensible, and just plain more maintainable than the mess that FreeBSD is evolving into. I like FreeBSD, it has been my system of choice for a while now, but there are some serious issues with it’s core (as well as some (a minority to be sure) of their developers), and it looks like from a technical point of view anyway, that DragonFly will be the way to go in the not too distant future (a year or so).
I am only interested in whether they will make some use of this feature, for example putting a line onto the console if any of the ethernet links break. Without further support, this feature worths nothing for a newbie like me