freebsd stable - May 2005 - Lifetime of FreeBSD branches

Could someone point me to a resource that outlines the expected supported
lifetime of all the branches? Can't find anything concrete on the webpage.

I'm developing a product, which i hope will run on FreeBSD. However the
rapid development of 5, and now 6 arriving out in a few months has me
worried if FreeBSD will be the right choice short and long term. I have
even considered using 4.11 for its stability and speed on single processor
systems, but I'm worried that some ports/hw will not be supported.

The recent amount of problems with 5 has me a little discouraged too, and
even considering Linux as an alternative. Hopefully that wont be the case,
but a clear outline of whats to come would be very helpful in the decision
making.

Thanks.

On Mon, May 23, 2005 at 03:21:32PM -0400, Mike Jakubik
wrote:
> Could someone point me to a resource that outlines the expected supported
> lifetime of all the branches? Can't find anything concrete on the
webpage.
http://www.freebsd.org/security/ - It's listed about 1/3 of the way down
the page in a table.

-- WXS

Mike Jakubik wrote:
> Could someone point me to a resource that outlines the expected supported
> lifetime of all the branches? Can't find anything concrete on the
webpage.
http://www.freebsd.org/security/

In addition to the material there (which is concerned with existing releases),
FreeBSD 5.x is expected to be supported until late 2007 (FreeBSD 5.5 plus two
years), and FreeBSD 6.x will probably be supported until early 2009 (the last
FreeBSD 6.x release plus two years).

Colin Percival

On Mon, May 23, 2005 at 03:21:32PM -0400, Mike Jakubik
wrote:
> Could someone point me to a resource that outlines the expected supported
> lifetime of all the branches? Can't find anything concrete on the
webpage.
> 
> I'm developing a product, which i hope will run on FreeBSD. However the
> rapid development of 5, and now 6 arriving out in a few months has me
> worried if FreeBSD will be the right choice short and long term. I have
> even considered using 4.11 for its stability and speed on single processor
> systems, but I'm worried that some ports/hw will not be supported.
The common wisdom has been that FreeBSD 4.11 is faster than 5.4 on
single processor systems.  Imagine my surprise when I went and
actually benchmarked this on the package build machines, and found
that 5.4 outperforms 4.11 by at least 10% when performing identical
workloads on identical UP hardware :-)

Stay tuned for more details...

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/20050523/5cef384c/attachment.bin

On Mon, May 23, 2005 3:51 pm, Kris Kennaway said:
> The common wisdom has been that FreeBSD 4.11 is faster than 5.4 on
> single processor systems.  Imagine my surprise when I went and actually
> benchmarked this on the package build machines, and found that 5.4
> outperforms 4.11 by at least 10% when performing identical workloads on
> identical UP hardware :-)
>
> Stay tuned for more details...
To be honest, i have not (yet) done any specific benchmarks for my
application, but overall, last time i used 4.x, it seemed more snappy.
But, this is good to hear :)

On May 23, 2005, at 3:51 PM, Kris Kennaway wrote:
> actually benchmarked this on the package build machines, and found
> that 5.4 outperforms 4.11 by at least 10% when performing identical
> workloads on identical UP hardware :-)
>
I have a pair of twin dual opteron boxes built about 1 month apart.   
One is about 5% faster than the other running 5.4-RELEASE-p1.  No  
idea why.

Vivek Khera, Ph.D.
+1-301-869-4449 x806

Mike Jakubik wrote:
> Could someone point me to a resource that outlines the expected supported
> lifetime of all the branches? Can't find anything concrete on the
webpage.
> 
> I'm developing a product, which i hope will run on FreeBSD. However the
> rapid development of 5, and now 6 arriving out in a few months has me
> worried if FreeBSD will be the right choice short and long term. I have
> even considered using 4.11 for its stability and speed on single processor
> systems, but I'm worried that some ports/hw will not be supported.
> 
> The recent amount of problems with 5 has me a little discouraged too, and
> even considering Linux as an alternative. Hopefully that wont be the case,
> but a clear outline of whats to come would be very helpful in the decision
> making.
> 
> Thanks.
> 
First of all, as the release engineer, I cannot stress enough that 6.0
is only an evolutionary step from 5.x.  It's natural to assume that
every major version change indicates major (and majorly destabilizing)
changes, but that is exactly what we are trying to get away from now.
When people ask what the future of 5.x is, my answer is "6.x" because
that's exactly what it is: a continuation and refinement of what we
did with 5.x, with a few needed architecture changes and features.

