Arne Wörner wrote:
Hi!
--- Patrick Proniewski <[EMAIL PROTECTED]> wrote:
Can u find out, if DMA transfers are enabled for those discs?
What does dmesg say?
see end of mail for full dmesg output,
Looks good... :-)) But I never saw FBSD's kernel messages about
SATA drives... ;-)
Maybe atacontrol(8) says something useful about SATA discs,
too (e. g. atacontrol mode 0)?
# atacontrol mode 0
Master = BIOSPIO
Slave = BIOSPIO
Hmm... 0 seems to be the wrong ata... Thats why the output does
not fit to SATA drives, I think...
# dd if=/dev/ad4 of=/dev/null bs=1m count=1000
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 17.647464 secs (59417943
bytes/sec)
That seems to be 2 or about 2 times faster than disc->disc
transfer... But still slower, than I would have expected...
SATA150 sounds like the drive can do 150MB/sec...
As far as I know, SATA busses are independant from each other (no
master/slave; every drive gets its own cable)... Maybe "dd" cannot
issue a read request, while the write isn't completed? DMA
shouldn't be the problem, since the memory interface is quite fast
in your case...
So there remain the questions:
1. Why does the read speed drop in ur setting (maybe writing to
ad6 takes more time than reading from ad4? u could try to run two
dd processes one with if=ad4 and the other with if=ad6)?
2. Why can't we reach 150MB/sec?
The reason why 35-40MB/s is good is because the drive itself cannot
stream any faster. SATA-150 interface is rated at 150MB/s, but the disk
cannot get close. Look at the specs for the drive, and you'll see that
the sustained rate is much lower than the burst speed. If you want fast
performance on a SATA disk, you'll need to buy a WD Raptor drive (74GB)
- that will get you more speed, but still not the 150MB/s.
(Maybe you could find a way to copy /dev/zero to /dev/ad6
without destroying the previous work... :-))
well, not very easy both disk are the same size ;)
I thought of the first 1000 1MB blocks... :-)
The write speed might be interesting...
Instead of dd, why not use gmirror?
Also - reads can be faster since the drive can read-ahead a number of
blocks into the cache in an efficient manner, but writes have to be
streamed to disk as they come in (going through the cache, and
buffering, but you get the idea).
Have you tried a smaller block size? What does 8k, 16k, or 512k do for
you? There really isn't much room for improvement here on a single device.
Eric
--
------------------------------------------------------------------------
Eric Anderson Sr. Systems Administrator Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------
_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
