On Fri, Apr 20, 2001 at 05:54:26AM -0700, Alfred Perlstein wrote:
> * Niek Bergboer <[EMAIL PROTECTED]> [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?
> > 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 [EMAIL PROTECTED]:/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
> 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.
> 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.
> 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.
Niek Bergboer
--
Conscience doth make cowards of us all.
-- Shakespeare
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
