RE: SMP Performance (Was: Re: Are hardware vendors starting to bail ... )
On Thu, 13 Jul 2006, Tamouh H. wrote: I have to put my two cents here: 1) I agree with few posters that FreeBSD performance have been lacking behind. I've reported few issues on performance list and many did. We offered few pre-production servers for performance testing, but the answer we keep getting is: a. It is either your hardware sucks b. your benchmark application sucks 'k, here's to all the performance folks ... how should someone test performance? a. actually doesn't apply, as long as your performance testing is being done apples to apples as far as hardware is concerned ... if I create a dual-boot system, with FreeBSD 4.x and FreeBSD 6.x on a machine, and run *accepted performance / benchmark applications*, and compare those results, one would hope that 6.x performance fater/better then 4.x ... 2) Regarding SMP, few posts talked about disabling hyper-thread and SMP because it causes a performance degradation. On production hosting server, the experience was otherwise though. Without HT and SMP, the server would sky rocket in resource consumption. This has been tested on FBSD 5.4 i386 Personally, I've never found HT to be a performance boost, and I run 9 'production hosting servers' ... I can actually feel the difference between turning it on/off ... not sure what you mean by 'sky rocket in resource consumption', but all my Dual Xeon servers have HTT disabled, and I'm not noticing anything odd ... if you could elaborate on how you are seeing this, I can check on my machine to see if I see similar ... 3) I'm also frustrated like many with the rapid advancement in release jumps. We barely started 5.x to conclude it does not live up to expectations, so now 6.x is suppoused to be the good version, yet 7.x is going to come out soon and probably in less than a year 6.x will be considered inadequate. As to this one ... 5.x built up a very very bad reputation for itself, so basically 'skipping' that one makes sense ... I know I wouldn't trust a new version of 5.x coming out ... 6.x, other then the file system deadlocks which I'm trying to provide suitable DDB traces for, I've not noticed anything wrong with 6.x ... The jump from 6.x to 7.x does seem a bit ... quick ... but, then again, 7.x hasn't been released yet, and I think its safe to say that we all know that in software development, 'release estimates' are almost never accurate ... The problem, as I see it, is that until the OS gets used in real life production environments, some of the more obscure bugs don't get found ... on a simple production server, not doing much, I doubt anyone would ever see the file system deadlocks ... but, there are several of us that are running it in production with heavy loads that do ... but it takes a good load on the machine to trigger it, and I doubt any of the developers have that to work with, and/or can easily simulate the 'randomness' of a production environment ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP Performance (Was: Re: Are hardware vendors starting to bail ... )
On 2006-07-16 11:45, User Freebsd [EMAIL PROTECTED] wrote: The problem, as I see it, is that until the OS gets used in real life production environments, some of the more obscure bugs don't get found ... on a simple production server, not doing much, I doubt anyone would ever see the file system deadlocks ... but, there are several of us that are running it in production with heavy loads that do ... but it takes a good load on the machine to trigger it, and I doubt any of the developers have that to work with, and/or can easily simulate the 'randomness' of a production environment ... Well said! Very much to the point, with reasonable, realistic arguments, as always, Marc :) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
SMP Performance (Was: Re: Are hardware vendors starting to bail ... )
On Thu, 13 Jul 2006, Jerry McAllister wrote: On Jul 13, 2006, at 9:22 AM, Danial Thom wrote: Simply enabling SMP on a single processor system adds 20-25% overhead in freebsd 6.1. Again, readily admitted/accepted by the developers. There is no way to recover that in efficiency, at least not for a long time. So don't enable SMP on a single cpu system. Easy enough to avoid. Chad Why would anyone want to enable SMP on a single CPU system anyway. Actually, I believe all the new boot disks / ISOs are all SMP-enabled, so unless you build a custom kernel (some ppl do just run GENERIC ... I'm not one, mind you), you could be running an SMP-enabled kernel on a UP system without even knowing it ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: SMP Performance (Was: Re: Are hardware vendors starting to bail ... )
On Jul 13, 2006, at 9:22 AM, Danial Thom wrote: Simply enabling SMP on a single processor system adds 20-25% overhead in freebsd 6.1. Again, readily admitted/accepted by the developers. There is no way to recover that in efficiency, at least not for a long time. So don't enable SMP on a single cpu system. Easy enough to avoid. Chad Why would anyone want to enable SMP on a single CPU system anyway. Actually, I believe all the new boot disks / ISOs are all SMP-enabled, so unless you build a custom kernel (some ppl do just run GENERIC ... I'm not one, mind you), you could be running an SMP-enabled kernel on a UP system without even knowing it ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 I have to put my two cents here: 1) I agree with few posters that FreeBSD performance have been lacking behind. I've reported few issues on performance list and many did. We offered few pre-production servers for performance testing, but the answer we keep getting is: a. It is either your hardware sucks b. your benchmark application sucks 2) Regarding SMP, few posts talked about disabling hyper-thread and SMP because it causes a performance degradation. On production hosting server, the experience was otherwise though. Without HT and SMP, the server would sky rocket in resource consumption. This has been tested on FBSD 5.4 i386 3) I'm also frustrated like many with the rapid advancement in release jumps. We barely started 5.x to conclude it does not live up to expectations, so now 6.x is suppoused to be the good version, yet 7.x is going to come out soon and probably in less than a year 6.x will be considered inadequate. While I understand the development team is working hard to catch-up with technology and hats off to all the developers, why there is in my opinion no long term strategy for the base of the software. Thank you, Tamouh ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
