Freebsd 5.3 Performance

[Robert Watson]

On Thu, 6 Jan 2005 Tm4528 at aol.com wrote:

> In a message dated 1/6/05 4:51:10 AM Eastern Standard Time, dave at horsfall.org 
> 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