Date: Sun, 7 Nov 1999 22:31:57 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: John-Mark Gurney <gurney_j@efn.org> Cc: FreeBSD Hackers <freebsd-hackers@FreeBSD.ORG> Subject: Re: writing much slower than reading... Message-ID: <199911080631.WAA89627@apollo.backplane.com> References: <19991106013045.13836@hydrogen.fircrest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
It doesn't necessarily, but your use of dd is causing the numbers to
look skewed.
It's real simple: when you read from the raw disk into a fixed buffer
the system is DMAing directly into the buffer. dd then 'writes' the
buffer to /dev/null, which is a NOP. There is no effect on the cpu's
L1 and L2 caches because the cpu never reads or copies the data anywhere.
When you write to a raw disk with your dd, it is reading a block from
/dev/zero into its local buffer which involves a zeroing operation
that the read code never had to do, then dd writes the buffer to disk.
So the write test is doing an extra scan of the buffer *and* blowing up
the cpu's L1 and L2 caches due to that scan while the read test is doing
no buffer copies at all so the cpu isn't touching the buffer at all -
leaving the L1 and L2 caches pretty much alone.
-Matt
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?199911080631.WAA89627>