Re: Async NFS exports?
Emm, I guess that answers my earlier question/mail: Why?---> basil# uname -a FreeBSD basil.dympna.com 3.2-RELEASE FreeBSD 3.2-RELEASE #7: Thu Aug 19 23:59:50 CDT 1999 rs...@basil.dympna.com:/export/current/src/sys/compile/Basil-SMP [Dual PPro-233's] basil# cd /stripe basil# df -k . Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/vinum/stripe 1719751186511 15735200 1%/stripe basil# Bonnie -s 256 ---Sequential Output ---Sequential Input-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU 256 10817 97.3 15805 93.1 6338 41.4 9943 97.5 15796 51.2 basil# mount_nfs -3 localhost:/stripe /mnt basil# cd /mnt basil# Bonnie -s 256 ---Sequential Output ---Sequential Input-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU 256 4270 57.6 6639 30.6 1877 11.7 3804 55.3 6201 18.7 Matthew Dillon wrote: > > :I asked this on stable but didn't get a response... Would I get any > :performance increases by mounting NFS exported partition as Async? > : > :Would my soul be tormented in purgatory for doing it? > : > :Just to be clear... I am wondering if mounting (on the NFS _server_) a > :partition (that is exportable) as async will have any performance > :benefits to the NFS clients? > : > :-Steve > > Ok, I've run some more tests. Basically you want to run NFSv3 under > CURRENT and you want to run at least 3 nfsiod's. On a 100BaseTX network > this will give you unsaturated write performance in the ballpark of > 9 MBytes/sec. Saturated write performance, that is where you write more > then the client-side buffer cache can handle, will stabilize at > 2.5 MBytes/sec. I have a patch for CURRENT which will increase the > saturated write performance to 4.5 MBytes/sec (basically by moving the > nfs_commit() from nfs_writebp() to nfs_doio() so it can be asynchronized). > Hopefully that patch will go in soon but there's a pretty big backlog of > patches that haven't gone in yet, some over a week and a half old, so... > > In anycase, even without the patch if you run a couple of nfsiod's and > do not saturated the buffer cache you should get optimal performance. > > Backing-porting the patch for nfs_commit to STABLE is possible but is > not likely to help much because the major performance restriction in > STABLE is related to buffer cache management, not NFS. > > OS #nfsiod's unsaturated saturated > write perf. write perf. > ( . 100BASETX .. ) > > CURRENT 0 9 MBytes/sec2.5 MBytes/sec > CURRENT 4 9 MBytes/sec4.5 MBytes/sec(w/patch) > > STABLE 0 3 MBytes/sec3 MBytes/sec(1) > STABLE 4 4 MBytes/sec3 MBytes/sec(1) > > note(1): saturated performance under STABLE is extremely inconsistant > > -Matt > Matthew Dillon > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Async NFS exports?
Emm, I guess that answers my earlier question/mail: Why?---> basil# uname -a FreeBSD basil.dympna.com 3.2-RELEASE FreeBSD 3.2-RELEASE #7: Thu Aug 19 23:59:50 CDT 1999 [EMAIL PROTECTED]:/export/current/src/sys/compile/Basil-SMP [Dual PPro-233's] basil# cd /stripe basil# df -k . Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/vinum/stripe 1719751186511 15735200 1%/stripe basil# Bonnie -s 256 ---Sequential Output ---Sequential Input-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU 256 10817 97.3 15805 93.1 6338 41.4 9943 97.5 15796 51.2 basil# mount_nfs -3 localhost:/stripe /mnt basil# cd /mnt basil# Bonnie -s 256 ---Sequential Output ---Sequential Input-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU 256 4270 57.6 6639 30.6 1877 11.7 3804 55.3 6201 18.7 Matthew Dillon wrote: > > :I asked this on stable but didn't get a response... Would I get any > :performance increases by mounting NFS exported partition as Async? > : > :Would my soul be tormented in purgatory for doing it? > : > :Just to be clear... I am wondering if mounting (on the NFS _server_) a > :partition (that is exportable) as async will have any performance > :benefits to the NFS clients? > : > :-Steve > > Ok, I've run some more tests. Basically you want to run NFSv3 under > CURRENT and you want to run at least 3 nfsiod's. On a 100BaseTX network > this will give you unsaturated write performance in the ballpark of > 9 MBytes/sec. Saturated write performance, that is where you write more > then the client-side buffer cache can handle, will stabilize at > 2.5 MBytes/sec. I have a patch for CURRENT which will increase the > saturated write performance to 4.5 MBytes/sec (basically by moving the > nfs_commit() from nfs_writebp() to nfs_doio() so it can be asynchronized). > Hopefully that patch will go in soon but there's a pretty big backlog of > patches that haven't gone in yet, some over a week and a half old, so... > > In anycase, even without the patch if you run a couple of nfsiod's and > do not saturated the buffer cache you should get optimal performance. > > Backing-porting the patch for nfs_commit to STABLE is possible but is > not likely to help much because the major performance restriction in > STABLE is related to buffer cache management, not NFS. > > OS #nfsiod's unsaturated saturated > write perf. write perf. > ( . 100BASETX .. ) > > CURRENT 0 9 MBytes/sec2.5 MBytes/sec > CURRENT 4 9 MBytes/sec4.5 MBytes/sec(w/patch) > > STABLE 0 3 MBytes/sec3 MBytes/sec(1) > STABLE 4 4 MBytes/sec3 MBytes/sec(1) > > note(1): saturated performance under STABLE is extremely inconsistant > > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: writing much slower than reading...
John-Mark, have you double checked your numbers? I get: rsnow@basil% time dd if=/dev/vinum/rstripe of=/dev/null bs=64k count=2048 2048+0 records in 2048+0 records out 134217728 bytes transferred in 8.096565 secs (16577120 bytes/sec) 0.016u 0.482s 0:08.09 6.0% 73+370k 0+0io 0pf+0w On vinum striped 9.1G 'cudas, SMP. -Rob John-Mark Gurney wrote: > > well, I am working on writing a capture program to do 640x480x12bpp@30fps > to a raw disk, but writing to the raw device is SOOO slow... the reason > I say it's slow is the fact that it takes 8 times the system time writing > than reading... > > a bit about the system... k6/2-250, 100mhz system bus, pc100 64meg dimm, > VIA MVP3 chipset (IDE DMA enabled), IBM-DPTA-372730 hard disk, Hauppauge > WinCast/TV Model 61351 B226, 3.3-RELEASE... > > now the hard disk can push and pull around 20meg/sec w/o any problems.. > but when I time the disk I get: > $ time dd if=/dev/rwd0s1g of=/dev/null bs=64k count=2048 > 2048+0 records in > 2048+0 records out > 134217728 bytes transferred in 5.747521 secs (23352281 bytes/sec) > 5.75 real 0.01 user 0.21 sys > $ time dd if=/dev/zero of=/dev/rwd0s1g bs=64k count=2048 > 2048+0 records in > 2048+0 records out > 134217728 bytes transferred in 6.281820 secs (21366057 bytes/sec) > 6.28 real 0.00 user 1.68 sys > > now, why does it cost SOOO much more processing time to write than > read?? are there plans to fix this slow down? is it possible? can't > we just dma write out of userland since we are blocking on the write? > > -- > John-Mark Gurney Voice: +1 408 975 9651 > Cu Networking > > "The soul contains in itself the event that shall presently befall it. > The event is only the actualizing of its thought." -- Ralph Waldo Emerson > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: writing much slower than reading...
{ Moved to FreeBSD-Questions }
Emm, I want your system. Have you double checked your numbers? They
look a bit high. Here's what I get on a vinum stripe across two 'cudas
on an SMP box:
rsnow@basil% time dd if=/dev/vinum/rstripe of=/dev/null bs=64k
count=2048
2048+0 records in
2048+0 records out
134217728 bytes transferred in 7.938773 secs (16906609 bytes/sec)
0.007u 0.520s 0:07.98 6.5% 73+371k 2+0io 0pf+0w
-Rob
John-Mark Gurney wrote:
>
> well, I am working on writing a capture program to do 640x480x12bpp@30fps
> to a raw disk, but writing to the raw device is SOOO slow... the reason
> I say it's slow is the fact that it takes 8 times the system time writing
> than reading...
>
> a bit about the system... k6/2-250, 100mhz system bus, pc100 64meg dimm,
> VIA MVP3 chipset (IDE DMA enabled), IBM-DPTA-372730 hard disk, Hauppauge
> WinCast/TV Model 61351 B226, 3.3-RELEASE...
>
> now the hard disk can push and pull around 20meg/sec w/o any problems..
> but when I time the disk I get:
> $ time dd if=/dev/rwd0s1g of=/dev/null bs=64k count=2048
> 2048+0 records in
> 2048+0 records out
> 134217728 bytes transferred in 5.747521 secs (23352281 bytes/sec)
> 5.75 real 0.01 user 0.21 sys
> $ time dd if=/dev/zero of=/dev/rwd0s1g bs=64k count=2048
> 2048+0 records in
> 2048+0 records out
> 134217728 bytes transferred in 6.281820 secs (21366057 bytes/sec)
> 6.28 real 0.00 user 1.68 sys
>
> now, why does it cost SOOO much more processing time to write than
> read?? are there plans to fix this slow down? is it possible? can't
> we just dma write out of userland since we are blocking on the write?
>
> --
> John-Mark Gurney Voice: +1 408 975 9651
> Cu Networking
>
> "The soul contains in itself the event that shall presently befall it.
> The event is only the actualizing of its thought." -- Ralph Waldo Emerson
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
