From owner-freebsd-hackers Sun Nov 7 22:32: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 44E691501F for ; Sun, 7 Nov 1999 22:31:59 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA89627; Sun, 7 Nov 1999 22:31:57 -0800 (PST) (envelope-from dillon) Date: Sun, 7 Nov 1999 22:31:57 -0800 (PST) From: Matthew Dillon Message-Id: <199911080631.WAA89627@apollo.backplane.com> To: John-Mark Gurney Cc: FreeBSD Hackers Subject: Re: writing much slower than reading... References: <19991106013045.13836@hydrogen.fircrest.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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