Hello, On Fri, 18 Mar 2005 22:16:05 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > -----Original Message----- > From: Nick Pavlica <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> > Cc: freebsd-questions@freebsd.org > Sent: Fri, 18 Mar 2005 19:45:44 -0700 > Subject: Re: FreeBSD 4.x Opteron Question > > :em1897, > : I'm curious how you are testing. In my testing, the 5.4 pre IP > :stack performed very well. I was able to get 100% more throughput > :than Linux (2.6.10 FC3) under heavy load on the exact same hardware. > :I was actually surprised at the difference because I have been a Linux > :Zellot for years. I didn't see any packet loss in my tests, but I do > :have good quality networking gear and servers. I was happy enough > :after my testing that I'm going to move my 4.x servers to 5.4 when > :it's released. I haven't tested dragonfly yet, but get all the > :performance I need out of FreeBSD. > : > :--Nick > > on a side note, I thought top posting was a no-no? I see gmail has the > same issues as AOL. Or are the issues with the old farts with their > newsreaders? :-) > > I don't get your logic. You are converting your servers from 4.x to 5.4 > because you've found that 5.4 is faster than linux? Is that some sort > of riddle? FreeBSD has always been faster than linux; I'm comparing > FreeBSD 4.x to 5.4, so I'm not sure what linux has to do with > anything here.
I guess I was a little vague :). I brought up Linux because you mentioned it in your earlier post, and wanted to share my results with it. Additionally, I have used Linux in many projects over the years and like to use it as a baseline of comparison. The point that I was trying to make was that I was getting good results with 5.4 in my tests. I have been pitting 4.x against 5.x since I began using FreeBSD for my projects. The 4.x series does have an excellent performance record that can't be questioned, however, 5.x gets the job done for me. > > What you can "get" in terms of throughput doesn't always give you > the right answer. My tests measure kernel performance; as I'm > interested in routing/packet-processing performance. Sockets add > a tricky variable. But I take the IP stack out of the equation > altogether > by bridging packets through a box, and I prefer to use a 50% load > as timings sometimes change when you start to saturate things > unnaturally. You won't be running your machine at 100% load, so > it makes no sense to test it that way. > > For the latest test I have a 3.06Ghz xeon bridging 486,000pps. > For FreeBSD 4.9, this is a 50% load. The load under 5.4 is 65%. > It tests interrupt and process switching performance, which for > a networking device is a key performance indicator. (I think) > that the 5.4 kernel is threaded, so there are latencies that > are very difficult to overcome. Linux has been threaded for > a long time, and always has been a poor Uniprocessor > performer. 5.4 is better than linux with one processor, > but if you are UP then > 4.x is clearly the way to go. Linux kills 5.4 with dual > processors; in fact 5.4 seems to have higher network > performance with 1 processor than 2. They still have > a lot of issues to work out. DragonflyBSD has done a > nice job with MP, but their performance is still a work > in progress. For UP, their performance is dismal so > its not quite where it needs to be, but its promising. > My tests are focused around simple network I/O and saturate all the other subsystems before making the kernel break a sweat, MP or UP. Curiously, all of my tests have never caused excessive CPU utilization on 5.x, and do seem to consume more CPU resources on 4.x. I was attributing this behavior to the scheduling and GIANT lock issues of 5.x . It's interesting to learn about your testing and that you are capable of stressing the Kernel so easily. The tests I perform I utilize my production and non production applications so that I could measure what the net affect of OS performance would be in my environment. I used to focus tests on more esoteric what if scenarios, even trying to optimize my code before it was done, etc. I have found over the years that performance is a tricky beast to catch. Being a performance junkie like myself tends to make me focus on the performance that I don't need rather than the performance that I do. I still think about the 400HP Camero that I drove to get groceries, and it still puts a smile on my face. > I just wish that they had done a 64-bit version of > 4.x. Because at the moment it seems that there is > no way to utilize the opteron fully without having > to use a slow version of the OS, which negates > the gains. Its a real shame. The bottom line in all of this is that 5.x and newer is where FreeBSD is going and 4.x and older is now legacy software weather we like it or not. In my mind this puts us in a postion to do one of the following: 1) Focus our efforts on 4.11 that's being replaced anyway. 2) Stop using FreeBSD and use Linux, Solaris, OpenBSD, ...... 3) Write our own OS that will solve all the worlds problems. 4) Accept the leadership and direction of the FreeBSD team and help them make 5.x and newer the OS that we know that it can be. Clearly option 4 is the best choice for FreeBSD and it's users for a number of reasons. The developers need people to use the software that they are working on so that they can improve it. In your case you could help the developers identify the performance issues that you are facing so that they can make improvements that would benefit you and all the other users that need routing/packet-processing performance. The dramatic changes made 5.x and newer can't be over stated. Essentially they are writing a new OS the hard way. They have to keep one foot behind while trying to move people forward with very few resources. I'm truly amazed that they have made it this far. Additionally, the core team chose to implement technologies that are technically superior, but are very difficult to implement. Even with the massive amount of resources that the Linux community has, they have opted to hold off on these types of technologies for easier solutions until they can implement them down the road. If we as a community, get on board with the developers we will ultimately be able to take advantage of these technologies, and will have a mature solution when other projects are just starting to go down this difficult journey. I didn't really realize this myself until recently and wanted to share my perspective. I know this has gotten of topic from the original post and I apologize for that. --Nick > > > On Fri, 18 Mar 2005 18:55:14 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]> > wrote: > > > > > > :Boris, > > : I would agree that my initial impression of 5.3 was that it was > slow > > :compared to 4.x. After some tuning, I now have 5.3 running at an > > :acceptable performance level. You may want to start testing the > newer > > :versions of 5 current. I have noticed improved performance on my > test > > :servers and believe that 5.4 will demonstrate an improvement in > > :performance. I know that the guys on the performance list would like > > :to get some good feedback if you find any specific bottlenecks with > it > > :as well. > > : > > :--Nick > > > > FYI, I recently testing bridging/network performance on 5.4-pre and > its > > about the same as 5.3: 25 to 30% more CPU load for the same traffic > > levels than 4.x. SMP drops packets at about 60% load and seems to > > have a lower capacity than UP. I'm sure some things are faster, but > > networking is a large component for most people I think. > > Threaded network stacks just don't seem to perform well, > > certainly not on UP. Linux MP works much better, but > > with 2 CPUs it has the capacity of FreeBSD 4.x with 1. > > So its hard to justify. > > > > FWIW, its quite a bit better with UP than DragonFLY, but > > dragonfly is much better with 2 processors. > > > > On Wed, 16 Mar 2005 14:51:43 -0800 (PST), Boris Spirialitious > > <[EMAIL PROTECTED]> wrote: > > > > > > --- cyb <[EMAIL PROTECTED]> wrote: > > > > http://www.freebsd.org/platforms/amd64.html > > > > > > > > Looks like you will need to use 5.3-release (or > > > > 5.3-stable/5.4-prerelease if you have more than > > > > 4GB). > > > > > > > > Why can you not use 5.3? > > > > > > 5.3 is too slow, and we have custom code. Why use > > > faster hardware just to use slower version of O/S? > > > Please don't start with flames. This is what I > > > feel. > > > > > > I don't need so much RAM, so 4.x will work with > > > 1 or 2GB of RAM? > > > > > > Boris > > > > > > > > > > > > > > > On Wed, 2005-03-16 at 09:43 -0800, Boris > > > > Spirialitious wrote: > > > > > --- Boris Spirialitious <[EMAIL PROTECTED]> > > > > > wrote: > > > > > > When opteron support start for Freebsd? I have > > > > 4.9. > > > > > > is supported? Or 4.11 better? I can't use 5.x. > > > > > > > > > > > > Will a i386 disk boot on opteron system? Can I > > > > > > use same disk image for intel and amd MBs? Any > > > > > > big problems? > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Boris > > > > > > > > > > Does anyone know answer please? Someone must use > > > > > Opteron here > > > > > > > > > > Boris > > > > > > > > -- > > > > GnuPG key : 0xD25FCC81 | > > > > http://cyb.websimplex.de/pubkey.asc > > > > Fingerprint: D182 6F22 7EEC DD4C 0F6E 564C 691B > > > > 0372 D25F CC81 > > > > > > > > > > > > > > > > > > > > > > __________________________________ > > > Do you Yahoo!? > > > Yahoo! Small Business - Try our new resources site! > > > http://smallbusiness.yahoo.com/resources/ > > > _______________________________________________ > > > 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]"
