Correct the gettimeofday test which relies on pthreading was a pointless test on NetBSD stable as well. I'm looking at the pthread.c file I just downloaded it from the CVS server with the rest of Gatling. Congratulations fefe you sucessfully stressed tested GNU pthreads on a NetBSD system instead of Native Pthreads in NetBSD 1.6ZD. NetBSD stable has GNU pthreads while NetBSD current has native threading capibilites. Add this in with the Kqueue mistake on NetBSD in his testing (caused bu using STABLE again) -- you beging to get the sense that this guy is a complete joke..
for (i=0; i<count; ++i) { int r; gettimeofday(&a,0); switch ((r=pthread_create(p+i,0,mythread,pfd))) { case 0:/* ok */ break; default:
"Also, the fact that he was surprised that NetBSD outperformed FreeBSD shows how clueless he is. OpenBSD is designed for a specific thing and security comes with a performance cost."
I meant to say "Also, the fact that he was surprised that NetBSD outperformed OpenBSD shows how clueless he is. OpenBSD is designed for a specific thing and security comes with a performance cost." -- My apologies for accidently putting FreeBSD in OpenBSD's place in that comment.
Maybe someone wants to MOD this next point below up ?
"- Be clear about its subject. The test focuses exclusively on network performance/scalability, and then goes on to praise or totally disqualify the OS's tested solely on this ground. The test doesn't look at crucial aspects like security, maintainability, documentation, correctness of design, etcetera, but will still not hesitate to draw very un-subtle conclusions."
"- Be clear about its subject. The test focuses exclusively on network performance/scalability, and then goes on to praise or totally disqualify the OS's tested solely on this ground. The test doesn't look at crucial aspects like security, maintainability, documentation, correctness of design, etcetera, but will still not hesitate to draw very un-subtle conclusions."
Agreed, what is measured here is scalability i.e latency. Scalability most often measured by time-complexity of an algorithms (microseconds and clock cycles). FreeBSD 4.8 is faster than 5.X because of lower total latency but 5.X has more scalability work done on it -- which he is trying to measure. Would have been interesting if he put 4.8 next to linux 2.4 and 5.X next to 2.6 in a proper environment(i.e not a partitioned hardisk with linux being the first OS installed on the DISK among a bunch of other environmental factors). This benchmark doesn't measure OS speed horizontally on all the things that make an OS fast just one horizontal specific area. This test deals with intimate API knowledge. Specifically POSIX API. NetBSD has the most unique API being that it is highly portable. For instance I bet he didn't even look into the POSIX compatibility integers in NetBSD's kernel MIB table. He didn't mention a Caveat for non engineers/programmers without intimate knowledge of scalability latency tests on POSIX API's what this test really mesaures vertically. This doesn't mean that one OS is faster than the other overall.
- Performed on proper hardware. I mean, doing a network performance test on an old laptop with inadequate harddisk size, with four very much server-oriented operating systems, one of which (OpenBSD) couldn't even be installed on the same part of the harddisk as the others! That's like organising a race between a Lamborghini, a Lotus, a Porsche and a Ferrari in downtown New York during rush hour, and disqualifying the Ferrari on the grounds that it is difficult to park backwards."
I get the sense that he is a linux user and got frustrated with the BSD's because they weren't userfriendly enough. I.E the egregious amatuer mistake of not setting "kern.maxproc=100000 into/boot/loader.conf " in the bootloader. The information wasn't obscure at all. It is cleary in the FreeBSD handbook in simple understandable terms. If he made mistakes with the best documented *BSD we can only imagine the mistakes he made with the others i.e alot of NetBSD's syctl's and other settings aren't documented at all (have to be a programmer/hacker and be able to read system code). Also, the fact that he was surprised that NetBSD outperformed FreeBSD shows how clueless he is. OpenBSD is designed for a specific thing and security comes with a performance cost.
"- Unbiased. This one was very much biased against OpenBSD, and in favour of Linux/'Leanux', as follows from many of the comments made by the tester."
He is totally biased and has problems with the OpenBSD developers and expressed hostilities to other BSD's on other occasions.
"- Performed by somebody who knew enough about installing and running all of the OS's involved to run tests on them (the tester seems knowledgeable about Linux, but is totally clueless as far as for instance OpenBSD is concerned.)"
Agreed, totally clueless on NetBSD and barely literate on Free (couldn't read the handbook RTFM i.e lazy)
- Performed with a test programme that wasn't "developed with a bias toward one of the OS's in the test (the test programme involved was developed on Linux, later 'ported to' *BSD.)"
A good C programmer can make unbiased benchmark programs since the nature of the language is highly portable... no comment.
"- Described plain fact, by someone who would be objective and who would avoid showing emotions about the subject, much less a general favour or disgust toward the OS's tested. This is especially important because of the sensitive nature of the test subject. There are so many flamewars already!"
Agreed very unprofessional
"- Described withoud prejudice even/if/ the tester happened to be more familiar or friendly with one of the OS's tested. That would really help improve the value of the test. Unprejudiced==scientifical==professional==a virtue."
Agreed again glad someone else understands this virtue. It's about integrity not subjective comfortable ease and laziness.
"- Carefully giving minute details about the test conditions (hardware, software, test programme details, OS installation details..) This test wasn't remotely accurate, look how it even fails to mention at what time OpenBSD-CURRENT was downloaded. That's crucial information."
Very much in agreement he should have documented the settings and tweaks he attempted and tried on each one. I wouldn' be surprised if you compiled the linux kernel and tailored it so it was more responsive and used GENERIC in all three BSD's except for ostensibly taking out the -debug symbols in the FreeBSD kernel. Which BTW is not enough since he probably didn't disable debugging in userland as well for FreeBSD.
"- Compare equally. The test is already invalid because it compares an ancient -STABLE NetBSD with a -CURRENT FreeBSD."
Very much in agreement here I am still at a loss to understand the mentality of this. It makes his epoll, kqueue , poll benchmark totally pointless among other things.
"- Be clear about its subject. The test focuses exclusively on netwo
Ah, so you choose to assume *BSD hackers and users are unemployed. Could it just be that not all featherless bipeds are mentally equal ? I think the latter is more likely. You choose to skirt around most of my points and just take up the specific sysctl tweaks I mentioned. Sorry , but life doesn't work that way. You don't get to choose what points you want to respond to and win the whole argument. What is this candy ass land ?
Linux end users on average tend to be the scum of the earth with median level IQ's. Ever witness the various linux ghettos on irc or usenet ? You cannot miss them. So it doesn't surprise me that this person was unable to conduct an "Empirical scientific double blind benchmark". Hence the oddball subjective extraneous derivatives of his so called "research" on these benchmarks are pointless. It serves only to satiate the need for lust in the lackluster minds of the mass linux user base --- that is the sole purpose of this propaganda.
In order for this study to be worth a damn he would have to:
1.) Use two computers with the same hardware from two different manufacturers.
2.) Have the common decency to do thorough research which I will prove he does not do before benchmarking.
3.) Email head developers from each operating systems on tips on tweaking each OS and what versions of each OS to use in each benchmark. If he still decided to use bleeding edge from both linux and the *BSD's-- he must do so consistently across the board. Obviously he didn't because he didn't use NetBSD 1.6ZD (current) from fresh cvs diffs. Strangely enough he went with -current for both OpenBSD and FreeBSD though. The only phrase that comes to mind is "highly subjective propaganda produced by a plebeian simian who was not even clever enough to mask his propaganda with at least the nomenclature of the scientific method. How hard would it have been for him to email Luke Mewburne, Miod, and someone from FreeBSD ?
He is obviously experienced with linux and semi literate with FreeBSD (although not really because he was too stupid to set certain tweaks). While totally clueless in the NetBSD and OpenBSD environments.
"In the mean time I heard that the -CURRENT version of NetBSD has over two years worth of improvements in it, so it probably is even better than NetBSD 1.6.1, which already surprised me with its good performance (although it is clearly outperformed by FreeBSD)." -- fefe.
Then you have no excuse for using the bleeding edge of Linux and FreeBSD.. total lack of consistency from a linux E-tard. He says at other times he was "surprised" that NetBSD outperformed and even beat the others clearly on benchmark to do with sockets. That would have come as no surprise to a serious engineer who had the integrity and quality of character to study the code changes to each OS by reading the mailing lists, developer change notes and even reading source code. The NetBSD socket performance win was clearly because of Jason Thorpes hack here:
"The clear loser of this benchmark is NetBSD, because they simply don't offer a better API than poll. As I wrote in the introduction, I only benchmarked the stable NetBSD 1.6.1 kernel here,
and I assume they have included kqueue in their -CURRENT kernel. I will try to update my NetBSD installation and rerun the benchmarks on it." -fefe
Gee, you think fefe ? You assume they have included a native kqueue ? Ah you mean you are a complete moron who couldn't be bothered to conduct real "research" and "benchmarking". Clearly it wouldn't have taken long to research and be able to say with authority "NetBSD has native kqueue it was added to the code on such and such a date by developer X". Just for the record NetBSD current does have native kqueue and native pthreads.
I bet you didn't even bother to tweak NetBSD at all as you barely tried with FreeBSD. Note that it would have been a good idea to tweak Kern.maxfiles, kernmaxvnodes and vm.anonmax with sysctl on NetBSD.
Also, why mention itojun on ipv6 but leave out other developers names where NetBSD and FreeBSD win on the benchmark ? He only goes on extravagant explainations on why OpenBSD loses in one scenario. His need to be verbose only in such a situation shows his linux bias or guilt for skewing the benchmark so bad. Oth
I have to agree with you on 9wm. I tried evilwm and I don't particulary fancy it; this is obviously highly subjective. However, my favorite minimal window manager is w9wm which is basically just a 50 line hack of the high quality 9wm from bell labs. The hack simply adds support for virtual screens and certain keybindings. if you want to check it out here is the homepage:
I tried evilwm and I don't particulary fancy it; this is obviously highly subjective. However, my favorite minimal window manager is w9wm which is basically just a 50 line hack of the high quality 9wm from bell labs. The hack simply adds support for virtual screens and certain keybindings.
if you want to check it out here is the homepage:
http://inferno.cs.univ-paris8.fr/~drieu/w9
Slashdot Mirror
Correct the gettimeofday test which relies on pthreading was a pointless test on NetBSD stable as well. I'm looking at the pthread.c file I just downloaded it from the CVS server with the rest of Gatling. Congratulations fefe you sucessfully stressed tested GNU pthreads on a NetBSD system instead of Native Pthreads in NetBSD 1.6ZD. NetBSD stable has GNU pthreads while NetBSD current has native threading capibilites. Add this in with the Kqueue mistake on NetBSD in his testing (caused bu using STABLE again) -- you beging to get the sense that this guy is a complete joke..
/* ok */
for (i=0; i<count; ++i) {
int r;
gettimeofday(&a,0);
switch ((r=pthread_create(p+i,0,mythread,pfd))) {
case 0:
break;
default:
Oops my apologies I said above
"Also, the fact that he was surprised that NetBSD outperformed FreeBSD shows how clueless he is. OpenBSD is designed for a specific thing and security comes with a performance cost."
I meant to say "Also, the fact that he was surprised that NetBSD outperformed OpenBSD shows how clueless he is. OpenBSD is designed for a specific thing and security comes with a performance cost." -- My apologies for accidently putting FreeBSD in OpenBSD's place in that comment.
Maybe someone wants to MOD this next point below up ?
"- Be clear about its subject. The test focuses exclusively on network performance/scalability, and then goes on to praise or totally disqualify the OS's tested solely on this ground. The test doesn't look at crucial aspects like security, maintainability, documentation, correctness of design, etcetera, but will still not hesitate to draw very un-subtle conclusions."
"- Be clear about its subject. The test focuses exclusively on network performance/scalability, and then goes on to praise or totally disqualify the OS's tested solely on this ground. The test doesn't look at crucial aspects like security, maintainability, documentation, correctness of design, etcetera, but will still not hesitate to draw very un-subtle conclusions."
Agreed, what is measured here is scalability i.e latency. Scalability most often measured by time-complexity of an algorithms (microseconds and clock cycles). FreeBSD 4.8 is faster than 5.X because of lower total latency but 5.X has more scalability work done on it -- which he is trying to measure. Would have been interesting if he put 4.8 next to linux 2.4 and 5.X next to 2.6 in a proper environment(i.e not a partitioned hardisk with linux being the first OS installed on the DISK among a bunch of other environmental factors). This benchmark doesn't measure OS speed horizontally on all the things that make an OS fast just one horizontal specific area. This test deals with intimate API knowledge. Specifically POSIX API. NetBSD has the most unique API being that it is highly portable. For instance I bet he didn't even look into the POSIX compatibility integers in NetBSD's kernel MIB table. He didn't mention a Caveat for non engineers/programmers without intimate knowledge of scalability latency tests on POSIX API's what this test really mesaures vertically. This doesn't mean that one OS is faster than the other overall.
"A proper test would be
/boot/loader.conf " in the bootloader. The information wasn't obscure at all. It is cleary in the FreeBSD handbook in simple understandable terms. If he made mistakes with the best documented *BSD we can only imagine the mistakes he made with the others i.e alot of NetBSD's syctl's and other settings aren't documented at all (have to be a programmer/hacker and be able to read system code). Also, the fact that he was surprised that NetBSD outperformed FreeBSD shows how clueless he is. OpenBSD is designed for a specific thing and security comes with a performance cost.
/if/ the tester happened to be more familiar or friendly with one of the OS's tested. That would really help improve the value of the test. Unprejudiced==scientifical==professional==a virtue."
- Performed on proper hardware. I mean, doing a network performance test on an old laptop with inadequate harddisk size, with four very much server-oriented operating systems, one of which (OpenBSD) couldn't even be installed on the same part of the harddisk as the others! That's like organising a race between a Lamborghini, a Lotus, a Porsche and a Ferrari in downtown New York during rush hour, and disqualifying the Ferrari on the grounds that it is difficult to park backwards."
I get the sense that he is a linux user and got frustrated with the BSD's because they weren't userfriendly enough. I.E the egregious amatuer mistake of not setting "kern.maxproc=100000 into
"- Unbiased. This one was very much biased against OpenBSD, and in favour of Linux/'Leanux', as follows from many of the comments made by the tester."
He is totally biased and has problems with the OpenBSD developers and expressed hostilities to other BSD's on other occasions.
"- Performed by somebody who knew enough about installing and running all of the OS's involved to run tests on them (the tester seems knowledgeable about Linux, but is totally clueless as far as for instance OpenBSD is concerned.)"
Agreed, totally clueless on NetBSD and barely literate on Free (couldn't read the handbook RTFM i.e lazy)
- Performed with a test programme that wasn't "developed with a bias toward one of the OS's in the test (the test programme involved was developed on Linux, later 'ported to' *BSD.)"
A good C programmer can make unbiased benchmark programs since the nature of the language is highly portable... no comment.
"- Described plain fact, by someone who would be objective and who would avoid showing emotions about the subject, much less a general favour or disgust toward the OS's tested. This is especially important because of the sensitive nature of the test subject. There are so many flamewars already!"
Agreed very unprofessional
"- Described withoud prejudice even
Agreed again glad someone else understands this virtue. It's about integrity not subjective comfortable ease and laziness.
"- Carefully giving minute details about the test conditions (hardware, software, test programme details, OS installation details..) This test wasn't remotely accurate, look how it even fails to mention at what time OpenBSD-CURRENT was downloaded. That's crucial information."
Very much in agreement he should have documented the settings and tweaks he attempted and tried on each one. I wouldn' be surprised if you compiled the linux kernel and tailored it so it was more responsive and used GENERIC in all three BSD's except for ostensibly taking out the -debug symbols in the FreeBSD kernel. Which BTW is not enough since he probably didn't disable debugging in userland as well for FreeBSD.
"- Compare equally. The test is already invalid because it compares an ancient -STABLE NetBSD with a -CURRENT FreeBSD."
Very much in agreement here I am still at a loss to understand the mentality of this. It makes his epoll, kqueue , poll benchmark totally pointless among other things.
"- Be clear about its subject. The test focuses exclusively on netwo
Ah, so you choose to assume *BSD hackers and users are unemployed. Could it just be that not all featherless bipeds are mentally equal ? I think the latter is more likely. You choose to skirt around most of my points and just take up the specific sysctl tweaks I mentioned. Sorry , but life doesn't work that way. You don't get to choose what points you want to respond to and win the whole argument. What is this candy ass land ?
Linux end users on average tend to be the scum of the earth with median level IQ's. Ever witness the various linux ghettos on irc or usenet ? You cannot miss them. So it doesn't surprise me that this person was unable to conduct an "Empirical scientific double blind benchmark". Hence the oddball subjective extraneous derivatives of his so called "research" on these benchmarks are pointless. It serves only to satiate the need for lust in the lackluster minds of the mass linux user base --- that is the sole purpose of this propaganda.
.
.. total lack of consistency from a linux E-tard. He says at other times he was "surprised" that NetBSD outperformed and even beat the others clearly on benchmark to do with sockets. That would have come as no surprise to a serious engineer who had the integrity and quality of character to study the code changes to each OS by reading the mailing lists, developer change notes and even reading source code. The NetBSD socket performance win was clearly because of Jason Thorpes hack here :
/03/0011.html
In order for this study to be worth a damn he would have to:
1.) Use two computers with the same hardware from two different manufacturers
2.) Have the common decency to do thorough research which I will prove he does not do before benchmarking.
3.) Email head developers from each operating systems on tips on tweaking each OS and what versions of each OS to use in each benchmark. If he still decided to use bleeding edge from both linux and the *BSD's-- he must do so consistently across the board. Obviously he didn't because he didn't use NetBSD 1.6ZD (current) from fresh cvs diffs. Strangely enough he went with -current for both OpenBSD and FreeBSD though. The only phrase that comes to mind is "highly subjective propaganda produced by a plebeian simian who was not even clever enough to mask his propaganda with at least the nomenclature of the scientific method. How hard would it have been for him to email Luke Mewburne, Miod, and someone from FreeBSD ?
He is obviously experienced with linux and semi literate with FreeBSD (although not really because he was too stupid to set certain tweaks). While totally clueless in the NetBSD and OpenBSD environments.
"In the mean time I heard that the -CURRENT version of NetBSD has over two years worth of improvements in it, so it probably is even better than NetBSD 1.6.1, which already surprised me with its good performance (although it is clearly outperformed by FreeBSD)." -- fefe.
Then you have no excuse for using the bleeding edge of Linux and FreeBSD
http://mail-index.netbsd.org/current-users/2002/ 07
"The clear loser of this benchmark is NetBSD, because they simply don't offer a better API than poll. As I wrote in the introduction, I only benchmarked the stable NetBSD 1.6.1 kernel here,
and I assume they have included kqueue in their -CURRENT kernel. I will try to update my NetBSD installation and rerun the benchmarks on it." -fefe
Gee, you think fefe ? You assume they have included a native kqueue ? Ah you mean you are a complete moron who couldn't be bothered to conduct real "research" and "benchmarking". Clearly it wouldn't have taken long to research and be able to say with authority "NetBSD has native kqueue it was added to the code on such and such a date by developer X". Just for the record NetBSD current does have native kqueue and native pthreads.
I bet you didn't even bother to tweak NetBSD at all as you barely tried with FreeBSD. Note that it would have been a good idea to tweak
Kern.maxfiles, kernmaxvnodes and vm.anonmax with sysctl on NetBSD.
Also, why mention itojun on ipv6 but leave out other developers names where NetBSD and FreeBSD win on the benchmark ? He only goes on extravagant explainations on why OpenBSD loses in one scenario. His need to be verbose only in such a situation shows his linux bias or guilt for skewing the benchmark so bad. Oth
the windowmagers xfwm4 (for the new xfce4 desktop) and pekwm work great with gnome-panel as well.
I have to agree with you on 9wm. I tried evilwm and I don't particulary fancy it; this is obviously highly subjective. However, my favorite minimal window manager is w9wm which is basically just a 50 line hack of the high quality 9wm from bell labs. The hack simply adds support for virtual screens and certain keybindings. if you want to check it out here is the homepage:
http://inferno.cs.univ-paris8.fr/~drieu/w9
I tried evilwm and I don't particulary fancy it; this is obviously highly subjective. However, my favorite minimal window manager is w9wm which is basically just a 50 line hack of the high quality 9wm from bell labs. The hack simply adds support for virtual screens and certain keybindings. if you want to check it out here is the homepage: http://inferno.cs.univ-paris8.fr/~drieu/w9