Re: Anatomy of Perfomance tests
___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" It would be very interesting to see the results of stress-testing systems. I cannot think of a scenario that isn't possible with a virtual machine. quite but not really. if tested OS does not force hard disk to commit writes at right time, as FreeBSD do, virtual machine will not catch all things. anyway abruptly stopping virtual machine is a good test. use LARGE memory for tested OS. Funny but this is the case when linux is actually worse as it could delay more writes and then issue them in any order. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Anatomy of Perfomance tests
That said, I think that the Linux kernel performs better simply due to wider adoption (larger developer base, wider set of use-cases, etc) and thus a higher chance of getting performance improvements. Note that stability matters too. of course - this is what i pointed out at first. the second is clear team managing a kernel, and support. What i recently get when getting FreeBSD crash problems is something that you'll not get from linux. It found out to be my fault. I would generally call properly configured FreeBSD as rock-stable. The filesystem performance was close, and comparing dangerous linux filesystem to UFS isn't good. i would recommend comparing -o async mounted UFS with that test. Second - i would like to see how responsive linux server is WHILE performing that tests ;) high latencies under load was a problem i always had with linux when still using it. But scientific computing task results are FreeBSD fault, and the some reason is clang compiler,. With recent gcc-recompiled binaries it would be similar result. Similar as with compute-bound processes OS doesn't have much to change. Maybe, if there were more threads run than available, scheduler could matter. And i think FreeBSD scheduler would clearly win. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Anatomy of Perfomance tests
On Fri, Jun 29, 2012 at 1:12 PM, Wojciech Puchar wrote: > what i would like to see too is how these systems compare on such test: > > - run lots of heavy disk I/O tests, many different in the same time, > including ones doing many writes to different places. > > - turn off power while doing this, by unplugging from wall plug. > > - compare amount of loss and destruction that happened to filesystem. > > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" It would be very interesting to see the results of stress-testing systems. I cannot think of a scenario that isn't possible with a virtual machine. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Anatomy of Perfomance tests
what i would like to see too is how these systems compare on such test: - run lots of heavy disk I/O tests, many different in the same time, including ones doing many writes to different places. - turn off power while doing this, by unplugging from wall plug. - compare amount of loss and destruction that happened to filesystem. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Anatomy of Perfomance tests
At least he should have used one or at very least identical systems, not 3 different, albeit similar. And I do not care If it would change results or not, comparing different systems invalidates benchmarks period. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Anatomy-of-Perfomance-tests-tp5722932p5722964.html Sent from the freebsd-questions mailing list archive at Nabble.com. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Anatomy of Perfomance tests
On Fri, 29 Jun 2012 11:40:37 +0200, Julien Cigar wrote: > On 06/29/2012 11:00, Fred Morcos wrote: >> On Fri, Jun 29, 2012 at 10:53 AM, Wojciech Puchar >> wrote: >>> Most probably all filesystems were used with defaults. >>> >>> MAYBE softupdates, but not even sure for this. Compare this to linux >>> which is async-like. Comparing with UFS+async would be more fair. >>> >>> Still - FreeBSD default MAXPHYS in param.h is far too low. i change it >>> to 2048*1024 (default is 128*1024) and improvement on handling large >>> files is huge. I run that setting everywhere. No problems. >>> >>> I already talked about it on forum but was ignored. >>> >>> As for scientific processing it should not depend much from OS at all, >>> but for sure it depends on crappy compiler that Juniper wanted... >>> >>> >>> >>> ___ >>> freebsd-questions@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions To >>> unsubscribe, send any mail to >>> "freebsd-questions-unsubscr...@freebsd.org" >> I would not worry too much about what this guy says. Judging from his >> interpretations of the plots, he doesn't seem to know much about the >> benchmarks he is running and why they behave that way on the different >> systems. I think he just runs and publishes everything that says >> benchmark on it, without truly understanding what's going on or even >> going through the effort of providing fair comparisons. >> >> That said, I think that the Linux kernel performs better simply due to >> wider adoption (larger developer base, wider set of use-cases, etc) >> and thus a higher chance of getting performance improvements. > > Note that stability matters too. > I remembered a bench on PostgreSQL where Linux was faster, but at some > point the machine had to be rebooted because it became unresponsive. > Unscientific, anecdotal and entirely subjective, but here's my 2c. I run both FreeBSD and Linux on the same machine in a multi-boot configuration. Each has its default disk configuration (UFS + SJ vs. Ext4 with journalling). Linux is noticeably faster, but the performance of both is satisfactory, and I prefer FreeBSD. To echo Julien, benchmarks aren't everything. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Anatomy of Perfomance tests
On 06/29/2012 11:00, Fred Morcos wrote: On Fri, Jun 29, 2012 at 10:53 AM, Wojciech Puchar wrote: Most probably all filesystems were used with defaults. MAYBE softupdates, but not even sure for this. Compare this to linux which is async-like. Comparing with UFS+async would be more fair. Still - FreeBSD default MAXPHYS in param.h is far too low. i change it to 2048*1024 (default is 128*1024) and improvement on handling large files is huge. I run that setting everywhere. No problems. I already talked about it on forum but was ignored. As for scientific processing it should not depend much from OS at all, but for sure it depends on crappy compiler that Juniper wanted... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" I would not worry too much about what this guy says. Judging from his interpretations of the plots, he doesn't seem to know much about the benchmarks he is running and why they behave that way on the different systems. I think he just runs and publishes everything that says benchmark on it, without truly understanding what's going on or even going through the effort of providing fair comparisons. That said, I think that the Linux kernel performs better simply due to wider adoption (larger developer base, wider set of use-cases, etc) and thus a higher chance of getting performance improvements. Note that stability matters too. I remembered a bench on PostgreSQL where Linux was faster, but at some point the machine had to be rebooted because it became unresponsive. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" -- No trees were killed in the creation of this message. However, many electrons were terribly inconvenienced. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Anatomy of Perfomance tests
when properly configured FreeBSD is quite good. if that company: http://www.phoronix.com/scan.php?page=news_item&px=MTExNDM chose FreeBSD in spite of hype-overloaded linux it must be a reason. As well as it seems they know what they are doing, storage configuration is IMGO an example how such things should be done to get the best of. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Anatomy of Perfomance tests
On Fri, Jun 29, 2012 at 10:53 AM, Wojciech Puchar wrote: > Most probably all filesystems were used with defaults. > > MAYBE softupdates, but not even sure for this. Compare this to linux which > is async-like. Comparing with UFS+async would be more fair. > > Still - FreeBSD default MAXPHYS in param.h is far too low. i change it to > 2048*1024 (default is 128*1024) and improvement on handling large files is > huge. I run that setting everywhere. No problems. > > I already talked about it on forum but was ignored. > > As for scientific processing it should not depend much from OS at all, but > for sure it depends on crappy compiler that Juniper wanted... > > > > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" I would not worry too much about what this guy says. Judging from his interpretations of the plots, he doesn't seem to know much about the benchmarks he is running and why they behave that way on the different systems. I think he just runs and publishes everything that says benchmark on it, without truly understanding what's going on or even going through the effort of providing fair comparisons. That said, I think that the Linux kernel performs better simply due to wider adoption (larger developer base, wider set of use-cases, etc) and thus a higher chance of getting performance improvements. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Anatomy of Perfomance tests
Most probably all filesystems were used with defaults. MAYBE softupdates, but not even sure for this. Compare this to linux which is async-like. Comparing with UFS+async would be more fair. Still - FreeBSD default MAXPHYS in param.h is far too low. i change it to 2048*1024 (default is 128*1024) and improvement on handling large files is huge. I run that setting everywhere. No problems. I already talked about it on forum but was ignored. As for scientific processing it should not depend much from OS at all, but for sure it depends on crappy compiler that Juniper wanted... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Anatomy of Perfomance tests
Hi, Can some body comment on these tests? http://www.phoronix.com/scan.php?page=article&item=debian_wheezybsd_freeze&num=1 Are these tests skewed in some way to make Linux look better? Thanks --Siju ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
