RE: Freebsd 5.3 Performance
> > >-Original Message- >From: [EMAIL PROTECTED] [mailto:owner-freebsd->[EMAIL PROTECTED] On Behalf Of Chris >Sent: Wednesday, January 12, 2005 5:44 PM >Cc: [EMAIL PROTECTED] >Subject: Re: Freebsd 5.3 Performance > >[EMAIL PROTECTED] wrote: >> Mr Watson, >> >> As you are listed as the leader of the FreeBSD foundation, and you seem to be >> the >> only one willing to admit that FreeBSD 5.3 is not yet up to the performance >> of 4.x, >> doesn't in concern you that: >> >> 1) Freebsd 4.x is not being supported as a production O/S, and the "support" >> is >> ending with 4.11 before 5.x is ready performance-wise? >> 2) FreeBSD 4.x doesn't seem to work well with the 7520/5 chipsets, which are >> required to run the latest Intel XEON CPUs (Dell's most powerful servers, for >> example, >> are based on the 7520). A long-standing PR has been largely ignored >> 3) None of your "developers", according to Ted M, have ever "heard of" Intel's >> latest and most powerful chipsets. >> 4) no one in your "organization" seems to care about 1, 2 or 3 >> >> FreeBSD has fallen into a performance "hole" of sorts, in that the fastest >> version >> doesnt run on the fastest Motherboards. Its easily correctable, by simply >> dedicating >> resources for a day or 2 to find out whats wrong with the 7520 support. I'd >> like to hear >> why you don't think its worthwhile, as a primary goal, to make certain that >> the >> fastest version of the product works well on the fastest available >> motherboards. > >Hahahaha - are we smelling a troll?! > >-- >Best regards, >Chris > >I finally got it all together ... >but I forgot where I put it. >___ >freebsd-questions@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-questions >To unsubscribe, send any mail to "[EMAIL PROTECTED]" Maybe the troll could be persuaded to work on a fix for the alleged problems that it's seeing. It would be far more productive and everyone, I'm sure would be much happier. BTW, I ran across the troll's name and another email address (probably one that doesn't change every 45 days) on a financial forum I was perusing. For a brief moment I was severely tempted to sign the troll up for every spam list that I could Google. Then my conscience kicked in and I remembered that it wouldn't be the right thing to do. Just think of the things I could have accomplished if my parents hadn't raised me with morals. Oh well, time to update my email filters again. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd 5.3 Performance
[EMAIL PROTECTED] wrote: Mr Watson, As you are listed as the leader of the FreeBSD foundation, and you seem to be the only one willing to admit that FreeBSD 5.3 is not yet up to the performance of 4.x, doesn't in concern you that: 1) Freebsd 4.x is not being supported as a production O/S, and the "support" is ending with 4.11 before 5.x is ready performance-wise? 2) FreeBSD 4.x doesn't seem to work well with the 7520/5 chipsets, which are required to run the latest Intel XEON CPUs (Dell's most powerful servers, for example, are based on the 7520). A long-standing PR has been largely ignored 3) None of your "developers", according to Ted M, have ever "heard of" Intel's latest and most powerful chipsets. 4) no one in your "organization" seems to care about 1, 2 or 3 FreeBSD has fallen into a performance "hole" of sorts, in that the fastest version doesnt run on the fastest Motherboards. Its easily correctable, by simply dedicating resources for a day or 2 to find out whats wrong with the 7520 support. I'd like to hear why you don't think its worthwhile, as a primary goal, to make certain that the fastest version of the product works well on the fastest available motherboards. Hahahaha - are we smelling a troll?! -- Best regards, Chris I finally got it all together ... but I forgot where I put it. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd 5.3 Performance
Mr Watson, As you are listed as the leader of the FreeBSD foundation, and you seem to be the only one willing to admit that FreeBSD 5.3 is not yet up to the performance of 4.x, doesn't in concern you that: 1) Freebsd 4.x is not being supported as a production O/S, and the "support" is ending with 4.11 before 5.x is ready performance-wise? 2) FreeBSD 4.x doesn't seem to work well with the 7520/5 chipsets, which are required to run the latest Intel XEON CPUs (Dell's most powerful servers, for example, are based on the 7520). A long-standing PR has been largely ignored 3) None of your "developers", according to Ted M, have ever "heard of" Intel's latest and most powerful chipsets. 4) no one in your "organization" seems to care about 1, 2 or 3 FreeBSD has fallen into a performance "hole" of sorts, in that the fastest version doesnt run on the fastest Motherboards. Its easily correctable, by simply dedicating resources for a day or 2 to find out whats wrong with the 7520 support. I'd like to hear why you don't think its worthwhile, as a primary goal, to make certain that the fastest version of the product works well on the fastest available motherboards. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd 5.3 Performance
I have noticed with all the work gone in to 5.x to optimise SMP performance in return uniprocessor performance has suffered considerably I think this is what the concerns are about? Will future releases such as 5.4 remedy this by fixing the drop in performance on uniprocessor machines? Chris On Mon, 10 Jan 2005 12:05:56 +, Dick Davies <[EMAIL PROTECTED]> wrote: > * Anthony Atkielski <[EMAIL PROTECTED]> [0154 09:54]: > > Mark writes: > > > > M> Ah, this point fascinates me. Running for years? Do you ever have > > M> to recompile your kernel? :) > > > > Usually once when I first install the OS, then never again (unless I > > change something in the hardware, which I hardly ever do). Windows > > often has to be rebooted just to install a new application (although > > that's a problem with the application, not a problem with the OS, in > > most cases). > > And what about security patches? > > -- > 'If we can hit that bull's-eye, the rest of the dominoes will fall like a > house of cards... Checkmate!' >-- Zapp. Brannigan > Rasputin :: Jack of All Trades - Master of Nuns > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd 5.3 Performance
* Anthony Atkielski <[EMAIL PROTECTED]> [0154 09:54]: > Mark writes: > > M> Ah, this point fascinates me. Running for years? Do you ever have > M> to recompile your kernel? :) > > Usually once when I first install the OS, then never again (unless I > change something in the hardware, which I hardly ever do). Windows > often has to be rebooted just to install a new application (although > that's a problem with the application, not a problem with the OS, in > most cases). And what about security patches? -- 'If we can hit that bull's-eye, the rest of the dominoes will fall like a house of cards... Checkmate!' -- Zapp. Brannigan Rasputin :: Jack of All Trades - Master of Nuns ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd 5.3 Performance
On Sunday, 9 January 2005 at 20:48:56 -0500, [EMAIL PROTECTED] wrote: > Your "point" doesn't address the lack of support for major chipsets, > so that users can utilitize the latest fast processors > available. The point is that those using 4.x because of its > performance advantages, cannot use it with the latest processors > because the MBs don't work in 4.x. THAT is the problem. I don't see any point, correct or otherwise. From the weekly "how to": Before you answer a question to FreeBSD-questions, consider: 3. Do you have something to contribute beyond what has already been said? 4. Are you sure you understand the question? 5. Are you sure your answer is correct? 6. Unless there's a good reason to do otherwise, reply to the sender and to FreeBSD-questions. 7. Include relevant text from the original message. See http://www.lemis.com/questions.html for the original message, which is much more detailed. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply or reply to the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address and phone numbers. pgpy8a4yuXxMP.pgp Description: PGP signature
Re: Freebsd 5.3 Performance
Your "point" doesn't address the lack of support for major chipsets, so that users can utilitize the latest fast processors available. The point is that those using 4.x because of its performance advantages, cannot use it with the latest processors because the MBs don't work in 4.x. THAT is the problem. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd 5.3 Performance
I find in amazing that a discussion of how FreeBSD 5.3 sucks compared to 4.x can segue into an discussion of FreeBSD vs Windows. I guess thats the politics of computing. And also a commentary on the mentality of the kind of person that uses FreeBSD. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd 5.3 Performance
Robert Watson writes: RW> The problems I have on the Windows XP platform appear to come from a RW> lack of robustness in the face of nasty application failure. A problem with the Windows environment as a whole is that applications tend to assume that they have the entire machine to themselves, and behave without any consideration for other programs that may be running on the same machine. In addition, Windows programmers (at least those with no experience outside of a PC environment) tend to vastly overused system calls and privileges that can destabilize the entire machine; many relatively mundane applications won't even install unless they can have privileges that they shouldn't really need. The net result is a far less stable platform than might otherwise be possible. It's all a consequence of the old MS-DOS paradigm, in which there is only one user and one program at a time, and any program can (and sometimes must) talk directly to the hardware and occasionally even override the OS. The NT family of operating systems corrected this in large part by introducing tight security concepts. But most Windows applications ignore or override these security features, making them moot. And Microsoft has aggravated the problem by removing or disabling features in NT versions such as Windows XP in order to increase compatibility and user-friendliness. Even NT 4.0 sacrificed security and stability just so that it could have a clone of the "modern" Windows 95 GUI. All of this is in contrast to UNIX, which, like so many other multiuser timesharing systems, has been obligated from the start to pay close attention to keeping users and programs separate. Ordinary UNIX user programs are aware of the fact that they are not alone and are written with security restrictions and the need for coexistence already in mind. In consequence, it's rare for a UNIX user program to do anything that destabilizes an entire system. Another way of looking at it is that, under Windows, practically every user program is the equivalent of a privileged daemon, potentially running roughshod over system stability. Having to support a GUI also destabilizes just about any system, and of course Windows depends on GUIs, although UNIX does not. RW> At work we use Windows with the usual combination of Microsoft RW> office and e-mail products, as well as tools like Acrobat. It seems RW> things go horribly wrong in the interactions between the components RW> (especially Acrobat integration into IE), and this leaves the system RW> in a poor state (often wedged). Lower level OS bits keep responding RW> to pings, but a hard boot is required to get anywhere useful. You're in a state where technically the system is up and running, and the OS is healthy, but the interaction and conflict between all the application programs you wish to run is so complex that any kind of error in one of them effectively stalls or kills them all. The only easy cure is a reboot. This is one argument against using application suites, as they are more likely to try to take over the machine and cause conflicts in consequence than are isolated, standalone applications. So Office or Lotus Notes is a lot more hazardous to run than some individual, free-standing application programs that make no assumptions about what else is on the machine. For this reason I'm very wary of installing anything from Microsoft these days, and only slightly less wary of companies like Adobe. They increasingly try to convert the entire PC to their own chosen environment during installation. RW> NT4 appeared a lot less robust with relatively frequent kernel RW> crashes, whereas with XP my impression has been that the kernel RW> itself is quite robust but the user shell and interface components RW> are so tightly integrated with application behavior that application RW> failure leaves them dead in the water. I didn't find NT to lack robustness, but I agree that XP and indeed all newer versions of Windows have confused the border between OS and applications so thoroughly that the net result is an overall destabilization of the machine. The extreme lack of transparency in Windows is a problem, too. You never really know what's going on behind the scenes. This is far less of a problem with legacy operating systems like UNIX that were designed to be fiddled with directly by administrators. RW> This is not disimilar to related failure modes on Mac OS X and using RW> X11/KDE on BSD, and suggests maybe part of the problem is in the RW> architecture of how we layer "system" applications over windowing RW> mechanisms. I completely agree. It's a general problem with any architecture of this kind (just installing a GUI is already a big step down the path of danger), but it's most obvious in the environments that depend most heavily on GUIs, such as Windows and the Mac. Of course, if you run a GUI on UNIX, you'll see similar problems there as well. To me it's too high a price to pay just for
Re: Freebsd 5.3 Performance
On Sun, 9 Jan 2005, Mark wrote: > > FreeBSD will run for years without a boot in many cases. > > Ah, this point fascinates me. Running for years? Do you ever have to > recompile your kernel? :) The longest personal uptime I've had is just under two years, and that was for a UPS-backed natbox in my parents' basement. I updated the userspace remotely as needed, but never bothered to reboot it as there wasn't really a motivation for a kernel update given its environment (the user space updates were for things like sendmail vulnerabilities). At some point, the power went out for longer than the UPS could keep it up, so the uptime went tumbling down... I think it was up for about 540-550 days at that point. Robert N M Watson ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd 5.3 Performance
On Sun, 9 Jan 2005, Anthony Atkielski wrote: > Robert Watson writes: > > RW> All I know is that the XP bits don't crash every week, they crash every > RW> three weeks. :-) My NT4 box crashed almost continuously. > > I have three machines, running FreeBSD, NT, and XP. All of them will > run until I boot them. They don't crash, or at least I can't remember > the last time I saw any of them crash (except for a hardware problem > that was crashing FreeBSD until I replaced the hardware). > > All of these operating systems are rock stable when used and > administered appropriately. I haven't had XP long enough to prove it, > but NT and FreeBSD will run for years without a boot in many cases. The problems I have on the Windows XP platform appear to come from a lack of robustness in the face of nasty application failure. At work we use Windows with the usual combination of Microsoft office and e-mail products, as well as tools like Acrobat. It seems things go horribly wrong in the interactions between the components (especially Acrobat integration into IE), and this leaves the system in a poor state (often wedged). Lower level OS bits keep responding to pings, but a hard boot is required to get anywhere useful. NT4 appeared a lot less robust with relatively frequent kernel crashes, whereas with XP my impression has been that the kernel itself is quite robust but the user shell and interface components are so tightly integrated with application behavior that application failure leaves them dead in the water. This is not disimilar to related failure modes on Mac OS X and using X11/KDE on BSD, and suggests maybe part of the problem is in the architecture of how we layer "system" applications over windowing mechanisms. Robert N M Watson ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd 5.3 Performance
Mark writes: M> Ah, this point fascinates me. Running for years? Do you ever have M> to recompile your kernel? :) Usually once when I first install the OS, then never again (unless I change something in the hardware, which I hardly ever do). Windows often has to be rebooted just to install a new application (although that's a problem with the application, not a problem with the OS, in most cases). But neither FreeBSD nor NT-based versions of Windows (which includes XP) crash on their own in the absence of hardware problems or buggy, privileged, third-party code (I'm thinking specifically of Windows device drivers here). -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Freebsd 5.3 Performance
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Anthony > Atkielski > Sent: Sunday, January 09, 2005 1:09 AM > To: freebsd-questions@freebsd.org > Subject: Re: Freebsd 5.3 Performance > > > Robert Watson writes: > > RW> All I know is that the XP bits don't crash every week, they > crash every > RW> three weeks. :-) My NT4 box crashed almost continuously. > > I have three machines, running FreeBSD, NT, and XP. All of them will > run until I boot them. They don't crash, or at least I can't remember > the last time I saw any of them crash (except for a hardware problem > that was crashing FreeBSD until I replaced the hardware). > > All of these operating systems are rock stable when used and > administered appropriately. I haven't had XP long enough to prove it, > but NT and FreeBSD will run for years without a boot in many cases. > Agreed, but this depends on what your doing with NT4. If your an ISP and your running NT4 or 2K or one of the Microsoft server platforms as a virtual host server for customers to use, then it is going to get stuffed up at least once every 3-4 months and have to be rebooted. And if a customer is writing their own ASP code then watch out! Crashes may occur daily! We know this from experience and we have several MCSE's on staff and run the stuff on Compaq Proliants, we know how to admin Microsoft products. Generally in an internal corporate setting where little changes on the server, once you have one of the Windows server platforms properly setup, as long as your using brand-name hardware, they will run for a long time without trouble. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd 5.3 Performance
> FreeBSD will run for years without a boot in many cases. Ah, this point fascinates me. Running for years? Do you ever have to recompile your kernel? :) Mark ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd 5.3 Performance
Robert Watson writes: RW> All I know is that the XP bits don't crash every week, they crash every RW> three weeks. :-) My NT4 box crashed almost continuously. I have three machines, running FreeBSD, NT, and XP. All of them will run until I boot them. They don't crash, or at least I can't remember the last time I saw any of them crash (except for a hardware problem that was crashing FreeBSD until I replaced the hardware). All of these operating systems are rock stable when used and administered appropriately. I haven't had XP long enough to prove it, but NT and FreeBSD will run for years without a boot in many cases. -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Freebsd 5.3 Performance
On Sat, 8 Jan 2005, Ted Mittelstaedt wrote: > > Entertainingly, at the company I work at, we only recently moved from > > Windows NT 4 to Windows XP, despite the dramatic improvements in Windows > > between those systems... > > dramatic improvements in XP over NT4? Robert, are you ill? ;-) > > Improvements, possibly, if your talking the eye candy on the interface, > but NT4 is loads faster on the same hardware than XP is. All I know is that the XP bits don't crash every week, they crash every three weeks. :-) My NT4 box crashed almost continuously. Robert N M Watson ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Freebsd 5.3 Performance
> -Original Message- > From: Robert Watson [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 08, 2005 4:26 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: Freebsd 5.3 Performance > > Entertainingly, at the company I work at, we only recently moved from > Windows NT 4 to Windows XP, despite the dramatic improvements in Windows > between those systems... dramatic improvements in XP over NT4? Robert, are you ill? ;-) Improvements, possibly, if your talking the eye candy on the interface, but NT4 is loads faster on the same hardware than XP is. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd 5.3 Performance
On Thu, 6 Jan 2005 [EMAIL PROTECTED] wrote: > In a message dated 1/6/05 4:51:10 AM Eastern Standard Time, [EMAIL PROTECTED] > writes: > > 4.10 *is* supported, and 5.3 works "as advertised" - what the hell is your > > *problem* exactly??? > Its been well documented that 5.3 does NOT work as advertised, and the > newest intel chipsets (not that new) don't work in 4.10, redering is useless > with the newer intel processors. To quote Robert watson of the Freebsd > core team who posted to this list on Nov 11, 2004: The statement you quote below does not mean that FreeBSD 5.3 is inappropriate for use in production, it rather means that with some workloads, FreeBSD 5.3 may show reduced performance over some earlier releaes. However, given that FreeBSD 4.x is in many cases the gold standard for network performance, and FreeBSD 5.x includes substantial rewrites of many sections of the kernel to support SMP better, some degradation in specific workloads at this point in the 5.x release life cycle isn't unexpected. My belief is that for the vast majority of FreeBSD installs, the performance costs will not be measurable -- in fact, in many interesting workloads, performance is dramatically improved. As I indicated in the quoted e-mail, the workloads particularly sensitive to the on-going performance work will be ones that are sensitive to small additional overhead, such as the high speed forwarding of many very small packets. And as I mentioned in my earlier e-mail, this is the continued topic of active development, with many improvements already present in the 5.x-STABLE branch. > " > FreeBSD 5.3 sees an observably higher per-packet processing costs than the > 4.x branch due to in-progress changes to the synchronization and queueing > models. Specifically, the SMPng work has changed the interrupt and > synchronization models throughout the kernel in order to increase > concurrency and preemptibility (i.e., lower latency in interrupt-based > processing). However, this has increaseed the overall overhead of > synchronization on the stack. The network stack forwarding path is > particularly sensitive to this, so while other parts of the system see > immediate concurrency benefits (i.e., socket-centric web servers that now > see less contention on SMP, and more preemption on UP), this path still > runs slower for many workloads. We're actively working to remedy this, > and you will see changes merged to the 6.x and 5.x branches over the next > couple of months that will cut into the numbers you see above by quite a > bit. Off the top of my head, I would have expected to see more around a > 15% overhead on UP for the workload you're seeing, but as you point out, > results can and do vary." > > 5.3 is not ready for production. 4.10 should be fully supported until it > is. The FreeBSD 4.x branches will be supported in production for quite some time in the future. However, only some releases are slated for "long life" maintenance, in order to reduce the testing and backporting workload and allow FreeBSD developers to focus their work more effectively. You can find detailed information on the planned support lifetimes of various releases on the FreeBSD Security Officer's web page. And, you'll see that changes and improvements continue to be merged to 4.x, albeit at a reduced pace, as we move forward. Merging large scale changes to 4.x doesn't make sense -- the effort is better invested in continuing to move forward on the 6.x and 5.x branches. However, as someone who anticipates having 4.x systems in production for years to come, I can promise we won't see things simply cease to be supported. I actually still have FreeBSD 3.x systems in production, as do many large consumers of FreeBSD... Entertainingly, at the company I work at, we only recently moved from Windows NT 4 to Windows XP, despite the dramatic improvements in Windows between those systems... Software seems to live a lot longer than one might think from the frantic software release rates of most application packages, etc. Robert N M Watson ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd 5.3 Performance
>The moment you start paying for development and support I'll agree with >you. Getting an incompetent like you to agree with me is so far from important that I can't help but smile about the thought of it ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd 5.3 Performance
On Jan 6, 2005, at 11:10 AM, [EMAIL PROTECTED] wrote: 5.3 is not ready for production. 4.10 should be fully supported until it is. TM The moment you start paying for development and support I'll agree with you. When I need a particularly low per packet cost such as a firewall I'll throw down some OpenBSD much as I hate to do it. On the other hand there are plenty of workloads I work with where FreeBSD 5 works great for me. Am I pissed as hell at that little NFS bug that's been floating around out there? Sure, but then I didn't drop the cash on a big Sun box to handle the load. While were at it, go look at what you get with Solaris these days. Sun's new OS can't fix the issues they are having with Sun's new hardware. With FreeBSD you have options 1) do the work yourself 2) live with it 3) use another OS that you are either paying for or not. In the mean time we all know you're not happy and none of us are capable of understanding the subtle and nuanced technical reasons why FreeBSD sucks. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd 5.3 Performance
[EMAIL PROTECTED] wrote: << snippage >> ***yaaawn*** Please don't feed the trolls. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Freebsd 5.3 Performance
In a message dated 1/6/05 4:51:10 AM Eastern Standard Time, [EMAIL PROTECTED] writes: > 4.10 *is* supported, and 5.3 works "as advertised" - what the hell is your > *problem* exactly??? Its been well documented that 5.3 does NOT work as advertised, and the newest intel chipsets (not that new) don't work in 4.10, redering is useless with the newer intel processors. To quote Robert watson of the Freebsd core team who posted to this list on Nov 11, 2004: " FreeBSD 5.3 sees an observably higher per-packet processing costs than the 4.x branch due to in-progress changes to the synchronization and queueing models. Specifically, the SMPng work has changed the interrupt and synchronization models throughout the kernel in order to increase concurrency and preemptibility (i.e., lower latency in interrupt-based processing). However, this has increaseed the overall overhead of synchronization on the stack. The network stack forwarding path is particularly sensitive to this, so while other parts of the system see immediate concurrency benefits (i.e., socket-centric web servers that now see less contention on SMP, and more preemption on UP), this path still runs slower for many workloads. We're actively working to remedy this, and you will see changes merged to the 6.x and 5.x branches over the next couple of months that will cut into the numbers you see above by quite a bit. Off the top of my head, I would have expected to see more around a 15% overhead on UP for the workload you're seeing, but as you point out, results can and do vary." 5.3 is not ready for production. 4.10 should be fully supported until it is. TM ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
