Re: Article: Network performance by OS
Rik van Riel wrote: On Sat, 16 Jun 2001, Matt Dillon wrote: This is old. The guys running the tests blew it in so many ways that you might as well have just rolled some dice. There's a slashdot article on it too, and quite a few of the reader comments on these bozos are correct. I especially like comment #41. Don't worry, FreeBSD stacks up just fine in real environments. The only thing that worries me a bit is that both FreeBSD and Linux needed to be tuned at all to run these things, even if it was just the maximum file descriptor setting. A lot of this tuning could easily be done dynamically (and is done dynamically on linux 2.4), but lots of it still has static maximums which have to be tuned by hand. Compile-time tuning for stuff which can be dynamically allocated (and freed) is IMHO a big sillyness in the OS. Use of zalloci() permits allocations to occur at interrupt, such as allocations for replacement mbuf's in receive rings. It would be very difficult to maintain FreeBSD's GigaBit ethernet performance without this type of thing. One of the things that worries me about the new mbuf allocator is how it behaves with regard to lock inversion in a driver lock at interrupt time. I'm not saying there is definitely a problem, but this is really tricky code, and the lock manager has poor deadlock avoidance characteristics when it comes to inversion, since it does not allocate locks onto a DAG arc that would permit cycle detection among N processes with N+1 (or more) locks. Because the allocations as a result of a zalloci() zone occur through the use of a page fault against a preallocated and contiguous KVA range, there's really very little, short of a full rewrite, which would permit allocations to still occur at interrupt, while at the same time ensuring that the zone remained recoverable. Frankly, with a number of minor modifications, and a bunch more INVARIANTS code to guard against inversion, we could allocate KVA space for mbufs, sockets, tcpcb's, and inpcb's (and udpcb's, though they are not as important to me), and have some possibility of recovering them to the system. This would have the effect of rendering the memory no longer type stable, but if it meant we could continue to allocate at interrupt context, it would be worth having a clearner going behind emptying full buckets back to the system. Yes, this report was completely useless as a benchmark, but it DID highlight a point where Linux and BSD can be improved: dynamic allocation (and freeing) of things like file descriptors and socket structures. Many of these default limitations are intentional, both in terms of running out of KVA space (personally, I run with a 3G KVA space, which also limits user processes to 1G of space, which is opposite of the normal arrangement), and in terms of administration. Burning this space for zone allocations, you still need to come to a decision about what size to make each zone, given the limitations of zones, and the interrupt allocation requirement discussed above. From an administrative perspective, you have to make a trade-off on whether on not you can weather a denial of service attack which expolits a vulnerability, such as no default limitation on the number of sockets or open file descriptors a process is permitted to consume. In having no limitations on this, you open yourself to failure under what, under ordinary circumstances, would have to be considered grossly abnormal loads. I have done a number of Windows installs, and among other things, it will ask you to characterize the load you expect, which I am sure results in some non-defaults for a number of tuning parameters. Similarly, it has opportunity to notice the network hardware installed: if you install a GigaBit Ethernet card, it's probably a good be that you will be running heavy network services off the machine. If you install SCSI disks, it's a pretty good bet you will be serving static content, either as a file server, or as an FTP or web server. Tuning for mail services is different; the hardware doesn't really tell you that's the use to which you will put the box. On the other hand, some of the tuning was front-loaded by the architecture of the software being better suited to heavy-weight threads implementations. Contrary to their design claims, they are effectively running in a bunch of different processes. Linux would potentially beat NT on this mix, simply because NT has more things running in the background to cause context switches to the non-shared address spaces of other tasks. Put the same test to a 4 processor box with 4 NIC cartds, and I have no doubt that an identically configured NT box will beat the Linux box hands down. A common thread in these complaints that the results were somehow FreeBSD's fault, rather than the fault of tuning and architecture of the application being run, is, frankly, ridiculous. -- Terry To Unsubscribe: send mail to
Re: Article: Network performance by OS
Bosko Milekic wrote: On Sat, Jun 16, 2001 at 02:14:14PM -0700, Matt Dillon wrote: [ .. ] but all this benchmark proves (in regards to the TCP results) is that FreeBSD puts its foot down earlier then other OS's in regards to how much it is willing to dedicate to the network. In a real life situation [ ... ] This is the best written paragraph on the issue in this entire thread. This is exactly my philosophy toward the whole thing. And I can tell you from previous dealings with companies that use FreeBSD as their main platform that this is one of the main reasons why. I would be _extremely_ surprised if registry entries were not tweaked in the NT case as part of the InstallShield installation. In other words, it's a lack of software layering, and the installation of everything by default that somewhat hamper FreeBSD's ability to automatically tune itself better, on top of some early architectural decisions that are coming back to bite us now. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
On Tue, Jun 19, 2001 at 12:05:14PM -0700, Terry Lambert wrote: Use of zalloci() permits allocations to occur at interrupt, such as allocations for replacement mbuf's in receive rings. It would be very difficult to maintain FreeBSD's GigaBit ethernet performance without this type of thing. Actually, mbuf and cluster allocations are not done with the zone allocator. Similarily to the zone allocator, though, the KVA space is all present at initialization time, and allocations are all done from a dedicate submap of kmem_map, which ensures that we have the required address space. Allocations are then done via kmem_malloc() from the given mbuf map and if the address space isn't available, we know that we have consumed the available address space, so we return NULL immediately and we deal with the mbufs and clusters already allocated and in circulation all via the cache lists. The reason mbuf and cluster allocations are fast, even at interrupt time, is not only due to the map allocations having all KVA they need, but mainly due to the usage of of the cache lists. The new allocator takes this a step further by introducing per-CPU cache allocation lists. As for the GigaBit performance, well, it even has less to do with the mbuf and cluster allocation code, as I'm sure Bill Paul will proudly point out. :-) The gigabit drivers at this time all do their own jumbo buffer allocations [they need physically contiguous multi-page buffers] and, from what I've seen, they mostly use contigmalloc() [ick!]. Some of them pre-allocate the large buffers with contigmalloc() so as to prevent seeing more and more allocation difficulties as memory becomes fragmented. One of the things that worries me about the new mbuf allocator is how it behaves with regard to lock inversion in a driver lock at interrupt time. I'm not saying there is definitely a problem, but this is really tricky code, and the lock manager has poor deadlock avoidance characteristics when it comes to inversion, since it does not allocate locks onto a DAG arc that would permit cycle detection among N processes with N+1 (or more) locks. Have you seen the WITNESS code in -CURRENT? Because the allocations as a result of a zalloci() zone occur through the use of a page fault against a preallocated and contiguous KVA range, there's really very little, short of a full rewrite, which would permit allocations to still occur at interrupt, while at the same time ensuring that the zone remained recoverable. Well, as I said, we don't use zalloci() for mbufs and cluster (and never have, in fact) but we still do have the contiguous KVA range. Frankly, with a number of minor modifications, and a bunch more INVARIANTS code to guard against inversion, we could allocate KVA space for mbufs, sockets, tcpcb's, and inpcb's (and udpcb's, though they are not as important to me), and have some possibility of recovering them to the system. sockets do use the zone allocator and the KVA space is pre-allocated, as you say. This would have the effect of rendering the memory no longer type stable, but if it meant we could continue to allocate at interrupt context, it would be worth having a clearner going behind emptying full buckets back to the system. Shortly, as I previously mentionned, I plan to introduce a kproc for the mb_alloc system which will, once the general cache list hits X number of objects, go ahead and clear up Y pages worth of objects from the general list. This would allow for the wired-down pages to be unwired (and we would thus reclaim memory) while still keeping the pre-allocated KVA space and while not hampering on the speedy allocations and deallocations of mbufs and clusters (in fact, since the kproc would only touch the general list, both interrupt and non-interrupt allocations would likely still be occuring even while the cleaning up is being done). Many of these default limitations are intentional, both I agree. in terms of running out of KVA space (personally, I run with a 3G KVA space, which also limits user processes to 1G of space, which is opposite of the normal arrangement), and in terms of administration. Burning this space for zone allocations, you still need to come to a decision about what size to make each zone, given the limitations of zones, and the interrupt allocation requirement discussed above. Again, I agree. :-) From an administrative perspective, you have to make a trade-off on whether on not you can weather a denial of service attack which expolits a vulnerability, such as no default limitation on the number of sockets or open file descriptors a process is permitted to consume. In having no limitations on this, you open yourself to failure under what, under ordinary circumstances, would have to be considered grossly abnormal loads. I have done a number of Windows installs, and among other things, it will ask
Re: Article Network performance by OS
Dag-Erling Smorgrav([EMAIL PROTECTED])@2001.06.17 07:48:27 +:
Rik van Riel [EMAIL PROTECTED] writes:
Not quite. Linux distributions tend to be extremely
conservative in the IDE options (DMA, interrupt unmasking,
write caching, etc. all disabled) while FreeBSD seems to
have write caching and DMA on by default...
Ahem.
First of all, Linux' file system (ext2fs) is more or less equivalent,
in terms of performance and integrity, to async ffs. This gives Linux
a big performance edge out of the box, and FreeBSD a big reliability
edge - but benchmark authors rarely care about fs integrity, as
shutting off the power during heavy disk I/O isn't generally part of
their benchmark.
well, IMVHO, it should be ;-)
Second, we tried turning write caching on ATA drives off by default,
and boy were you (the user community) pissed. Yes, turning wc off
shows you just how crappy those non-tagged-queueing 4000 RPM ATA
drives you picked up at Fry's for some pocket change are. So we
turned it back on. If you're not happy with that, put 'hw.ata.wc=0'
in your /boot/loader.conf and they'll be off after the next reboot.
Or get real disks.
that's one for the handbook, eh? imagine:
Q: i got problem {...}, it seems to depend on (ATA|IDE|disk|drive|...)
A: get real hardware, you're running a production system, aren't you?
it would be a nice thing[tm] to have such stuff in the docs.
/k
--
Zero Defects, n.: The result of shutting down a production line.
KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie
http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/
karstenrohrbach.de -- alphangenn.net -- alphascene.org -- [EMAIL PROTECTED]
GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46
PGP signature
Re: Article Network performance by OS
On Mon, Jun 18, 2001 at 12:34:53PM +0200, Karsten W. Rohrbach wrote:
Dag-Erling Smorgrav([EMAIL PROTECTED])@2001.06.17 07:48:27 +:
Second, we tried turning write caching on ATA drives off by default,
and boy were you (the user community) pissed. Yes, turning wc off
shows you just how crappy those non-tagged-queueing 4000 RPM ATA
drives you picked up at Fry's for some pocket change are. So we
turned it back on. If you're not happy with that, put 'hw.ata.wc=0'
in your /boot/loader.conf and they'll be off after the next reboot.
Or get real disks.
that's one for the handbook, eh? imagine:
Q: i got problem {...}, it seems to depend on (ATA|IDE|disk|drive|...)
A: get real hardware, you're running a production system, aren't you?
it would be a nice thing[tm] to have such stuff in the docs.
Can we put your e-mail address below, to direct there all the feedback
from home users with IDE drives? :P
G'luck,
Peter
--
If I were you, who would be reading this sentence?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
Matt Dillon wrote: : But this isn't true at all. How many people need to make thousands : or tens of thousands of simultanious connections to a machine out of the : box? Almost nobody. So to run a benchmark and have it hit these : :You are essentially saying: out primary target market is small :servers. We can accomodate bigger loads as well but this may :require some hand tuning. On the other hand, NT's target market :is large servers, so it does not need tuning there but performs :worse in the smaller configurations. No, what I am essentially saying is that anyone who has a need to run something that sophisticated had better have some clue as to the platform he is using or he has no business running it. Even if the platform were tuned for the so-called 'large' installation, if the administrator doesn't know much about his most critical server the poor company that hired him is going to have a hellofalot more to worry about then the server not being magically tuned! I agree with that. By the way, is not it customary for the benchmarks run by magazines to consult the manufacturers if the testers are not able to configure the system by themselves ? I don't remember these guys asking questions on -hackers. And I will point out that NT is hardly optimized for 'large servers'. What, are you nuts? It took BEST Internet months... that's MONTHS... hundreds of man-hours to optimize an NT box to handle more then a handful of simultanious frontpage users and even then it couldn't even approach what one of our FreeBSD boxes was doing. It took HiWay Are you talking about Hotmail ? My understanding about it was that they run 5000 small servers, exactly the case when even an out-of-the-box FreeBSD will shine, not even speaking about a tuned one. Technologies another few months, *with* microsoft's help, to get their dedicated NT web server platform to even come close to what their SGI boxes were throwing out. It was a disaster all around. Optimized out of the box? I don't think so. An NT or W2K box might run on a 16-way system, and it may appear all rosy in contrived benchmarks, 32-way I think. At least that's what a full-blown Unisys ES7000 machine has and MS claims to support it. but in the real world it doesn't stack up. At least we (FreeBSD and Linux) don't pretend that our systems scale well to 16-way boxes... only Solaris (and now defunct SGI hardware) can make that claim. NT And Dynix and AIX and HP-UX and UnixWare. and W2K on a 16-way box would be a huge waste of money. Well, UnixWare runs circles around it on the same box. However FreeBSD does not scale well beyond 2 CPUs yet. Windows admins have odd ideas about what constitutes 'large'. Their idea of large is a rack full of windows boxes serving a few hundred active users, or maybe a colo-full of boxes serving a few thousand, or perhaps a bunch of expensive 4-way or 16-way cpu boxes to server X users. Nope, these SMP boxes are usually used for the database servers. The difficulty with the databases is that (unlike web servers or pop/smtp servers or other such stuff) you can't easily divide the job to an arbitrary number of small machines with a simple load balancer. The efficiency of interlocking and data exchange requires one big machine with large memory and many peripheral buses. Our idea of large (in this case defined by Terry or Paul Saab) is one FreeBSD box handling tens of thousands to a hundred thousand TCP connections, and a rack full of machine serving millions. Windows people conveniently forget the amount of work it takes to get an NT or W2K box operating, the amount of work it takes to upgrade one, and the amount of work it takes to fix one when something breaks. They don't fix, they reinstall (not that it reduces the amount of time but the contrariwise). -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
It's a lot faster on writes with softupdates enabled. FreeBSD will also have journaling filesystems soon. Either way, this was not a very good benchmark. On Sun, 17 Jun 2001, Rayson Ho wrote: But how much tuning is needed? You can download a kernel patch for VM, another kernel patch for FS... I am sure Linux can be even faster on an SMP machine with a Journaling FS (XFS, RFS, JFS, ext3, etc). Rayson --- Kenneth Wayne Culver [EMAIL PROTECTED] wrote: This is not really a hardcore networking app but a custom app written by the person who did the benchmark. The main reason that FreeBSD came in last was mostly because the guy didn't mount his filesystem correctly. On Sat, 16 Jun 2001, Matthew Hagerty wrote: Greetings, Here is a surprisingly unbiased article comparing OSes running hard core network apps. The results are kind of disturbing, with FreeBSD (4.2) coming in last against Linux (RH), Win2k, and Solaris (Intel). http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm The tests were performed against the TCP/IP implementation on these platforms with different system calls. File systems tests (EXT2 for Linux, UFS for FreeBSD and Solaris, and NTFS for Windows 2000) were performed by creating writing, and reading 10,000 files in the same directory, increasing the file size from 4K to 128K. Tests of various network applications based on number of simultaneous connections, process-based vs. thread-based, and sync vs. async connection handling were also performed. Hope it might be helpful to you... Matthew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message __ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article Network performance by OS
Rik van Riel [EMAIL PROTECTED] types: On Sat, 16 Jun 2001, Jonathan Fortin wrote: Linux is tuned out of the box, where the others are tuned for stability. Not quite. Linux distributions tend to be extremely conservative in the IDE options (DMA, interrupt unmasking, write caching, etc. all disabled) while FreeBSD seems to have write caching and DMA on by default... This doesn't agree with what was said about IDE write cache in Linux when it was toggled in FBSD. At that point, it was claimed that 1) Linux left the disk write cache in whatever state it found it in, and 2) most drives shipped with write cache enabled, just so they would peform well on benchmarks. In other words - it's generally on by default. On the other hand, all those other options can make a *lot* of difference. I've got some old tests I ran on 3.x wd driver with a brand new disk. Here's what bonnie says for one test with none of the go-fast options on: ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU wd100 2300 14.2 2285 6.7 1350 6.0 2499 17.7 2729 6.5 123.4 3.2 And here's what it says when you turn on UDMA and all those good things: ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU wd100 16841 88.5 15186 26.1 16610 38.2 21409 100.0 133543 100.0 3004.7 48.6 mike P.S. - no, I'm not presenting this as if it were a real benchmark. I just happened to have these numbers laying around as part of some other work I did. But the change is impressive. -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
On Sat, Jun 16, 2001 at 05:39:49PM -0400, Garance A Drosihn wrote: Mind you, I do agree that it would be very nice if we [the industry] could figure out benchmarking tactics which did not depend on the knowledge level of the person doing the benchmark. It would also be really nice to see lasting peace in every corner of the globe, but that also isn't going to happen without divine intervention. Getting back to benchmarks, the problem is that as soon as someone designs a benchmark, some members of the competition (the competition in whatever field is being benchmarked) sits down and figures out how to look good on that benchmark. The way that the SPEC organisation manages it (and has been doing a pretty good job on CPU/memory benchmarks over the years) is to work hard to make sure that the work done by the benchmark _is_ representative of the sorts of work that real people do with the sorts of systems where you're interested in CPU performance. That way, companies that figure out how to look good on the benchmark tend to actually make their platform behave well for a wide variety of applications. The other thing about SPEC benchmarks is that the interested parties benchmark themselves, and disclose their configurations, so that those reading the results can (a) reproduce them and (b) know what sorts of things that they should do if they want to make their own applications run as well as that. I remember that the last time this question arose, someone suggested raising a fund to buy (yes, the sad part of SPEC is that they sell the test suite to fund future developments) SpecWEB. How is that effort going, and do the folk who have volunteered to run it have access to suitably impressive hardware? (That last point is likely a stumbling block for either FreeBSD _or_ Linux. You can bet that if Microsoft wanted to win SpecWEB races they'd be able to buy better hardware than any group that's scratching to get $800 together...) For OS benchmarking, what we probably need is something like SpecWEB with Laser association(the sailing variety) one-design rules for the hardware. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
:... : to know the first thing about the platform he is running his software : on is a complete and utter idiot and the company that employs such a : person has a hellofalot more to worry about then the performance of an : untuned machine. : :We are telling people that FreeBSD is primarily a good server OS, :right ? Then it should come with the standard configuration tuned :with this purpose in mind. Not foolproof, not workstation but :high-performance server. : :IMHO this is a big problem with too many Unix (including Linux) :and generally Open Source programs and systems. They allow to :do great things after being properly tuned. However the default :configuration supplied with them is utterly horrible by some :mysterious reason. So the learning curve for them is quite steep But this isn't true at all. How many people need to make thousands or tens of thousands of simultanious connections to a machine out of the box? Almost nobody. So to run a benchmark and have it hit these limitations on an untuned machine and then say that this somehow proves that the boxes needed to be better-tuned out of the box is just plain and simply hogwash. Out of the box, FreeBSD (and Linux) work just fine for virtually anything you need to do, with very few exceptions. If you need to run a huge multi-gigabyte database, or you need to run an EFNET IRC server, or a USENET relay, or a SPAM mailer, then you have a bit of tuning work to do. Otherwise it will just work. We tune our default configurations for what most people need. We don't tune them to run stupid benchmarks. :and requires to learn the product in deep and tune it before :using. Well, I do enjoy learning things, however tuning the :same things in each new version over and over again for the 10th :time becomes quite boring. Nonsense. If you intend to work a machine to the hilt, and expect to maintain it for any length of time, and you aren't willing to spend some time tuning it, then the only thing wrong with the picture is *you*, Not the machine, Not the OS... but you. Don't blame your problems on the machine if you aren't willing to lift a finger learning how it works. -Matt :This is not to say that Windows is better: the default :configurations are usually slightly better but there is no :[reasonably easy] way whatsoever to make them decent. : :-SB To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article Network performance by OS
At 7:12 PM -0400 6/16/01, Jonathan Fortin wrote:
As for the benchmark briefly, It's biased because whoever did it knew fuck
nothing about Unix and Linux doesnt need tuning so Linux won period.
Linux is tuned out of the box, where the others are tuned for stability.
It gets far, far better than this. I misunderstood some of the
details of the article the first time I read it. It turns out that
the morons have written an SMTP MTA that keeps all writes in memory
and never flushes them to disk.
When the ignorance of RFCs and standards is at this intrastellar
level, you can forget everything you wanted to talk about with
regards to OS tuning. None of that means anything whatsoever, when
compared to a program that completely and totally violates the single
most fundamental principle of the standards.
The programmers may have known something about how an async,
poll()-based application can be written, but they very, very clearly
knew absolutely nothing whatsoever about writing an SMTP MTA.
Go home, the party's over. These guys are so bloody clue-free
that it's no longer worth the effort even contemplating the thought
of attempting to help them learn how things ought to be done.
--
Brad Knowles, [EMAIL PROTECTED]
/*efdtt.c Author: Charles M. Hannum [EMAIL PROTECTED] */
/* Represented as 1045 digit prime number by Phil Carmody */
/* Prime as DNS cname chain by Roy Arends and Walter Belgers*/
/* */
/* Usage is: cat title-key scrambled.vob | efdtt clear.vob*/
/* where title-key = 153 2 8 105 225 or other similar 5-byte key*/
dig decss.friet.org|perl -ne'if(/^x/){s/[x.]//g;print pack(H124,$_)}'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Article Network performance by OS
Brad Knowles writes: It gets far, far better than this. I misunderstood some of the details of the article the first time I read it. It turns out that the morons have written an SMTP MTA that keeps all writes in memory and never flushes them to disk. ... Go home, the party's over. These guys are so bloody clue-free that it's no longer worth the effort even contemplating the thought of attempting to help them learn how things ought to be done. SMTP cluefulness == benchmarking cluefulness ??? The default config is optimized for SPAM. They also offer: Crash-proof option. Makes sure that no message is lost in event of crash or power failure. Note: this feature slows performance. So clearly the developers know what they are supposed to do. With disk failure rates being what they are, and the uptime some people get, I don't think the normal MTA behavior helps very much anyway. It is an option though, just not the default. Marketing must love to say equal to 15 sendmail servers. Obviously these people want to sell a product, and they don't care what they have to do to make that product look good. Maybe they have more of a clue than you do, mixed with a bit of evil perhaps. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
Matt Dillon wrote: | Out of the box, FreeBSD (and Linux) work just fine for virtually | anything you need to do, with very few exceptions. If you need to | run a huge multi-gigabyte database, or you need to run an EFNET IRC | server, or a USENET relay, or a SPAM mailer, then you have a bit of | tuning work to do. Otherwise it will just work. We tune our default | configurations for what most people need. We don't tune them to run | stupid benchmarks. This is indeed the case. I've been running FreeBSD releases from the CD subscription service since 2.2.6 on my own network and all my customer networks. I do build a new kernel each time so that I can drop all the drivers that aren't needed (as that halves the kernel size), but that takes only a few minutes per release and is a no-brainer. And then those boxes just run and FreeBSD just works and the performance for those real world operations is excellent -- reliability is 100% and speed is such that users feel that they're getting instant responses. That's the only kind of benchmark that matters. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
Date: Sat, 16 Jun 2001 16:57:04 -0400 (EDT) From: Albert D. Cahalan [EMAIL PROTECTED] You mean they should just optimize for FreeBSD, or should they also use completion ports on Win2K, /dev/poll on Solaris, and RT signals on Linux? What is wrong with using the portable API on every OS? If you want an all-out performance test, use what's available. is fine to use fancy FreeBSD features. Otherwise no, it isn't OK. FreeBSD shouldn't need nonportable hacks to keep up with Win2K and Linux. Like mounting the volume async? :-P What size swap partition did they use? How hard is it to compile a custom kernel? What optimizations did they use on the respective compilers? You're sounding like a Microsoftie, demanding that code be written (Troll alert) to the latest OS-specific API to get decent performance. The decent performance issue has been addressed. For all-out performance, accept filters and kqueues are not that new. Not to mention that anyone using a kernel out of the box needs to be larted. If you run Google or Yahoo, sure. If the admin is really the guy hired to make web pages selling potted plants, no way. And I suppose that routers must also coddle the admin using FP, because it's too hard to filter bogons or configure netmasks by hand? BGP should be plug and play, eh? A certain amount of manual work is too much -- don't get me wrong. But there's a point where, if you want to be a network admin, you simply must know WTF you are doing. If an admin is too dumb to at least start tuning a system, will they know enough to asymmetrically encrypt sensitive info before storing it in a database? If not, I'm less than excited about buying from them. Anybody who needs a wizard, singing mouse, or dancing teddy bear to bind an IP address to a NIC scares me. Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article Network performance by OS
At 2:49 PM -0400 6/17/01, Albert D. Cahalan wrote:
So clearly the developers know what they are supposed to do.
No. Not when they claim that sendmail does precisely the same
thing, and I can easily demonstrate from the RELEASE_NOTES that this
changed in 8.10 (previously, I think sendmail checkpointed after
every ten recipients, but in order to prevent possible problems where
an error partway down the list could wind up with a copy of the
message being re-delivered every time to all recipients above the
problem one and after the last checkpoint, they changed SuperSafe to
be true).
With disk failure rates being what they are, and the uptime some
people get, I don't think the normal MTA behavior helps very much
anyway. It is an option though, just not the default.
Linux async mounts still trash filesystems. If you don't care
about that, that's fine. But then you've got no business writing an
article for a magazine like _SysAdmin_.
Obviously these people want to sell a product, and they don't care
what they have to do to make that product look good. Maybe they have
more of a clue than you do, mixed with a bit of evil perhaps.
You haven't been watching the responses from one of the authors
on the mailing list set up to discuss this article (as requested by
the folks at _SysAdmin_). He really is clearly clueless with regards
to benchmark tuning, FreeBSD in general, and proper operation of SMTP
MTAs.
I would invite you to send your own letter to the publishers of
_SysAdmin_, which will get forwarded to the mailing list, which you
will then probably be subscribed to. Then you can see the
cluelessness for yourself.
--
Brad Knowles, [EMAIL PROTECTED]
/*efdtt.c Author: Charles M. Hannum [EMAIL PROTECTED] */
/* Represented as 1045 digit prime number by Phil Carmody */
/* Prime as DNS cname chain by Roy Arends and Walter Belgers*/
/* */
/* Usage is: cat title-key scrambled.vob | efdtt clear.vob*/
/* where title-key = 153 2 8 105 225 or other similar 5-byte key*/
dig decss.friet.org|perl -ne'if(/^x/){s/[x.]//g;print pack(H124,$_)}'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
But how much tuning is needed? You can download a kernel patch for VM, another kernel patch for FS... I am sure Linux can be even faster on an SMP machine with a Journaling FS (XFS, RFS, JFS, ext3, etc). Rayson --- Kenneth Wayne Culver [EMAIL PROTECTED] wrote: This is not really a hardcore networking app but a custom app written by the person who did the benchmark. The main reason that FreeBSD came in last was mostly because the guy didn't mount his filesystem correctly. On Sat, 16 Jun 2001, Matthew Hagerty wrote: Greetings, Here is a surprisingly unbiased article comparing OSes running hard core network apps. The results are kind of disturbing, with FreeBSD (4.2) coming in last against Linux (RH), Win2k, and Solaris (Intel). http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm The tests were performed against the TCP/IP implementation on these platforms with different system calls. File systems tests (EXT2 for Linux, UFS for FreeBSD and Solaris, and NTFS for Windows 2000) were performed by creating writing, and reading 10,000 files in the same directory, increasing the file size from 4K to 128K. Tests of various network applications based on number of simultaneous connections, process-based vs. thread-based, and sync vs. async connection handling were also performed. Hope it might be helpful to you... Matthew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message __ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
: But this isn't true at all. How many people need to make thousands : or tens of thousands of simultanious connections to a machine out of the : box? Almost nobody. So to run a benchmark and have it hit these : :You are essentially saying: out primary target market is small :servers. We can accomodate bigger loads as well but this may :require some hand tuning. On the other hand, NT's target market :is large servers, so it does not need tuning there but performs :worse in the smaller configurations. No, what I am essentially saying is that anyone who has a need to run something that sophisticated had better have some clue as to the platform he is using or he has no business running it. Even if the platform were tuned for the so-called 'large' installation, if the administrator doesn't know much about his most critical server the poor company that hired him is going to have a hellofalot more to worry about then the server not being magically tuned! And I will point out that NT is hardly optimized for 'large servers'. What, are you nuts? It took BEST Internet months... that's MONTHS... hundreds of man-hours to optimize an NT box to handle more then a handful of simultanious frontpage users and even then it couldn't even approach what one of our FreeBSD boxes was doing. It took HiWay Technologies another few months, *with* microsoft's help, to get their dedicated NT web server platform to even come close to what their SGI boxes were throwing out. It was a disaster all around. Optimized out of the box? I don't think so. An NT or W2K box might run on a 16-way system, and it may appear all rosy in contrived benchmarks, but in the real world it doesn't stack up. At least we (FreeBSD and Linux) don't pretend that our systems scale well to 16-way boxes... only Solaris (and now defunct SGI hardware) can make that claim. NT and W2K on a 16-way box would be a huge waste of money. Windows admins have odd ideas about what constitutes 'large'. Their idea of large is a rack full of windows boxes serving a few hundred active users, or maybe a colo-full of boxes serving a few thousand, or perhaps a bunch of expensive 4-way or 16-way cpu boxes to server X users. Our idea of large (in this case defined by Terry or Paul Saab) is one FreeBSD box handling tens of thousands to a hundred thousand TCP connections, and a rack full of machine serving millions. Windows people conveniently forget the amount of work it takes to get an NT or W2K box operating, the amount of work it takes to upgrade one, and the amount of work it takes to fix one when something breaks. (remainder removed) -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Article: Network performance by OS
Greetings, Here is a surprisingly unbiased article comparing OSes running hard core network apps. The results are kind of disturbing, with FreeBSD (4.2) coming in last against Linux (RH), Win2k, and Solaris (Intel). http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm The tests were performed against the TCP/IP implementation on these platforms with different system calls. File systems tests (EXT2 for Linux, UFS for FreeBSD and Solaris, and NTFS for Windows 2000) were performed by creating writing, and reading 10,000 files in the same directory, increasing the file size from 4K to 128K. Tests of various network applications based on number of simultaneous connections, process-based vs. thread-based, and sync vs. async connection handling were also performed. Hope it might be helpful to you... Matthew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
: :Greetings, : :Here is a surprisingly unbiased article comparing OSes running hard core :network apps. The results are kind of disturbing, with FreeBSD (4.2) :coming in last against Linux (RH), Win2k, and Solaris (Intel). This is old. The guys running the tests blew it in so many ways that you might as well have just rolled some dice. There's a slashdot article on it too, and quite a few of the reader comments on these bozos are correct. I especially like comment #41. Don't worry, FreeBSD stacks up just fine in real environments. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
On Sat, 16 Jun 2001, Matt Dillon wrote: : :Greetings, : :Here is a surprisingly unbiased article comparing OSes running hard core :network apps. The results are kind of disturbing, with FreeBSD (4.2) :coming in last against Linux (RH), Win2k, and Solaris (Intel). This is old. The guys running the tests blew it in so many ways that you might as well have just rolled some dice. There's a slashdot article on it too, and quite a few of the reader comments on these bozos are correct. I especially like comment #41. Don't worry, FreeBSD stacks up just fine in real environments. Disagree wrt NFS services. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS Re: Article: Network performance by OS
I didn't believe my eyes windows is better than FreeBSD.. can't be true - Original Message -- From: Matt Dillon [EMAIL PROTECTED] To: Matthew Hagerty [EMAIL PROTECTED] Send: 06:56 PM Subject: Re: Article: Network performance by OS : :Greetings, : :Here is a surprisingly unbiased article comparing OSes running hard core :network apps. The results are kind of disturbing, with FreeBSD (4.2) :coming in last against Linux (RH), Win2k, and Solaris (Intel). This is old. The guys running the tests blew it in so many ways that you might as well have just rolled some dice. There's a slashdot article on it too, and quite a few of the reader comments on these bozos are correct. I especially like comment #41. Don't worry, FreeBSD stacks up just fine in real environments. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message ___ Palnet Webmail, http://www.palnet.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
Date: Sat, 16 Jun 2001 11:56:45 -0700 (PDT) From: Matt Dillon [EMAIL PROTECTED] This is old. The guys running the tests blew it in so many ways that you might as well have just rolled some dice. There's a slashdot article on it too, and quite a few of the reader comments on these bozos are correct. I especially like comment #41. Don't worry, FreeBSD stacks up just fine in real environments. If the programmers who wrote that software used poll() on FreeBSD 4.2, then I'd say that they need to RTFM and learn about kernel queues and accept filters. Not to mention that anyone using a kernel out of the box needs to be larted. Personally, I think that article casts more doubt on the authors than on FreeBSD... Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
On Sat, 16 Jun 2001, Matt Dillon wrote: This is old. The guys running the tests blew it in so many ways that you might as well have just rolled some dice. There's a slashdot article on it too, and quite a few of the reader comments on these bozos are correct. I especially like comment #41. Don't worry, FreeBSD stacks up just fine in real environments. The only thing that worries me a bit is that both FreeBSD and Linux needed to be tuned at all to run these things, even if it was just the maximum file descriptor setting. A lot of this tuning could easily be done dynamically (and is done dynamically on linux 2.4), but lots of it still has static maximums which have to be tuned by hand. Compile-time tuning for stuff which can be dynamically allocated (and freed) is IMHO a big sillyness in the OS. Yes, this report was completely useless as a benchmark, but it DID highlight a point where Linux and BSD can be improved: dynamic allocation (and freeing) of things like file descriptors and socket structures. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
With gratuitously non-standard quoting which I fixed, Matt Dillon writes: [Matthew Hagerty] Here is a surprisingly unbiased article comparing OSes running hard core network apps. The results are kind of disturbing, with FreeBSD (4.2) coming in last against Linux (RH), Win2k, and Solaris (Intel). This is old. The guys running the tests blew it in so many ways that you might as well have just rolled some dice. There's a slashdot article on it too, and quite a few of the reader comments on these bozos are correct. I especially like comment #41. Don't worry, FreeBSD stacks up just fine in real environments. Feel free to post a benchmarking procedure that would let one person produce fair results. Results ought to be reproducable: you, I, and an NT kernel developer all get the same answers. From another post where you tried to list the ways they blew it: If you intend to push a system to its limits, you damn well better be prepared to tune it properly or you are just wasting your time. On any operating system. You will never find joe-user running his system into the ground with thousands of simultanious connections and ten thousand files in a mail directory, so it's silly to configure the system from a joe-user perspective. So every FreeBSD server requires an expensive admin to tune it? That Win2K solution is looking good now. :-) These admins now... they never quit their job at just the wrong moment, people always have a hot-spare admin, or you think one can find and hire a really good admin as soon as needed? Nobody would ever have an unplanned demand that would run the system into the ground with thousands of simultanious connections and ten thousand files in a mail directory of course, especially when the admin isn't available. After all, the OS couldn't cope. Wait, wasn't this where FreeBSD was supposed to be really good while Linux and Win2K sucked? Hmmm, interesting. I guess it's fair to shove Linux deep into swap (as pro-FreeBSD benchmarkers always do), but not fair to make FreeBSD handle a large directory? Slashdot respondants did a pretty good job identifying the problems - network mbufs, softupdates, Robert here just brought up the possibility of IDE write caching being turned off, etc etc etc. The It was SCSI. Read the article. fact that the bozos doing the 'benchmark' knew about sysctl but only tuned the file descriptor limit is a pretty good indication of how biased they were. Biased against Win2K maybe, which beat FreeBSD without any tuning at all. FreeBSD got the same treatment as Solaris and Linux did. I'll bet they didn't even bother compiling up a kernel... something that is utterly trivial in a FreeBSD system, and if they did they certainly didn't bother tuning it. Lots of places would not allow this. Heavy tweaking requires heavy documentation to be reproducable by a future admin. It adds cost. There is a don't break anything concern. Every other system was in the same boat, so stop complaining. Linux got stuck with 2.2.16-22, even though it comes with friendly interactive kernel config editors. Go on, admit it. The benchmark was fair to FreeBSD, and you just don't like to see the results. BTW I'm serious about seeing your procedure for fair benchmarking. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
E.B. Dreger writes: If the programmers who wrote that software used poll() on FreeBSD 4.2, then I'd say that they need to RTFM and learn about kernel queues and accept filters. You mean they should just optimize for FreeBSD, or should they also use completion ports on Win2K, /dev/poll on Solaris, and RT signals on Linux? What is wrong with using the portable API on every OS? In an open competition where each team writes the code, sure, it is fine to use fancy FreeBSD features. Otherwise no, it isn't OK. FreeBSD shouldn't need nonportable hacks to keep up with Win2K and Linux. You're sounding like a Microsoftie, demanding that code be written to the latest OS-specific API to get decent performance. Not to mention that anyone using a kernel out of the box needs to be larted. If you run Google or Yahoo, sure. If the admin is really the guy hired to make web pages selling potted plants, no way. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
: If you intend to push a system to its limits, you damn well better : be prepared to tune it properly or you are just wasting your time. : On any operating system. You will never find joe-user running his : system into the ground with thousands of simultanious connections : and ten thousand files in a mail directory, so it's silly to : configure the system from a joe-user perspective. : :So every FreeBSD server requires an expensive admin to tune it? :That Win2K solution is looking good now. :-) : :These admins now... they never quit their job at just the wrong Huh? I'm talking about a reasonably smart 16 year old kid who bothers to spend a little time learning how a platform works. I don't know what you are talking about. Expensive sysadmin? Where did that come from? Any bozo with half a brain who has spent more then a week playing with FreeBSD in a serious way can tune it better then the idiots who ran the benchmark. A person who depends on the ability to run an out-of-the-box solution into the ground and actually expects it to perform well without having to know the first thing about the platform he is running his software on is a complete and utter idiot and the company that employs such a person has a hellofalot more to worry about then the performance of an untuned machine. The reality in the world is that most of these so-called benchmarks are meaningless. This one happens to be worse then normal, especially when the less informed masses start quoting them. People like me, who have actually HAD real unplanned loads smash into their FreeBSD boxes, know exactly how good FreeBSD is in handling those loads. No contrived benchmark can match real world results. I mean, give me a break, create and delete 10,000 files in a directory with softupdates turned off? The only time I ever had more then 10,000 queue files in a directory was running BEST, supporting 30,000+ users and some insanely huge mailing lists. Anyone actually running that kind of load had better be able to afford (or be) a sysop who at least knows his ass from a hot rock! -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
Albert D. Cahalan [EMAIL PROTECTED] types: I'll bet they didn't even bother compiling up a kernel... something that is utterly trivial in a FreeBSD system, and if they did they certainly didn't bother tuning it. Lots of places would not allow this. Heavy tweaking requires heavy documentation to be reproducable by a future admin. It adds cost. There is a don't break anything concern. Building a custom kernel on BSD isn't heavy tweaking, it's SOP. If you follow recommended practices, no documentation is required to make the results reproduceable on that system. If you have good admin procedures, then no documentation is required to reproduce the system on new hardware after the other is destroyed in a fire. Go on, admit it. The benchmark was fair to FreeBSD, and you just don't like to see the results. Ok, the bechmark was fair. To complete the trio(*), the Pope is a pagan and bears hold it until they're out of the woods. They didn't run all the systems in truly out of the box state, and didn't say *how* the selected what tuning they did. They didn't discuss the design goals of the systems, which are different and will influence the effect of measurements. This was a puff piece masquerading as a benchmark. mike *) Lies, damned lies and statistics. -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
:The only thing that worries me a bit is that both FreeBSD :and Linux needed to be tuned at all to run these things, :even if it was just the maximum file descriptor setting. : :A lot of this tuning could easily be done dynamically :(and is done dynamically on linux 2.4), but lots of it :still has static maximums which have to be tuned by hand. :Compile-time tuning for stuff which can be dynamically :allocated (and freed) is IMHO a big sillyness in the OS. : : :Yes, this report was completely useless as a benchmark, :but it DID highlight a point where Linux and BSD can be :improved: dynamic allocation (and freeing) of things :like file descriptors and socket structures. : :regards, : :Rik It's certainly true that a greater degree of dynamic tuning could be done, but all this benchmark proves (in regards to the TCP results) is that FreeBSD puts its foot down earlier then other OS's in regards to how much it is willing to dedicate to the network. In a real life situation where you may be running a multi-user load or a large database, the very last thing you want to do is shift every last bit of your resources away from the users or the database and to the network when an 'unexpected load' comes in (unexpected meaning something that is a factor of 100 or 1000x what the machine normally handles). The truth of the matter is that no amount of dynamic tuning can handle every situation... at some point you have to manually tune the box. FreeBSD does exactly the right thing on an untuned box by capping the network resources. If the authors want to run the machine into the ground with a benchmark, they have to tune the machine properly to handle the load because FreeBSD anyway is more interested in keeping the integrity of the machine as a whole together then it is tuning itself to match some idiot who thinks he is gods own gift to humanity running a benchmark. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
On Sat, Jun 16, 2001 at 02:14:14PM -0700, Matt Dillon wrote: It's certainly true that a greater degree of dynamic tuning could be done, but all this benchmark proves (in regards to the TCP results) is that FreeBSD puts its foot down earlier then other OS's in regards to how much it is willing to dedicate to the network. In a real life situation where you may be running a multi-user load or a large database, the very last thing you want to do is shift every last bit of your resources away from the users or the database and to the network when an 'unexpected load' comes in (unexpected meaning something that is a factor of 100 or 1000x what the machine normally handles). The truth of the matter is that no amount of dynamic tuning can handle every situation... at some point you have to manually tune the box. FreeBSD does exactly the right thing on an untuned box by capping the network resources. If the authors want to run the machine into the ground with a benchmark, they have to tune the machine properly to handle the load because FreeBSD anyway is more interested in keeping the integrity of the machine as a whole together then it is tuning itself to match some idiot who thinks he is gods own gift to humanity running a benchmark. This is the best written paragraph on the issue in this entire thread. This is exactly my philosophy toward the whole thing. And I can tell you from previous dealings with companies that use FreeBSD as their main platform that this is one of the main reasons why. -Matt Regards, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
At 4:31 PM -0400 6/16/01, Albert D. Cahalan wrote: Feel free to post a benchmarking procedure that would let one person produce fair results. Results ought to be reproducable: you, I, and an NT kernel developer all get the same answers. Nice ideal. Hard to imagine it happening any time soon. All of these OS's have their tricks when installing, and the person who knows the OS thinks nothing of those simple tuning issues. The person who doesn't know the OS wouldn't have a clue about the tuning. I have the feeling that this thread isn't going to generate much useful info, if the debate is going to include quasi- trolls like that. Mind you, I do agree that it would be very nice if we [the industry] could figure out benchmarking tactics which did not depend on the knowledge level of the person doing the benchmark. It would also be really nice to see lasting peace in every corner of the globe, but that also isn't going to happen without divine intervention. Getting back to benchmarks, the problem is that as soon as someone designs a benchmark, some members of the competition (the competition in whatever field is being benchmarked) sits down and figures out how to look good on that benchmark. So every FreeBSD server requires an expensive admin to tune it? That Win2K solution is looking good now. :-) We have windows servers here at RPI. They require expensive admins too. We're putting up an exchange server right now, and it's requiring more time, effort and resources to set up correctly than just about anything we've ever put up in Unix-land - even though some of our recent hires include good people who have a lot of experience with Windows (and almost none with Unix...). I am sure that for SOME companies in SOME environments, Win2K is setup right for them right out of the box. However, that does not hold true for all companies, all environments, or all usage-patterns. It just does not universally apply. Again, this seems more like a troll than any serious or even realistic discussion of the issues. My guess is that nothing much good is going to come from this thread, at the rate it's going. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
At 2:04 PM -0700 6/16/01, Matt Dillon wrote: :So every FreeBSD server requires an expensive admin to tune it? :That Win2K solution is looking good now. :-) : :These admins now... they never quit their job at just the wrong Huh? I'm talking about a reasonably smart 16 year old kid who bothers to spend a little time learning how a platform works. I don't know what you are talking about. I think he's talking about some of the characters in the upcoming Lord of the Rings movie trilogy, namely, 'the trolls'. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
On Sat, Jun 16, 2001 at 04:31:41PM -0400, Albert D. Cahalan wrote: I guess it's fair to shove Linux deep into swap (as pro-FreeBSD benchmarkers always do), but not fair to make FreeBSD handle a large directory? Well... no. This test did stress FreeBSD's ability to handle large directories, and that's fine. Especially since they didn't even bother to compare it to ReiserFS, which should be much better. However, they could have / should have leveled the playing field with one very simple tweak: *Mount all filesystems async* The tests merely tested the effect of the disk's ability to handle tagged queuing and the disk's ability to cache stuff. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
From: Albert D. Cahalan [EMAIL PROTECTED] Subject: Re: Article: Network performance by OS Date: Sat, 16 Jun 2001 16:31:41 -0400 (EDT) So every FreeBSD server requires an expensive admin to tune it? That Win2K solution is looking good now. :-) That says a lot about your selection criteria. I guess it's fair to shove Linux deep into swap (as pro-FreeBSD benchmarkers always do), but not fair to make FreeBSD handle a large directory? This is a foolish comparison. It's not all that rare to have a system suffer temporary (or even continuous) spikes in demand which cause it to go deep into swap whereas anyone stuffing tens of thousands of files into directory is simply an idiot who doesn't understand what databases are for. It's a serious apples-and-oranges comparison. Biased against Win2K maybe, which beat FreeBSD without any tuning at all. For this particular benchmark, yes. If you want a rather less contrived benchmark, why not compare Apache running under both Windows NT and FreeBSD/Linux/Solaris? It's available for all those platforms and given that you're running the same application, it would be a fair assumption that any difference in performance will be due to the OS itself and you'll also be able to stand by your benchmark as indicative of something people actually CARE about, namely web server performance. All this trolling merely reminds me of the benchmark paper presented a few USENIXes ago which showed Solaris to be almost a factor of 10 slower than Linux when calling getpid() 50,000 times in a row. Of course the comparison was also blatantly unfair since Solaris had extra lock overhead imposed by the fact that it was fully SMP capable whereas (at the time) Linux was not. Lies, damn lies, and statistics. You want fair benchmarking, there it is. Go put your money where your mouth all too frequently is, Albert. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
Hi Matt, follow ups to -chat On 16-Jun-01 Matt Dillon wrote: : If you intend to push a system to its limits, you damn well better : be prepared to tune it properly or you are just wasting your time. : On any operating system. You will never find joe-user running his : system into the ground with thousands of simultanious connections : and ten thousand files in a mail directory, so it's silly to : configure the system from a joe-user perspective. : :So every FreeBSD server requires an expensive admin to tune it? :That Win2K solution is looking good now. :-) : :These admins now... they never quit their job at just the wrong Huh? I'm talking about a reasonably smart 16 year old kid who bothers to spend a little time learning how a platform works. I don't know what you are talking about. Expensive sysadmin? Where did that come from? Any bozo with half a brain who has spent more then a week playing with FreeBSD in a serious way can tune it better then the idiots who ran the benchmark. Whilst I agree with your sentiment I would like to bring in the spectre of the real world. There are many diverse usage models in the world. The benchmark under discussion aims to rate various platforms running a package for ISPs. But, I wonder where the majority of FreeBSD/Unix boxes actually live? To take an example - where I work. We are an electronic engineering design consultancy and have a wide mix of projects. The basic IT infrastructure is Windows, a mix of W98, NT4 and W2k with a few Suns for IC design. We have about 200 people on site. The majority of IT support is NOT tuning the machines for best performance (whether it be W2k cross compiling for an embedded system or the Suns for IC design), but just keeping up with people needing a pool machine for a project or customer visit, fixing the switches when they blow up after a power cut, or restoring the Exhange databases...They don't even manage to find the time to recompile a Solaris kernel! Dynamic tuning would be ideal to help our IT get best performance out of NFS and Samba serving project data whilst also running Verilog/VDHL sims on the same box. I guess that this may never get to best performance for a given app, and, as such would not want to remove the possibility of tuning. A person who depends on the ability to run an out-of-the-box solution into the ground and actually expects it to perform well without having to know the first thing about the platform he is running his software on is a complete and utter idiot and the company that employs such a person has a hellofalot more to worry about then the performance of an untuned machine. I agree iff the business depends on the solution as its value prop. (e.g. ISP) but, I am sure that there are many more businesses that just use a box as tool to create their value prop. (e.g. an IC vendor). What do we do in those cases? They do not have the staff expertise to tune, to get the best out of the tens of applications that must be run to achieve the overall business goals. As a genuine question, does anyone have an idea of what the split of Suns/HPs /SGIs etc. is between internet/intranet server vs. work station on a desk is? -Matt Duncan --- Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. [EMAIL PROTECTED]| Steven King To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
For this particular benchmark, yes. If you want a rather less contrived benchmark, why not compare Apache running under both Windows NT and FreeBSD/Linux/Solaris? It's available for all those platforms and given that you're running the same application, it would be a fair assumption that any difference in performance will be due to the OS itself and you'll also be able to stand by your benchmark as indicative of something people actually CARE about, namely web server performance. I'm not convinced this is a fair test either, particularly unix vs windows, for 2 main reasons: 1) The Apache port has not recieved as much attention as the unix ports, in terms of development effort/time 2) Implementations of identical features may take radically different code paths, not all of which are equivilant in performance. There may indeed be better ways of implementing feature X on windows than on unix, but because it's a port, those implementations may not have been used. I'm not convinced there is any such thing as a fair benchmark, nor am I convinced that benchmarks are valuable. Clearly the benchmark cited is flawed, but what benchmark is not? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Article Network performance by OS
Hello, In order to perform a valid benchmark for stricly performance issues and let aside stability trade offs, A fair benchmark would be to purchase 3 exact systems, update BIOS, then deploy Linux, FreeBSD, and Windows2k. Tune them to the max, each perspective that could be modified to increase performance, then run silly write/read test, connect() test whatever. And in your test, show all the performance options you used and whatnot, and this benchmark should be redone periodly with new advices to show people what OS is the fastest when it's leg is pulled. As for the benchmark briefly, It's biased because whoever did it knew fuck nothing about Unix and Linux doesnt need tuning so Linux won period. Linux is tuned out of the box, where the others are tuned for stability. Thank you. Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article Network performance by OS
* Jonathan Fortin [EMAIL PROTECTED] [010616 19:13] wrote: Hello, In order to perform a valid benchmark for stricly performance issues and let aside stability trade offs, A fair benchmark would be to purchase 3 exact systems, update BIOS, then deploy Linux, FreeBSD, and Windows2k. Tune them to the max, each perspective that could be modified to increase performance, then run silly write/read test, connect() test whatever. And in your test, show all the performance options you used and whatnot, and this benchmark should be redone periodly with new advices to show people what OS is the fastest when it's leg is pulled. As for the benchmark briefly, It's biased because whoever did it knew fuck nothing about Unix and Linux doesnt need tuning so Linux won period. Linux is tuned out of the box, where the others are tuned for stability. Linux is not tuned out of the box, Linux just allows for just about any subsystem to monopolize the kernel resources. Basically when you start to stress multiple subsystems on a Linux box that isn't tuned properly it all goes to hell. This is because for example your network buffers might eat up too much memory for you to be able to do a reasonable job at caching files. Also, I really hate it when people say Linux's disk IO is fast compared to FreeBSD, sure it's fast, but at the expense of possible massive corruption on a crash. Oh wait, Linux doesn't crash, does it? :) -- -Alfred Perlstein [[EMAIL PROTECTED]] Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
At 6:37 PM -0400 6/16/01, Brian Mitchell wrote: I'm not convinced there is any such thing as a fair benchmark, nor am I convinced that benchmarks are valuable. Clearly the benchmark cited is flawed, but what benchmark is not? I must admit I (personally) have a major ambivalence towards benchmarks. I want to see them, I'm always interested in reading them, and yet at the end of the day I almost never really believe anything they say... Well, some ones I believe, if there are very few significant variables between the things being benchmarked. Comparing PowerPC 603's to PowerPC 603e's, for instance. Once you get to anything where you're changing cpu's AND os's AND compilers AND hardware AND hw configurations AND OS configuration experience, AND AND AND... well, it's just hopeless. At best they give you some ideas of what should be done differently in a follow-up benchmark, to maybe perhaps get a more valid comparison on that one. Not that I'll believe that one either, but I might at least think it's a better comparison. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
:a pool machine for a project or customer visit, fixing the switches when they :blow up after a power cut, or restoring the Exhange databases...They :don't even manage to find the time to recompile a Solaris kernel! : :Dynamic tuning would be ideal to help our IT get best performance out of NFS :and Samba serving project data whilst also running Verilog/VDHL sims on the :same box. I guess that this may never get to best performance for a given app, :and, as such would not want to remove the possibility of tuning. Why are you assuming that tuning takes a lot of effort? One good sysop is all you need. One man-week and then you are done. That's it. We aren't talking about having an entire department working 24x7 for a year tuning machines. We are talking about *ONE* person who tunes the machines on the side. The amount of effort required is zero... That is how it works on UNIX systems... Linux, FreeBSD, Solaris, whatever. Tuning a UNIX box is extremely easy to do and extremely easy to replicate. It doesn't matter whether you have one machine or a hundred. Not taking the time to tune your machines is roughly equivalent to running a 6 cylinder engine on 4 cylinders. This is true whether you are a small shop or a big shop, whether you are a startup or a fortune-500 company, whether your UNIX machines are servers or workstations. There is no 'if'. Anyone who depends on the default configuration of their systems and anyone who isn't willing to maintain them after they've been installed is throwing away money. Lots of money. It's that simple. If your IT department isn't up to the task then maybe you should consider firing them. -Matt :Duncan : :--- : :Duncan Barclay | God smiles upon the little children, To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
This is not really a hardcore networking app but a custom app written by the person who did the benchmark. The main reason that FreeBSD came in last was mostly because the guy didn't mount his filesystem correctly. On Sat, 16 Jun 2001, Matthew Hagerty wrote: Greetings, Here is a surprisingly unbiased article comparing OSes running hard core network apps. The results are kind of disturbing, with FreeBSD (4.2) coming in last against Linux (RH), Win2k, and Solaris (Intel). http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm The tests were performed against the TCP/IP implementation on these platforms with different system calls. File systems tests (EXT2 for Linux, UFS for FreeBSD and Solaris, and NTFS for Windows 2000) were performed by creating writing, and reading 10,000 files in the same directory, increasing the file size from 4K to 128K. Tests of various network applications based on number of simultaneous connections, process-based vs. thread-based, and sync vs. async connection handling were also performed. Hope it might be helpful to you... Matthew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article Network performance by OS
On Sat, 16 Jun 2001, Jonathan Fortin wrote: Linux is tuned out of the box, where the others are tuned for stability. Not quite. Linux distributions tend to be extremely conservative in the IDE options (DMA, interrupt unmasking, write caching, etc. all disabled) while FreeBSD seems to have write caching and DMA on by default... Both systems have tuning out of the box in different ways. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
Greetings All, I just wanted to thank everyone for the responses! I did not mean to start such a debated thread. I'm glad to have the information about why FreeBSD place so poorly in these idiot's tests. I'll have to write SysAdmin a letter now and ask them why the hell they would publish such an article. I hope I'm not wasting my money subscribing to the magazine... Again, thank you all for the information! I have been using FreeBSD since Release-1.1 (I downloaded the binary install disks via AOL!!) and have used every version since. I have also tried Solaris, Linux, BSDI, Windows, and NetBSD, but I keep coming back to FreeBSD. One day I hope to be able to contribute my share as well. Thanks, Matthew At 02:42 PM 6/16/2001 -0400, Matthew Hagerty wrote: Greetings, Here is a surprisingly unbiased article comparing OSes running hard core network apps. The results are kind of disturbing, with FreeBSD (4.2) coming in last against Linux (RH), Win2k, and Solaris (Intel). http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm The tests were performed against the TCP/IP implementation on these platforms with different system calls. File systems tests (EXT2 for Linux, UFS for FreeBSD and Solaris, and NTFS for Windows 2000) were performed by creating writing, and reading 10,000 files in the same directory, increasing the file size from 4K to 128K. Tests of various network applications based on number of simultaneous connections, process-based vs. thread-based, and sync vs. async connection handling were also performed. Hope it might be helpful to you... Matthew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article Network performance by OS
Rik van Riel [EMAIL PROTECTED] writes: Not quite. Linux distributions tend to be extremely conservative in the IDE options (DMA, interrupt unmasking, write caching, etc. all disabled) while FreeBSD seems to have write caching and DMA on by default... Ahem. First of all, Linux' file system (ext2fs) is more or less equivalent, in terms of performance and integrity, to async ffs. This gives Linux a big performance edge out of the box, and FreeBSD a big reliability edge - but benchmark authors rarely care about fs integrity, as shutting off the power during heavy disk I/O isn't generally part of their benchmark. Second, we tried turning write caching on ATA drives off by default, and boy were you (the user community) pissed. Yes, turning wc off shows you just how crappy those non-tagged-queueing 4000 RPM ATA drives you picked up at Fry's for some pocket change are. So we turned it back on. If you're not happy with that, put 'hw.ata.wc=0' in your /boot/loader.conf and they'll be off after the next reboot. Or get real disks. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
