Re: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
On Mon, Nov 30, 2009 at 11:34:06PM -0800, James Phillips typed: --- On Mon, 11/30/09, Bruce Cran br...@cran.org.uk wrote: This is actually the way UFS/FFS works too: when my system was crashing fairly regularly I was a bit surprised to find empty files after editing them. Also, I just verified that saving a file, rebooting, editing it again (with ee(1)) and powering off the system does still result in a zero length file being on disk. Ok, good to know. I saw UFS corruption once with frequent restarts, but assumed that was because the delayed filesystem checking never had a chance to run. Since I don't have a UPS I guess backups are doubly important. Note that finding an empty file you had just been editing before a crash is NOT UFS corruption. It's data loss, probably caused by softupdates, which guarantees filesystem consistency in the case of a crash, but it can sometimes be up to a minute behind in actually writing the data blocks to the disk. Ruben ___ 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: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
O. Hartmann wrote: I'm just wondering what's wrong with FreeBSD 8.0/amd64 when I read the Benchmarks on Phoronix.org's website. Especially FreeBSD's threaded I/O shows in contrast to all claims that have been to be improoved the opposite. Instead of trying to compare something, I propose to look on that numbers itself first: - first test tells that average write latency is about 100us. But it looks quite surprising for Laptop HDD, which has seek time of at least several milliseconds. - second test - a bit closer to life - 2-3ms - ok, Linux won here slightly, as FreeBSD installation in this test had no NCQ support. - third test - 9us per write on Linux. I am just crying. - forth test - all OSes gave 50-80us. Probably it is just a buffer case read time. So most of shown cases are testing almost only file system cache parameters. It is just insane to compare them for so different systems with so different write-back policies. If somebody still have questions, after some UFS parameters tuning I've got with the same tiotest tool: - Random Write latency - 15us, - Random Read latency - 7us. So who can beat my FreeBSD? :))) What's about second test. To check possible NCQ effect I've built test setup with new 320GB 7200RPM Seagate drive connected to Intel ICH10R controller. I've run IMHO more reasonable benchmark/raidtest tool from ports on whole device, to execute pregenerated random mix of 1 random-sized (512B - 128KB) read/write requests using default ata(4) driver and new ahci(4): Number of READ requests: 5029. Number of WRITE requests: 4971. Number of bytes to transmit: 655986688. Number of processes: 32. The results: ata(4) - no NCQ: Bytes per second: 12455402 Requests per second: 189 ahci(4) - with NCQ: Bytes per second: 19889778 Requests per second: 303 Results are repeatable up to the 4-th digit. Average time per request is 5.29ms and 3.3ms respectively, that is realistic for this drive. So, with such difference, I believe, we will not loose this test any more. -- Alexander Motin ___ 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
Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
I'm just wondering what's wrong with FreeBSD 8.0/amd64 when I read the Benchmarks on Phoronix.org's website. Especially FreeBSD's threaded I/O shows in contrast to all claims that have been to be improoved the opposite. oh ___ 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: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
I didn't know these were released already, but I had a look. I was disappointed with the results. If anyone wants to look here is the link: http://www.phoronix.com/scan.php?page=articleitem=freebsd8_benchmarksnum=1 Linux's ext4 seems to leave UFS and ZFS well behind in a number of benchmarks. O. Hartmann wrote: I'm just wondering what's wrong with FreeBSD 8.0/amd64 when I read the Benchmarks on Phoronix.org's website. Especially FreeBSD's threaded I/O shows in contrast to all claims that have been to be improoved the opposite. oh ___ 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 ___ 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: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
On Nov 30, 2009, at 9:47 AM, O. Hartmann wrote: I'm just wondering what's wrong with FreeBSD 8.0/amd64 when I read the Benchmarks on Phoronix.org's website. Especially FreeBSD's threaded I/O shows in contrast to all claims that have been to be improoved the opposite. Corrected link: http://www.phoronix.com/scan.php?page=articleitem=freebsd8_benchmarksnum=1 And yeah, quite honestly: disk scheduling in FreeBSD appears to suck... The only reason I'm not switching from Linux. :( Regards, Thomas (PS. See my thread about horrible console latency during disk IO in the archives, very related. DS.)___ 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: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
Thomas Backman wrote: On Nov 30, 2009, at 9:47 AM, O. Hartmann wrote: I'm just wondering what's wrong with FreeBSD 8.0/amd64 when I read the Benchmarks on Phoronix.org's website. Especially FreeBSD's threaded I/O shows in contrast to all claims that have been to be improoved the opposite. Corrected link: http://www.phoronix.com/scan.php?page=articleitem=freebsd8_benchmarksnum=1 And yeah, quite honestly: disk scheduling in FreeBSD appears to suck... The only reason I'm not switching from Linux. :( Regards, Thomas (PS. See my thread about horrible console latency during disk IO in the archives, very related. DS.) Hello Thomas. I recall myself having had similar problems during heavy disk I/O (UFS and ZFS) with stuck console, stuck clients and especially stuck X11-clients. The discussion was really 'hot', but in the end no clear statement was made whether this is disk-i/o related or a deeper problem in the scheduler. Sorry for the lack of the link, I thought Phoronix is well known ... Oliver ___ 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: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
On Nov 30, 2009, at 12:38 PM, O. Hartmann wrote: Thomas Backman wrote: On Nov 30, 2009, at 9:47 AM, O. Hartmann wrote: I'm just wondering what's wrong with FreeBSD 8.0/amd64 when I read the Benchmarks on Phoronix.org's website. Especially FreeBSD's threaded I/O shows in contrast to all claims that have been to be improoved the opposite. Corrected link: http://www.phoronix.com/scan.php?page=articleitem=freebsd8_benchmarksnum=1 And yeah, quite honestly: disk scheduling in FreeBSD appears to suck... The only reason I'm not switching from Linux. :( Regards, Thomas (PS. See my thread about horrible console latency during disk IO in the archives, very related. DS.) Hello Thomas. I recall myself having had similar problems during heavy disk I/O (UFS and ZFS) with stuck console, stuck clients and especially stuck X11-clients. The discussion was really 'hot', but in the end no clear statement was made whether this is disk-i/o related or a deeper problem in the scheduler. Sorry for the lack of the link, I thought Phoronix is well known ... Oliver That's too bad, re: the scheduling. It seems to be a quite universal problem, yet I haven't seen much effort spent on working on the problem. :/ Re: phoronix, I commented mostly because the site is .com and not .org, so I came to a parked domain when I clicked your link. :) Also, I figured linking directly to the article will help the archives. Regards, Thomas___ 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: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
Thomas Backman wrote: On Nov 30, 2009, at 9:47 AM, O. Hartmann wrote: I'm just wondering what's wrong with FreeBSD 8.0/amd64 when I read the Benchmarks on Phoronix.org's website. Especially FreeBSD's threaded I/O shows in contrast to all claims that have been to be improoved the opposite. Corrected link: http://www.phoronix.com/scan.php?page=articleitem=freebsd8_benchmarksnum=1 And yeah, quite honestly: disk scheduling in FreeBSD appears to suck... The only reason I'm not switching from Linux. :( About the only useful result of the Phoronix benchmark suite in general is that benchmarking is hard, and that though tedious, statistical analisys and multiple runs actually have a realistic purpose. I suspect their runs have a very large variance between tests and are only useful in order-of-magnitude sort of comparisons. Most of their CPU-bound benchmarks therefore show results with insignificant differences, and most of the others benchmark the compilers. On the other hand, disk IO benchmarks like http://www.phoronix.com/scan.php?page=articleitem=freebsd8_benchmarksnum=7 reflect the real state of the things, which can be easily demonstrated by a large number of other benchmarks (e.g. blogbench). AFAIK there is some speculation among developers about why is this so, but nothing definite yet. For what it's worth, ZFS effectively does a fair bit of its own IO scheduling, so persons interested in this particular aspect should also try the tests with ZFS. My own tests (with other benchmarks) show that ZFS helps significantly, though the cumulative result is still significantly worse than Linux's. ___ 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: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
In response to Ivan Voras ivo...@freebsd.org: Thomas Backman wrote: On Nov 30, 2009, at 9:47 AM, O. Hartmann wrote: I'm just wondering what's wrong with FreeBSD 8.0/amd64 when I read the Benchmarks on Phoronix.org's website. Especially FreeBSD's threaded I/O shows in contrast to all claims that have been to be improoved the opposite. Corrected link: http://www.phoronix.com/scan.php?page=articleitem=freebsd8_benchmarksnum=1 And yeah, quite honestly: disk scheduling in FreeBSD appears to suck... The only reason I'm not switching from Linux. :( All operating systems were left with their default options during the installation process... It's common knowledge that the default value for vfs.read_max is non- optimal for most hardware and that significant performance improvements can be made in most cases by raising it. While it would be nice if FreeBSD shipped with a more performant default setting, it would also be nice if mindless benchmark drones would quit assuming that every system ships pre-configured to perform optimally in their benchmarks. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ ___ 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: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
On Mon, Nov 30, 2009 at 02:49:17PM +0100, Ivan Voras wrote: Bill Moran wrote: In response to Ivan Voras ivo...@freebsd.org: Thomas Backman wrote: On Nov 30, 2009, at 9:47 AM, O. Hartmann wrote: I'm just wondering what's wrong with FreeBSD 8.0/amd64 when I read the Benchmarks on Phoronix.org's website. Especially FreeBSD's threaded I/O shows in contrast to all claims that have been to be improoved the opposite. Corrected link: http://www.phoronix.com/scan.php?page=articleitem=freebsd8_benchmarksnum=1 And yeah, quite honestly: disk scheduling in FreeBSD appears to suck... The only reason I'm not switching from Linux. :( All operating systems were left with their default options during the installation process... It's common knowledge that the default value for vfs.read_max is non- optimal for most hardware and that significant performance improvements can be made in most cases by raising it. On the other hand, random IO is negatively influenced by readahead :) Parallel Random I/O gives better results on Raid 5 than a single sequential read :-) I also found FreeBSD UFS with Softupdates handling directories with many small files much better than Linux and ReiserFS (same hardware) - at least a simple ls returned much quicker on FreeBSD (factor 5 to 10). So it is always a matter of what you intend to do with the filesystem - is it for logging, for mailserver-storage, for database usage, for fileserver, webserver etc. (with or without changing atime), with redundancy (raid 1, 5, 10) or using zfs, etc. With FreeBSD we have a system that works ok out of the box, but for real-world usage needs some tuning to be optimised for the specific task. Regards, Holger ___ 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: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
Holger Kipp wrote: On Mon, Nov 30, 2009 at 02:49:17PM +0100, Ivan Voras wrote: On the other hand, random IO is negatively influenced by readahead :) Parallel Random I/O gives better results on Raid 5 than a single sequential read :-) I also found FreeBSD UFS with Softupdates handling directories with many small files much better than Linux and ReiserFS (same hardware) - at least a simple ls returned much quicker on FreeBSD (factor 5 to 10). Yes, until ext4 I was always surprised how bad Linux ext2/3 handled large metadata operations (file deletions and creations). UFS+SU definitely has places where it shines. With FreeBSD we have a system that works ok out of the box, but for real-world usage needs some tuning to be optimised for the specific task. Of course. But I think the issue at hand is that there really is more work to do to catch up on average IO performance. ___ 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: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
Bill Moran writes: It's common knowledge that the default value for vfs.read_max is non- optimal for most hardware and that significant performance improvements can be made in most cases by raising it. Documentation/discussion where? Respectfully, Robert Huff ___ 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: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
In response to Robert Huff roberth...@rcn.com: Bill Moran writes: It's common knowledge that the default value for vfs.read_max is non- optimal for most hardware and that significant performance improvements can be made in most cases by raising it. Documentation/discussion where? http://www.google.com/search?q=freebsd+vfs.read_max ... although it doesn't seem to be officially documented anywhere. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ ___ 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: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
Robert Huff wrote: Bill Moran writes: It's common knowledge that the default value for vfs.read_max is non- optimal for most hardware and that significant performance improvements can be made in most cases by raising it. Documentation/discussion where? There is no documentation except for the sysctl documentation itself: vfs.read_max: Cluster read-ahead max block count but it depends on the load - it helps sequential reads, will probably do nothing for other kinds of loads. It is also UFS-only. ___ 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: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
Date: Mon, 30 Nov 2009 20:07:15 +1100 From: alex a...@mailinglist.ahhyes.net Subject: Re: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0? To: freebsd-questions@freebsd.org Message-ID: 4b138b43.4000...@mailinglist.ahhyes.net Content-Type: text/plain; charset=ISO-8859-15; format=flowed I didn't know these were released already, but I had a look. I was disappointed with the results. If anyone wants to look here is the link: http://www.phoronix.com/scan.php?page=articleitem=freebsd8_benchmarksnum=1 Linux's ext4 seems to leave UFS and ZFS well behind in a number of benchmarks. My first thought is that Ext4 may be cheating on the benchmarks. The performance regressions should probably be concerning though. Ext4 data loss; explanations and workarounds http://www.h-online.com/open/news/item/Ext4-data-loss-explanations-and-workarounds-740671.html Ext4 data loss Bug #317781 (Fix released) https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781 If you really want to make sure the data in on disk, you have to use fsync() or fdatasync(). Even with ext3, if you crash at the wrong time, you will also lose data. So it's not the case with ext4 that it's going to truncate files ievery time/i a non-redundant component dies. It's not bevery time/b. If you fdatasync() or fsync() the file, once the system call returns you know it will be safely on disk. With the patches, the blocks will be forcibly allocated in the case where you are replacing an existing file, so if you crash, you'll either get the old version (if the commit didn't make it) or the new version (if the commit did make it). If you really care, you could write a program which runs sync() every 5 seconds, or even every 1 second. Your performance will be completely trashed, but that's the way things break. - Theodore Ts'o wrote on 2009-03-06 __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.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: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
On Mon, 30 Nov 2009 09:22:17 -0800 (PST) James Phillips anti_spam...@yahoo.ca wrote: Date: Mon, 30 Nov 2009 20:07:15 +1100 From: alex a...@mailinglist.ahhyes.net Subject: Re: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0? To: freebsd-questions@freebsd.org Message-ID: 4b138b43.4000...@mailinglist.ahhyes.net Content-Type: text/plain; charset=ISO-8859-15; format=flowed I didn't know these were released already, but I had a look. I was disappointed with the results. If anyone wants to look here is the link: http://www.phoronix.com/scan.php?page=articleitem=freebsd8_benchmarksnum=1 Linux's ext4 seems to leave UFS and ZFS well behind in a number of benchmarks. My first thought is that Ext4 may be cheating on the benchmarks. The performance regressions should probably be concerning though. Ext4 data loss; explanations and workarounds http://www.h-online.com/open/news/item/Ext4-data-loss-explanations-and-workarounds-740671.html Ext4 data loss Bug #317781 (Fix released) https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781 If you really want to make sure the data in on disk, you have to use fsync() or fdatasync(). Even with ext3, if you crash at the wrong time, you will also lose data. So it's not the case with ext4 that it's going to truncate files ievery time/i a non-redundant component dies. It's not bevery time/b. If you fdatasync() or fsync() the file, once the system call returns you know it will be safely on disk. With the patches, the blocks will be forcibly allocated in the case where you are replacing an existing file, so if you crash, you'll either get the old version (if the commit didn't make it) or the new version (if the commit did make it). If you really care, you could write a program which runs sync() every 5 seconds, or even every 1 second. Your performance will be completely trashed, but that's the way things break. - Theodore Ts'o wrote on 2009-03-06 This is actually the way UFS/FFS works too: when my system was crashing fairly regularly I was a bit surprised to find empty files after editing them. Also, I just verified that saving a file, rebooting, editing it again (with ee(1)) and powering off the system does still result in a zero length file being on disk. -- Bruce Cran ___ 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: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
--- On Mon, 11/30/09, Bruce Cran br...@cran.org.uk wrote: This is actually the way UFS/FFS works too: when my system was crashing fairly regularly I was a bit surprised to find empty files after editing them. Also, I just verified that saving a file, rebooting, editing it again (with ee(1)) and powering off the system does still result in a zero length file being on disk. Ok, good to know. I saw UFS corruption once with frequent restarts, but assumed that was because the delayed filesystem checking never had a chance to run. Since I don't have a UPS I guess backups are doubly important. -james. __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ ___ 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
