Date: Fri, 20 Apr 2001 07:05:14 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: niek@bergboer.net Cc: freebsd-hackers@freebsd.org Subject: Re: UFS block size vs. write speed Message-ID: <20010420070514.R1790@fw.wintelcom.net> In-Reply-To: <20010420152029.A35974@wit379119.student.utwente.nl>; from niek@wit379119.student.utwente.nl on Fri, Apr 20, 2001 at 03:20:29PM %2B0200 References: <20010420144543.F30241@wit379119.student.utwente.nl> <20010420055426.Q1790@fw.wintelcom.net> <20010420152029.A35974@wit379119.student.utwente.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
you really need to try harder to wrap lines properly. * Niek Bergboer <niek@wit379119.student.utwente.nl> [010420 06:17] wrote: > On Fri, Apr 20, 2001 at 05:54:26AM -0700, Alfred Perlstein wrote: > > * Niek Bergboer <niek@wit379119.student.utwente.nl> [010420 05:43] wrote: > > > b.) Are there other newfs options that I can use to increase throughput? > > Have you tried softupdates? > > Isn't it true that softupdates only work when filesystems are mounted sync? Or does it > also improve performance when filesystems are mounted async? It really depends on how temporary those files are. Softupdates can realize when a disk IO never needs to happen where async can't do that. > > > PS: The tests were already done with the fs mounted async. The > > > drive in question communicates at UDMA/33 on a PIIX4 controller in > > > an AMD K6/2 233 system. > > There's a couple things here. > > > a) what version of freebsd are you using? > > recent versions turn of IDE write caching, you may want to turn > > this on, see the ata(4) manpage, remeber that it can only be set > > at boot time. > > To be fully informative: > FreeBSD wit379119.student.utwente.nl 4.3-RC FreeBSD 4.3-RC #0: Mon Apr 9 16:23:30 CEST 2001 root@wit379119.student.utwente.nl:/usr/obj/usr/src/sys/WUTRA1 i386 > > Indeed, write caching (hw.ata.wc) was set to zero some time ago, but the loader in configured to > enable it at boot time: > > $ sysctl hw.ata.wc > hw.ata.wc: 1 ok, what do the disks probe as? > > b) how are you writing these files? perhaps we can figure a faster > > way to do the io? did you write the program yourself? What size > > writes are you doing? > > At the moment the files are transferred using FTP. In fact, now matter what optimisation, the > files _must_ be transferred using FTP because of interoperability constraints within my network > environment, so that cannot be changed. What ftp server are you using? > > It's funny, but you have the ideal system for an interesting > > optimization I've always wanted to try. Since you seem to be > > reading over the network, have you tried doing this, creating > > the file and then using ftruncate on it to extend it, then use > > mmap() and read directly from the socket into the mmap'd area. > > I must say that I'm not so much of a system programmer, but I guess that changes to the > ftp-client should be relatively easy. I'll look into it when I have so time. Wait, are you using an ftp server or client? Which "end" is on the FreeBSD box? Have you tried upping the socketbuffer size? What about turning on fast tcp? (it's one of the sysctl rfc options) > > You may have to experiment with several different madvise() flags > > to get optimal performance. Or you may discover that doing this > > "trick" actually makes performance worse because of the way > > the trick screws with what the vm system expects. > > I think a combination of MADV_SEQUENTIAL and/or MADV_WILLNEED > > could do the trick. > > Thank you for your input. As I said, it might take some time before I've implemented this, so > please do not expect results too fast. k :) -- -Alfred Perlstein - [alfred@freebsd.org] Represent yourself, show up at BABUG http://www.babug.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010420070514.R1790>