Only two days behind schedule, the FreeBSD team released the first in a series of betas leading up to what will (possibly) become the 5.3-STABLE milestone. FreeBSD 5.3-BETA1 one can be obtained from here or one of many mirrors. Release notes here.
FreeBSD 5.3-BETA 1 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Last time I tried 5.x, it still needed a lot of work on SMP. To take full advantage of the SMP improvements, you needed certain hardware, otherwise you were saddled with the big lock, still. At least that’s what I gleaned from the documentation.
I’m still running 4.x on my servers, and don’t plan on upgrading anytime soon, really.
I’d like to see SGI or IBM allow one of their superior FS’s to be BSD-licensed so FreeBSD and NetBSD can finally move on from FFS.
There seems to be still quite a lot of open issues:
http://www.freebsd.org/releases/5.3R/todo.html
Is ULE going to be the default scheduler?
ULE has been the default scheduler since 5.2.1. And yes it will be the default scheduler for future releases.
Well, I have 5.2.1 installed and SCHED_4BSD is the scheduler found on the GENERIC kernel config file.
I tried ULE but didn’t like the performance in some situations, like multiple simultaneous compilations.
Maybe there’s too much debug turned on or the implementation isn’t quite there yet.
hurdboy: They fixed the SMP network driver problems yet? Last time I tried 5.x, it still needed a lot of work on SMP. To take full advantage of the SMP improvements, you needed certain hardware, otherwise you were saddled with the big lock, still. At least that’s what I gleaned from the documentation.
See here: http://lists.freebsd.org/pipermail/freebsd-current/2004-August/0350…
This link should be include in the news, because it has some more informations.
Alp: Is ULE going to be the default scheduler?
You should have read in the Release Notes (link above in news) and you will never ask that kind of question.
http://www.freebsd.org/projects/busdma/
You should have read in the Release Notes (link above in news) and you will never ask that kind of question.
I’d suggest you have a look at the ToDo page I linked earlier, under the section “scheduler cleanup and resolution”. That shows it is not all too clear which one will be default.
Please keep your arrogant comments to yourself next time.
I’d suggest you have a look at the ToDo page I linked earlier, under the section “scheduler cleanup and resolution”. That shows it is not all too clear which one will be default.
In the Release Notes:
The ULE scheduler is now the default scheduler in the GENERIC kernel. For the average user, interactivity is reported to be better in many cases. This means less “skipping” and “jerking” in interactive applications while the machine is very busy. This will not prevent problems due to overloaded disk subsystems, but it does help with overloaded CPUs. On SMP machines, ULE has per-CPU run queues which allow for CPU affinity, CPU binding, and advanced HyperThreading support, as well as providing a framework for more optimizations in the future. As fine-grained kernel locking continues, the scheduler will be able to make more efficient use of the available parallel resources.
Has anyone tried to run Java 1.5 (beta) on this release or any of the 5.x FreeBSD releases. The reason why I ask is b/c it has been known that Java and FreeBSD don’t mix well.
This same exact comment has been used many times on OSNews, Slashdot and several other tech news sites.
And just what is wrong with FFS? Running both UFS and UFS2 on my system and it performs rather nicely and is rather reliable. I personally don’t see any reason for me to move away.
As the “report abuse” info tells you, we require you to email us the direct link so we can mod it down manually. Replying here, won’t do you any good, because none of the moderators are actually reading comments. It was out of luck tonight that I read this comment section.
The freebsd.org site is hosted with Yahoo, which is the largest user of FreeBSD among hosting companies, with more than 261k active sites. FreeBSD has a secured a strong foothold with the hosting community and continues to grow, gaining over a million hostnames and half a million active sites since July 2003. The reason for this is FreeBSD’s deployment with the operators of shared hosting systems, where tens and even hundreds of thousands of sites are collectively administered as part of a single system.
FFS is a dated FS design compared to um, just about everything with the exception of ext2/3. JFS, XFS, NTFS/HPFS, even *gag* ReiserFS, all use a nice b-tree design for fast access, fixed block size, etc. etc. Yes, FFS is stable, but it’s slow, and there are better designs today. See how long it takes to do newfs on a 200GB volume. See how long it takes to fsck same volume (softupdates don’t cure the necessity to fsck sometimes). It’s getting insane. I have one server that takes several hours to fsck (FreeBSD 4.9). I have larger volumes on Linux machines that go much faster with XFS.
That’s a rather short sighted analysis of FFS+Soft Updates. Journaling filesystems are somewhat of a Faustian bargain, especially when used in conjunction with write caching. Rather than simply not having changes written out if the system crashes/loses power before the write cache is committed, files are often simply deleted, or in the case of XFS, filled with zeroes.
Soft updates are able to order writes in such a way as to provide a consistent means of preserving data integrity when the filesystem is checked. At the same time, they perform caching of metadata, substantially improving the performance of metadata operations. Removing a large directory tree on a FreeBSD system is instantaneous, whereas depending on the number of items in the heirarchy, can take several minutes on Linux with journaling filesystems.
Never had a problem with speed here and UFS or UFS2. I can easily fsck 370GB of data under 30 minutes on my system.
BTW journaling is actually being worked into it as a option. Read the mailing lists some time.
Hmm… odd… newfs has all ways been nearly instant here… sounds like your system is badly configured.
Hehe, and on 5x small little problems like that are even less of a worry… and you have even quicker recovery time from the system going down uncleanly.
I tried both 5.1 and 5.2 – both could not understand my disk geometry. And this seems to be a known issue for some time…
Has this been fixed in 5.3-BETA1?
Regards,
Shaitan
Funny to see this posted. Wondering if I should really bother once 5.3 comes out. I just retried FBSD 5.2.1 over the weekend (was curious to see how the new Nvidia drivers work), and I ran into a problem I think I’ve seen before. In a nutshell, I have an audigy card, and I use a PCI modem for my net connection. The modem works fine, the audigy is unsupported in 5.2.1, however, looks like in 5.3 it is supported. There’s some patches out there, I tried two of them. One is the chibis driver, and the other looks to be a patch from Orlando B.
Anyhow, using the semi-official patch (I believe its the one that being merged into 5.3), if I enabled sound, when I’d go to access the modem, the whole OS freezes up. I have to cold kill it. I suspect an IRQ conflict of sorts, but shouldn’t the OS be able to deal with this? With the other driver, I also experienced this problem in the past, though not this time, now it just complains that it can’t bind to the device, and hence isn’t terribly useful for me right now.
As a side note, I’ve not had this problem with the other BSDs, nor with Linux. Kind of sucks, because I’d really like to be able to use FreeBSD as my workstation.
5.2.1 doesn’t recognize geometry of 2 standard IDE HDDs of mine either.
I’m using the new nvidia drivers right now. My system continues very stable and the performance gain is impressive.
This comment is in response to one posted a little while ago concerning how well FreeBSD works with Java. Just a few facts concerning the issue:
1) The FreeBSD foundation is currently and has been working with Sun to have certified releases of Java. Currently only version 1.3 has been approved by Sun as java compatible.
2) There is a team of coders working on creating patches for the most recent releases of java. Patchset level 6 for java 1.4.2 is quite stable and I has been used in a number of production systems quite successfully (including my own)
3) There is currently no official patchset for java 1.5
I have used java on freebsd for a while now and while it isn’t the funnest thing to have to compile the sources by hand I have not had any issues with it running Resin and our various EJB applications.
For those of you who have not yet tried FreeBSD out I would strongly recommend it. It is a wonderful system which is nicely polished. I don’t mean to bash on Linux or any other operating system but I do a lot of database dumps and reloads when testing on **very** large datasets (on the order of 500,000 SQL queries). In every other operating system I have ever tried with MySQL it takes .5 seconds per query on average. In FreeBSD it takes approximately .07, when working with that many records that is a significant time difference.
Personally freebsd is my favorite OS, it’s extremely stable and very fast and responsive (perhaps in my expereince even the fastest), even with lots of things running or/and compiling.
I know a lot of problems in 5.x especially 5.2 and 5.2.1 had been fixed in the 5-current, So I assume that 5.3 will have very fewer problems as 5.2.1 had.
Personally I have not had any problems installing/using java on freebsd, but I dont use it a lot.
My advice is to all is to give it a testdrive, thats why they put the 5.3 beta out, and report back issues so they can be worked out.
Has X.org become the default for sysinstall in this beta release? I know there was talk about it. If so I’ll download it now and try it. If not, well for me there is no sense.
Click on a link that I have given in the fifth comment at the first page. It gives you this answer.
X.org is the default for FreeBSD 5.3.
XFree86 4.4 is also available in the ports tree for those who wish to stick with it.
And there’s a nice make.conf variable for choosing which one should be used for port dependencies.
Yes, for most network drivers. The default will be to enable thread support in the network drivers, but you’ll always have the option of disabling the debug.mpsafenet sysctl to drop back to single-threaded networking.
SCHED_ULE has been the default in GENERIC since about two days after the release of 5.2.1.
SCHED_BSD is still available for those that have problems with SCHED_ULE.
newfs-ing a 400 GB RAID 5 array took maybe 10 minutes on a dual-Athlon-MP 2600+ system with 3.5 GB RAM and a 3Ware Escalade RAID controller.
On the few times I’ve had to fsck the drive, it took less than 30 minutes to complete (there’s just over 100 GB of data in the /home partition). While that’s not fast, it takes longer than 30 minutes to fix a ReiserFS 3 /home partition on our RedHat 7.x servers (yeah, they’re old, but they work).
SoftUpdates and Journals are solutions to different problems. They can’t really be compared directly. Neither one is the perfect solution to all problems. It would be nice if XFS or JFS was ported over to FreeBSD, though.
Only two days behind schedule
I’m sorry, this is laughable. Technically correct because it reflects the recently updated scheduler, but it implies that everything is going smoothly. In reality, 5-STABLE is literally *years* behind schedule.
I’m sorry, this is laughable. Technically correct because it reflects the recently updated scheduler, but it implies that everything is going smoothly. In reality, 5-STABLE is literally *years* behind schedule.
Give yourself a gold star, Complainy McDouchebag. Obviously that comment was in the scope of moving the 5-CURRENT tree to 5.3-RELEASE. While you may or may not be silently lauding Linux, it certainly serves as a maturity benchmark for other operating systems, so I’ll go ahead and compare them now for the purposes of establishing FreeBSD 5.x’s relative maturity.
For all the political turmoil, difficulties in reimplementing multithreading from scratch into the kernel in a well-designed, cohesive manner, they’re able to achieve a meticulously well integrated OS environment which performs on par with its much lauded and overhyped cousin, Linux, on the primary target platforms for the two, low end to midrange servers. Linux certainly proves more scalable in the high end server space, but it can’t hold a candle to the competators in that field such as Solaris and z/OS.
I certainly commend the work of the FreeBSD developer team and highly admire their (Cathedral) engineering methodology as opposed to the progressive cobbling of more cruft onto the existing system and then making large slash-and-burn changes when it proves unmaintainable, like Linux has done with *major* kernel subsystems like the VM which have been stable and finely tuned in FreeBSD for years.
Give yourself a gold star, Complainy McDouchebag. Obviously that comment was in the scope of moving the 5-CURRENT tree to 5.3-RELEASE.
No, that wasn’t obvious.
While you may or may not be silently lauding Linux
You BSD zealots sure do have a lot of Linux conspiracy theories. Just stick to the topic, OK? That is: FreeBSD.
[ snip a lot of baseless claims and Linux envy ]
Well thank you for that load of tripe. Please stick to slashdot in future.
Please don’t feed the trolls
What’s more, a quick search shows that your claims are not only baseless, but in fact plain wrong.
http://marc.theaimsgroup.com/?l=freebsd-amd64&m=108490922809652&w=2
About 2 or 3 different people were all having the same problem with Linux running at nearly twice the speed of FreeBSD on this low end server. They offered $500 and free access their hardware for anyone who could solve the problem. Nobody could.
Oh, and spare me your make believe counter-claim of having the exact opposite experience.
Sorry for feeding the troll. Those clowns always have to bring up Linux and simply can’t stick to the topic when discussing FreeBSD, can they?
Not taken the time to read all of it, but it sounds more like a mysql bug. There have been similar posts in regard to 5x. Nearly all of which wrapped back around to mysql not using the right lib for threading.
No. Changing the thread libraries didn’t help.
Not taken the time to read all of it, but it sounds more like a mysql bug. There have been similar posts in regard to 5x. Nearly all of which wrapped back around to mysql not using the right lib for threading.
It’s not a mysql bug. Robert Watson has been work very hard with the improvement on this part. Robert has posted in the mailing list few times with the different improvement results without compare with Linux yet. But, it is faster than older 5.2.1 now. It will be very insteresting to see someone to do the benchmark again between FreeBSD 5.3 and Linux.
It’s not a mysql bug. Robert Watson has been work very hard with the improvement on this part. Robert has posted in the mailing list few times with the different improvement results without compare with Linux yet. But, it is faster than older 5.2.1 now. It will be very insteresting to see someone to do the benchmark again between FreeBSD 5.3 and Linux.
rwatson just said this of the mpsafe networking stuff:
FYI, while results can and will vary, I was pleased to observe moving from a UP->MP speedup of 1.07 on a dual-processor box to a speedup of 1.42 with the supersmack benchmark using 11 workers and 1000 select transactions with MySQL. For reference, that was with the 4BSD scheduler and adaptive mutexes. For loopback netperf with TCP and UDP, I observed no change in performance (well, 1% better for UDP RR, but basically no change).
So this is about the best you would expect 5.3 to perform, considering it is in freeze (ie, best case, tuned by a FreeBSD guru). So it seems that the TCP/IP stack still only scales to 1 CPU on this test, however UNIX sockets allow the test to use 2 CPUs at 70% efficiency.