We are going to release 6.0 within the next few months, and 6.1 4
months after that.  There will be a 5.5 release inbetween there just
to wrap up that branch and provide users a bridge for 6.x.  I don't
expect there to be any 5.x releases after 5.5 because there simply
won't be anything left to offer in that branch that isn't in 6.x.

The 6.x transition will not have the handicaps that the 5.x transition
had for users.  It does not have a significantly different compiler
that requires major porting work for user applications.  It does not
have a dozen new experimental features that are still being debugged.
The only really new and experimental feature is the SMP VFS work, but
that has been undergoing a significant amount of testing, and it can
be turned off if need be.  This is in sharp contrast to 5.x that had
so many overlapping experimental areas that it was hard to test, isolate
and fix problems.

I think that we've gotten over most of the stability and performance
hurdles of 5.x.  We have a complete OS, not just a kernel, and it has
more components than the 4.x OS.  But despite that, most bugs reported
on this list seem to get solved fairly quickly, either with advice from
others or with a commit to the source tree.  We have a number of very
strong and very active ports and source tree committers that are doing a
very good job of refining the system, and I expect that to continue.
More bug reports are always welcome, and if you feel that there is a bug
that isn't getting attention that is critical for 6.0, email
re@FreeBSD.org about it, or email me personally.

As for performance, Kris has shown that the 5.x/6.x performance penalty
is now much more of a myth than reality. SMP on 6.x is significantly
more scalable and high performance than anything we've released before.
We are finally starting to see the benefits of our SMPng design.  Most
of the infrastructure work is done, so 6.x will be about refining it,
locking down more peripheral drivers and components, and tending to the
general details that have fallen behind in 5.x.  It's going to be a very
good release series.

I understand that there are some specific reasons for some people to
stick with 4.x.  There were people that stuck with 2.2.x back during
the 3.x and 4.x days because they also had specific needs.  I think
that this is fine if done for the right reasons, and I'm glad that those
people are willing to stick with FreeBSD instead of looking elsewhere.
However, if there is anything that we can do to help with the transition
forward to 5.x/6.x, please let me know.

Again, please don't take the abrupt switch to 6.0 to mean that 5.x is
flawed or that 6.x will also have a short lifespan.  The real purpose
of the switch is nothing but positive; it'll keep us focused and prevent
us from overreaching and overextending ourselves.  It's a very good
and very postive strategy.

Scott

On Tue, May 24, 2005 at 10:18:54PM +0200, Matthias Buelow
wrote:
> Max Laier wrote:
> 
> > I have seen this on my box.  Disabling one of the USB-ports solved the
> > problem.  I was seeing very high IRQ-rates.  Check $vmstat -i during
the
> > process to see if you have abnormal high rate jumps.  It might be that
we
> > must investigate some of our drivers to play nice with each other.
> 
> Interrupt rates were normal.
But are any IRQs shared?

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/20050524/323f4f4a/attachment-0001.bin

Kris Kennaway wrote:
> But are any IRQs shared?
Hmm... atapci1 is shared with fxp0 on irq 20.. does fxp0 also require
the giant lock?

mkb.

On Wed, May 25, 2005 at 07:26:31AM +0200, Matthias Buelow
wrote:
> Kris Kennaway wrote:
> 
> >Show me vmstat -i now.
> 
> interrupt                          total       rate
> irq1: atkbd0                         586          0
> irq13: npx0                            1          0
> irq14: ata0                           94          0
> irq17: wi0                            54          0
> irq20: fxp0 atapci1                62079         99
> irq21: uhci0 ehci0                     1          0
> irq22: uhci1                        1102          1
> lapic0: timer                    1246549       1994
> lapic1: timer                    1246427       1994
> Total                            2556893       4091
> 
> 
> The only relevant conflict I could see is irc 20; but I had already 
> tested that by removing fxp0 from the kernel.
I wonder if USB is causing the problem all on its own..since that was
the culprit in other situations when it was being triggered by virtue
of interrupt sharing.  Any chance you can try a non-USB mouse and
remove USB from your kernel?

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/20050524/0a386d04/attachment.bin