Real "technical comparison"
This "postmark" test is useless self flagellation. The intent of the "test" is obviously intended to show certain facts which we all know to be self-evident under strange load conditions which are patently "unreal". We already knew the limitations on putting many files in a directory; the only useful thing you could do with that many files in a single directory is to iterate them all. If the application were trying to "remember" 60,000 path names, we are talking about 60MB of RAM, just for the potential top end path data alone, not including the linked list pointers for a simple linked list approach. I would suggest a better test would be to open _at least_ 250,000 connections to a server running under both FreeBSD and Linux. I was able to do this without breaking a sweat on a correctly configured FreeBSD 4.3 system. Even if all the clients were simultaneously active, on a single Gigabit NIC, that's still in excess of 4 kilobits a second per client. This could easily be the case with, for example, a pager network or other content broadcasting system, or an EAI tool, such as IBM's MQ-Series. It seems to me that this would be a much more real-world scenario than some badly written third party code acting in the worst possible way with FS contents. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Real "technical comparison"
On Wed, 30 May 2001, Terry Lambert wrote: > The intent of the "test" is obviously intended to show > certain facts which we all know to be self-evident under > strange load conditions which are patently "unreal". > I would suggest a better test would be to open _at least_ > 250,000 connections to a server That would certainly qualify for the "patently unreal" part, but I don't know what else you want to prove here. > This could easily be the case with, for example, a pager > network or other content broadcasting system, or an EAI > tool, such as IBM's MQ-Series. Doing a gigabit per second in 3kB per second connections doesn't seem all that realistic when you realise that they'll want their messages only acknowledged when they are safely on disk, etc... Think "transactions". 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: Real "technical comparison"
> This "postmark" test is useless self flagellation. The benchmark tests what it was meant to test: performance on huge directories. > The intent of the "test" is obviously intended to show > certain facts which we all know to be self-evident under > strange load conditions which are patently "unreal". That apps designed with UFS in mind don't usually create such directories is irrelevant. Those that do are being pushed past their original design, which does happen! > We already knew the limitations on putting many files > in a directory; the only useful thing you could do with > that many files in a single directory is to iterate them > all. If the application were trying to "remember" 60,000 > path names, we are talking about 60MB of RAM, just for > the potential top end path data alone, not including the > linked list pointers for a simple linked list approach. Some people think 60 MB of RAM is tiny. > I would suggest a better test would be to open _at least_ > 250,000 connections to a server running under both FreeBSD > and Linux. I was able to do this without breaking a sweat > on a correctly configured FreeBSD 4.3 system. > > Even if all the clients were simultaneously active, on a > single Gigabit NIC, that's still in excess of 4 kilobits a > second per client. > > This could easily be the case with, for example, a pager > network or other content broadcasting system, or an EAI > tool, such as IBM's MQ-Series. How about a real benchmark? At www.spec.org I see SPECweb99 numbers for Solaris, AIX, Linux, Windows, Tru64, and HP-UX. FreeBSD must be hiding, because I don't see it. BSDI, Walnut Creek, and WindRiver all have failed to submit results. (the cost is just loose change for WindRiver) Linux is still #1 for 1 to 4 processors. The 8-way results need to be redone on newer hardware (Windows is ahead now) and Linux doesn't have 6-way or 12-way numbers. Go on, show some numbers. Stop hiding. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Real "technical comparison"
Rik van Riel wrote: > > On Wed, 30 May 2001, Terry Lambert wrote: > > > The intent of the "test" is obviously intended to show > > certain facts which we all know to be self-evident under > > strange load conditions which are patently "unreal". > > > I would suggest a better test would be to open _at least_ > > 250,000 connections to a server Depends on your environment. I've had freebsd 4.x machines with 125k active connections from real http users. The load average was up around 30, and the pty response was a little slow, but the user experience was just as snappy as you'd like, thank you very much. FreeBSD frequently leads the industry in most connections per machine. Back in '96 I held the record across all IRC networks for most concurrent connections for 8 months, peaking at 5,300. We would have had more, except our ircd sucked. :) Using my config and a vastly improved ircd they blew by me on efnet with first 8k, then 10k before the bandwidth cost got to be too much. My point is, you never push the limits unless you push the limits. :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Real "technical comparison"
In article <[EMAIL PROTECTED]> you wrote: > On Wed, 30 May 2001, Terry Lambert wrote: >> I would suggest a better test would be to open _at least_ 250,000 >> connections to a server > > That would certainly qualify for the "patently unreal" part, but I don't > know what else you want to prove here. Thank you for not telling it to one of my servers which is running around with about 10 concurrent connections biting its tail. I wouldn't like to hurt its feelings. And I've got the feeling that it will have to bear a bit more of that beating. Noses. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Real "technical comparison"
On Wed, 30 May 2001, Albert D. Cahalan wrote: > > I would suggest a better test would be to open _at least_ > > 250,000 connections to a server running under both FreeBSD > > and Linux. I was able to do this without breaking a sweat > > on a correctly configured FreeBSD 4.3 system. > > How about a real benchmark? Good question indeed. All proposed benchmarks in this thread have been geared heavily towards one system or the other and are not at all "industry standard" benchmarks. > At www.spec.org I see SPECweb99 numbers for Solaris, AIX, > Linux, Windows, Tru64, and HP-UX. FreeBSD must be hiding, > because I don't see it. BSDI, Walnut Creek, and WindRiver > all have failed to submit results. > Linux is still #1 for 1 to 4 processors. The 8-way results > need to be redone on newer hardware (Windows is ahead now) > and Linux doesn't have 6-way or 12-way numbers. Last I heard the 8-way result with Windows had an "NC" (not qualified) next to it. OTOH, Linux' 8-way numbers still leave a lot to be desired ... > Go on, show some numbers. Stop hiding. *nod* We can all brag about our performance being better than the others, but unless some actual numbers on a standardised benchmark are being published, it's nothing more than just bragging and bullshitting each other. If FreeBSD's performance is as good as people say (which I'm not doubting, at least as far as the realistic claims go), then where are those impressively high specweb numbers? ;) 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: Real "technical comparison"
On Thu, 31 May 2001, Noses wrote: > Thank you for not telling it to one of my servers which is running > around with about 10 concurrent connections biting its tail. I > wouldn't like to hurt its feelings. And I've got the feeling that it > will have to bear a bit more of that beating. Interesting, what's that thing doing ? Mmm, now that I think of it, at least one company wants to run a stateful firewall & VPN endpoint with well over 128.000 connections too (and on Linux 2.4, even ... this would be an interesting thing to test). 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: Real "technical comparison"
It seems Rik van Riel wrote: > > At www.spec.org I see SPECweb99 numbers for Solaris, AIX, > > Linux, Windows, Tru64, and HP-UX. FreeBSD must be hiding, > > because I don't see it. BSDI, Walnut Creek, and WindRiver > > all have failed to submit results. > > > Linux is still #1 for 1 to 4 processors. The 8-way results > > need to be redone on newer hardware (Windows is ahead now) > > and Linux doesn't have 6-way or 12-way numbers. > > Last I heard the 8-way result with Windows had an "NC" > (not qualified) next to it. OTOH, Linux' 8-way numbers > still leave a lot to be desired ... > > > Go on, show some numbers. Stop hiding. > > *nod* If somebody sends me the 800 US$ the software costs, or better get me the software for free (we are a free OS right) I'll gladly run it through a variety of machines here... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Real "technical comparison"
On Thu, 31 May 2001, Søren Schmidt wrote: > If somebody sends me the 800 US$ the software costs, or better > get me the software for free (we are a free OS right) I'll gladly > run it through a variety of machines here... If you think this is the problem, I'll happily chip in $50; it would be interesting to see some numbers... Note that I'll drop offline for a week or so now, I'll be unplugging my laptop in a minute to display my gf's lecture's slides and then I'll be off for holidays ;) 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: Real "technical comparison"
Rik van Riel wrote: > > On Wed, 30 May 2001, Terry Lambert wrote: > > > The intent of the "test" is obviously intended to show > > certain facts which we all know to be self-evident under > > strange load conditions which are patently "unreal". > > > I would suggest a better test would be to open _at least_ > > 250,000 connections to a server > > That would certainly qualify for the "patently > unreal" part, but I don't know what else you > want to prove here. I have a system ready to go to production that has been tested well in excess of that number of connections. My numbers over 250,000 are currently classified by the people paying me to do the work. You may remember when I found and fixed the cred structure reference count rollover at 32,7xx network connections, in 4.3, recently. That was for this project. > > This could easily be the case with, for example, a pager > > network or other content broadcasting system, or an EAI > > tool, such as IBM's MQ-Series. > > Doing a gigabit per second in 3kB per second connections > doesn't seem all that realistic when you realise that > they'll want their messages only acknowledged when they > are safely on disk, etc... Think "transactions". Consider that HTTP 1.1 persistant connections are frequently idle, as users view the pages they downloaded. In many applications, the speed is determined by the human needing to assimilate the information, which was presented quickly. Given average statistics on latency between page loads on browsers with humans attached to them, I rather expect that an HTTP 1.1 server that served 250,000 connections would have no trouble statistically keeping up with T1 speeds, for the full 250,000 connections; that's about the highest possible DSL rate, assuming your house was next door to the LATE. This is just a real-world example that a layman would be expected to intuitively understand, if they couldn't understand the pager network or content broadcasting system real-world examples. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Real "technical comparison"
"Albert D. Cahalan" wrote: > > > This "postmark" test is useless self flagellation. > > The benchmark tests what it was meant to test: performance > on huge directories. Which is useless, since only degenerate software results in huge directories. I have yet to see one example of software which would result in this degenerate case, for which there was not more modern software providing at least equivalent functionality being generally available. Unless you want to count the "postmark" program itself. > > The intent of the "test" is obviously intended to show > > certain facts which we all know to be self-evident under > > strange load conditions which are patently "unreal". > > That apps designed with UFS in mind don't usually create > such directories is irrelevant. Those that do are being > pushed past their original design, which does happen! Only 5% of computer systems currently in use have FSs capable of not "failing" this test: o AIX systems with JFS o SGI systems with XFS o Obsolete OS/2 systems with JFS o Obsolete OS/2 systems with HPFS o Obsolete NT 1.x and 2.x systems with HPFS o Experimental Linux systems with the incompletely implemented XFS o Experimental Linux systems with the incompletely implemented ReiserFS o Experimental FreeBSD systems with the incompletely implemented XFS o Experimental FreeBSD systems with my patches from 1995 for trie-structured directory storage for Berkeley FFS o FreeBSD systems running IFS (Inode FS), where there are no directory entries, and everything is by inode number On the other hand, we have: SVR3 UFS; SVR4 UFS; SVR4 VxFS (Veritas); Solaris VxFS; SVR4 NWFS; DOS FAT; DOS FAT16; VFAT; VFAT32; NTFS; AFS; CODA; NFSv1; NFSv2; NFSv3; NFSv4; Mac HFS; ExtFS; Ext2FS; Ext3FS; EFS; EmFS; LFS; SpriteFS; AdvFS; RFS; TFS; SFS; HRFS; DTFS; MFS; FlFS; SVFS; SV1KFS; Acer Fast FS; Xenix FS; BFS; IFS; etc.. I could go on... are you getting the picture? Only a moron implements his code to run only on marginal platforms. If you are implementing commercial code, you often only know the developement environment, not the target environment. You might as well write your code without bzero'ing your sockaddr_in structs before using them "because everything is Linux". > Some people think 60 MB of RAM is tiny. Count me as one of them. I use ~64MB of RAM for just the mbuf per connection that is used to contain "struct tcptemp"'s _just in case I need to send keepalives_, for my example of 250,000 connections on my production server which actually _does_ support this many connections. Your 60MB would leave me with only enough memory to eke out a mere 15,625 connections. > How about a real benchmark? > > At www.spec.org I see SPECweb99 numbers for Solaris, AIX, > Linux, Windows, Tru64, and HP-UX. FreeBSD must be hiding, > because I don't see it. BSDI, Walnut Creek, and WindRiver > all have failed to submit results. > > (the cost is just loose change for WindRiver) I don't represent WindRiver. If you would care to front me the $US 800, I would be happy to run those tests, if they happen to be your favorites. Until then, my benchmark is what I can achieve on real hardware in a real application. [ ... "show some numbers" ... ] I did: 250,000 simultaneous connections; and that's not nearly what I've actually achieved, merely what I choose to disclose. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Real "technical comparison"
Rik van Riel wrote: > > How about a real benchmark? > > Good question indeed. All proposed benchmarks in this thread > have been geared heavily towards one system or the other and > are not at all "industry standard" benchmarks. > > > At www.spec.org I see SPECweb99 numbers for Solaris, AIX, > > Linux, Windows, Tru64, and HP-UX. FreeBSD must be hiding, > > because I don't see it. BSDI, Walnut Creek, and WindRiver > > all have failed to submit results. The problem with this, as has already been pointed out, is US$800; this is a volunteer project: are you volunteering? > > Go on, show some numbers. Stop hiding. > > *nod* > > We can all brag about our performance being better than > the others, but unless some actual numbers on a standardised > benchmark are being published, it's nothing more than just > bragging and bullshitting each other. Alll I really give a damn about is making my application work; I could never do that without a source-available OS for which my strategic modifications do not have to be released in source form, so that basically limits my choices considerably. > If FreeBSD's performance is as good as people say (which I'm > not doubting, at least as far as the realistic claims go), > then where are those impressively high specweb numbers? ;) I have posted a really cut down version of my real application requirements as a proposed benchmark. If you want high SpecWeb numbers, you should look at the AfterBurner Web server, which, AFAIK, has only ever run on FreeBSD. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Real "technical comparison"
Rik van Riel wrote: > > Thank you for not telling it to one of my servers which is running > > around with about 10 concurrent connections biting its tail. I > > wouldn't like to hurt its feelings. And I've got the feeling that it > > will have to bear a bit more of that beating. > > Interesting, what's that thing doing ? > > Mmm, now that I think of it, at least one company wants to > run a stateful firewall & VPN endpoint with well over 128.000 > connections too (and on Linux 2.4, even ... this would be an > interesting thing to test). Unfortunately, my test code is proprietary, as it relies on some deep (and hard won) knowledge of the BSD stack. It's pretty trivial to build code that can run on 25 client machines tuned to 10,000 fd's each, and a server that just forks and accepts connections will leave you some idea of how much remaining capability there is on your target server, after tuning, to do actual work. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Real "technical comparison"
In article <[EMAIL PROTECTED]> you wrote: >> Thank you for not telling it to one of my servers which is running >> around with about 10 concurrent connections biting its tail. I >> wouldn't like to hurt its feelings. And I've got the feeling that it >> will have to bear a bit more of that beating. > > Interesting, what's that thing doing ? Grabing stuff from a number of database servers, combining it, turning it into HTML-documents (including converting graphics formats) and handing them off to the web servers which requested it. Which is causing a nice mix of network load and computations. And no, the server isn't even the highest possible end, not even near it; even my desktop machine has more CPU than this server (I'm just jelous of its RAM size). Noses. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
