Hi I switched over half a dozen or so servers to 5.x since october last year expecting the same stability and performance I have had from freebsd 4.x, after running it for 2 or 3 months I have ran into some problems/concerns, listed below. This is not intended for anything other then feedback and andswers to my questions I am well aware of the hard work put into freebsd and will continue to love the os. 1 - Speed, performance, All but 2 of the servers are normal Single processor machines and I think mainstream is still single processor, whilst there are smp machines and 64bit machines cropping up they are still a minority, what I have noticed first hand and read on the web is that 5.3 is sluggish behind 4.10 on single cpu machines, whilst on 64bit and smp machines it whizzes along. Was it a wise decision to only concentrate on smp performance as what seems to be the case and is there going to be single processor improvements to come? 2 - stability, about 75% of my servers are fully stable on freebsd 5.3, on 4.x I have had no stability issues. We have 1 server just continously locking up, another one that has tcp stack problems (its to do with the network side of things as locally it responds but goes offline), and has to be rebooted every few weeks. 3 - robustness, 5.3 seems to not handle ddos attacks so well, I remember on a 4.x machine I could easily take a full 100mbit udp flood and have the server respond albeit maybe with some lag but it stayed functional, 5.x seems to crumble under a lot less pressure on the same machine. This could be with pf been loaded on top of ipfw adding extra overhead I dont know. 4 - compatiblity, I remember using 5.2.1 and pretty much all software worked well in that and then they did the bind defaulting to base and libs version jump, why wasnt this done in 5.0 so 3rd party apps could adjust, now we have a situation where most stuff that worked in 4.x worked well in 5.1 and 5.2.1 but then broke in 5.3 so effectively 5.3 was liek a new major version over 5.2.1. I doubt I will be rolling back my server's as I know things will get better over time but new server's we build I will expect to be deploying 4.10 on them. I just feel with the ULE scheduler stuff and the IO performance issues I have heard about along with the issues I have come across that 5.3 got rushed towards the end, and instead of keeping 5.x as CURRENT they wanted 5.3 to be a production release so disabled some things such as the ULE scheduler to force it to be stable and its turned out a bit messy. Has anyone else got comments on my 4 main points? Chris
On Sunday, 6. February 2005 16:01, Chris wrote:> 4 - compatiblity, I remember using 5.2.1 and pretty much all software > worked well in that and then they did the bind defaulting to base and > libs version jump, why wasnt this done in 5.0I personally told lots and lots of people to NOT use 5.2.1-Release and wait for 5.x to become a stable branch instead, but it still got installed far more often than it really should have. 5.2.1 was still a Technology Preview release - it was a snapshot of FreeBSD 5-CURRENT, just as 5.0-RELEASE, 5.1-RELEASE and 5.2-RELEASE were before. In retrospect, there probably should have been more warning signs on the website and the documentation to point out that fact. Also, there probably should have been more feature and driver backports to FreeBSD 4, so less people would have been tempted by the better hardware support and general friendlyness of FreeBSD 5-CURRENT. Too late to change now, but perhaps something that should be remembered for the next time FreeBSD goes through a similar transition period. -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050206/05df5eee/attachment.bin
On Sun, Feb 06, 2005 at 03:01:49PM +0000, Chris wrote:> 4 - compatiblity, I remember using 5.2.1 and pretty much all software > worked well in that and then they did the bind defaulting to base and > libs version jump, why wasnt this done in 5.0 so 3rd party apps could > adjust, now we have a situation where most stuff that worked in 4.x > worked well in 5.1 and 5.2.1 but then broke in 5.3 so effectively 5.3 > was liek a new major version over 5.2.1.I haven't seen much trouble with the rest, but my way of handling the above was to take the entire shared library complement from 4.x and load it in a "compat" directory, then add that to the ldconfig set. I am still running a whole host of application binaries (indeed, probably 80% of them) on 4.x code. No problems so far. -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://www.spamcuda.net SPAM FREE mailboxes - FREE FOR A LIMITED TIME! http://genesis3.blogspot.com Musings Of A Sentient Mind
Chris wrote:> Hi > > I switched over half a dozen or so servers to 5.x since october last > year expecting the same stability and performance I have had from > freebsd 4.x, after running it for 2 or 3 months I have ran into some > problems/concerns, listed below. This is not intended for anything > other then feedback and andswers to my questions I am well aware of > the hard work put into freebsd and will continue to love the os. > > 1 - Speed, performance, All but 2 of the servers are normal Single > processor machines and I think mainstream is still single processor, > whilst there are smp machines and 64bit machines cropping up they are > still a minority, what I have noticed first hand and read on the web > is that 5.3 is sluggish behind 4.10 on single cpu machines, whilst on > 64bit and smp machines it whizzes along. Was it a wise decision to > only concentrate on smp performance as what seems to be the case and > is there going to be single processor improvements to come? >The focus on SMP is an investment in the future. Within a few years, multi-core CPUs (not just Hyperthreading) are going to become the norm, and single CPU systems will eventually become the minority. Of course, that might not help you today when you look at your investment in single CPU systems, and I can understand your frustration. FreeBSD 5.x has mostly been about laying the foundation for the new model and ensuring that it works correctly. We've tried to bring performance up to an acceptable level on UP, but there is obviously still work to be done. Luckily, a number of developers are actively engaged in this work, from making locks cheaper to cutting down on interrupt handling latency.> 2 - stability, about 75% of my servers are fully stable on freebsd > 5.3, on 4.x I have had no stability issues. We have 1 server just > continously locking up, another one that has tcp stack problems (its > to do with the network side of things as locally it responds but goes > offline), and has to be rebooted every few weeks.Are you using plain 5.3-RELEASE, or are you tracking the RELENG_5_3 or RELENG_5 branches? A number of bugs have been fixed since the 5.3 release. It would be quite interesting to find out the nature of your problems.> > 3 - robustness, 5.3 seems to not handle ddos attacks so well, I > remember on a 4.x machine I could easily take a full 100mbit udp flood > and have the server respond albeit maybe with some lag but it stayed > functional, 5.x seems to crumble under a lot less pressure on the same > machine. This could be with pf been loaded on top of ipfw adding > extra overhead I dont know.This probably would add quite a bit of overhead. The ipfw package is not locked, so dealing with that adds even more overhead, unfortunately.> > 4 - compatiblity, I remember using 5.2.1 and pretty much all software > worked well in that and then they did the bind defaulting to base and > libs version jump, why wasnt this done in 5.0 so 3rd party apps could > adjust, now we have a situation where most stuff that worked in 4.x > worked well in 5.1 and 5.2.1 but then broke in 5.3 so effectively 5.3 > was liek a new major version over 5.2.1.5.3 was the first release that we actively advertised as having API stability. There were a number of library problems compatbility problems that we caught and fixed before 5.3 was released, and that led to the library version bumps. A valid argument could be made that 5.3 should have been called 6.0, though.> > I doubt I will be rolling back my server's as I know things will get > better over time but new server's we build I will expect to be > deploying 4.10 on them. I just feel with the ULE scheduler stuff and > the IO performance issues I have heard about along with the issues I > have come across that 5.3 got rushed towards the end, and instead of > keeping 5.x as CURRENT they wanted 5.3 to be a production release so > disabled some things such as the ULE scheduler to force it to be > stable and its turned out a bit messy. Has anyone else got comments > on my 4 main points?ULE was indeed turned off because of performance and stability problems. It has a lot of potential and I do hope it gets to the point where it can be made the default again, but for now the 4BSD scheduler is a better choice for most people. The problems with ULE would have forced us to disable it for the release regardless if the was -CURRENT or -STABLE. I'm taking a hard look at I/O performance right now while I optimize a number of drivers. There is have been a number of discussion on various mailing lists recently about I/O performance (most notably on the freebsd-performance list), and if you have any data to share, I'd like to see it. Scott
On Sun, Feb 06, 2005 at 03:01:49PM +0000, Chris wrote:> 4 - compatiblity, I remember using 5.2.1 and pretty much all software > worked well in that and then they did the bind defaulting to base and > libs version jump, why wasnt this done in 5.0 so 3rd party apps could > adjust, now we have a situation where most stuff that worked in 4.x > worked well in 5.1 and 5.2.1 but then broke in 5.3 so effectively 5.3 > was liek a new major version over 5.2.1.5.2.1 was clearly marked as a "developer preview" release and you were warned not to rely on it for production use. As a snapshot of FreeBSD-CURRENT, binary compatibility is not guaranteed and often needs to be broken in the course of development. Kris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050206/731fa657/attachment.bin
> On Sun, Feb 06, 2005 at 03:01:49PM +0000, Chris wrote: > >> 4 - compatiblity, I remember using 5.2.1 and pretty much all software >> worked well in that and then they did the bind defaulting to base and >> libs version jump, why wasnt this done in 5.0 so 3rd party apps could >> adjust, now we have a situation where most stuff that worked in 4.x >> worked well in 5.1 and 5.2.1 but then broke in 5.3 so effectively 5.3 >> was liek a new major version over 5.2.1. > > 5.2.1 was clearly marked as a "developer preview" release and you were > warned not to rely on it for production use. As a snapshot of > FreeBSD-CURRENT, binary compatibility is not guaranteed and often > needs to be broken in the course of development. > > KrisJust adding a note: I regularly use FreeBSD on a Toshiba notebook, and switched from 4.x to 5.x to benefit from cardbus support. Well, I started with 5.2.1 and all things did well. Since then, I'm trying to track 5-STABLE with no success. Starting with 5.3-RELEASE, the ACPI stopped to work, as well as did the rl driver. So, I switched back to 5.2.1. []s T?rgan
On Sun, 6 Feb 2005, Scott Long wrote:> > 3 - robustness, 5.3 seems to not handle ddos attacks so well, I > > remember on a 4.x machine I could easily take a full 100mbit udp flood > > and have the server respond albeit maybe with some lag but it stayed > > functional, 5.x seems to crumble under a lot less pressure on the same > > machine. This could be with pf been loaded on top of ipfw adding > > extra overhead I dont know. > > This probably would add quite a bit of overhead. The ipfw package is > not locked, so dealing with that adds even more overhead, unfortunately.Actualy, just to set the record straight on this technically -- ipfw is locked, albeit using a variation on the sx lock theme. ipfw will run without Giant as long as the rest of the stack is running without Giant. Robert N M Watson