On 3/5/06, Beastie [EMAIL PROTECTED] wrote:
Nikolas Britton wrote:
On 3/3/06, Alex Zbyslaw [EMAIL PROTECTED] wrote:
Nikolas Britton wrote:
Please can you be careful when you attribute your comments. You've sent
this
email to me, and left only my name in the attributions as if I
were
Nikolas Britton wrote:
On 3/5/06, Beastie [EMAIL PROTECTED] wrote:
Nikolas Britton wrote:
On 3/3/06, Alex Zbyslaw [EMAIL PROTECTED] wrote:
Nikolas Britton wrote:
Please can you be careful when you attribute your comments. You've sent
this
email to me, and
Nikolas Britton wrote:
On 3/3/06, Alex Zbyslaw [EMAIL PROTECTED] wrote:
Nikolas Britton wrote:
Please can you be careful when you attribute your comments. You've sent
this email to me, and left only my name in the attributions as if I
were someone suggesting either dd or diskinfo as
Nikolas Britton wrote:
Please can you be careful when you attribute your comments. You've sent
this email to me, and left only my name in the attributions as if I
were someone suggesting either dd or diskinfo as accurate benchmarks,
when in fact my contribution was to suggest unixbench and
On 3/3/06, Alex Zbyslaw [EMAIL PROTECTED] wrote:
Nikolas Britton wrote:
Please can you be careful when you attribute your comments. You've sent
this email to me, and left only my name in the attributions as if I
were someone suggesting either dd or diskinfo as accurate benchmarks,
when in
Your performance sucks because, to quote the manual, Input data is
read and written in 512-byte blocks.
Try a sensible blocksize. 16k would mimic a standard file system
block, but even that is likely to underestimate. If you were, say,
copying the disk to another you could easily use
Beastie wrote:
second tools is diskinfo, but i'm not quite happy with the result.
#diskinfo -t /dev/amrd0s1d
/dev/amrd0s1d
512 # sectorsize
96609024# mediasize in bytes (931G)
1953118377 # mediasize in sectors
121575 # Cylinders
On 3/2/06, Alex Zbyslaw [EMAIL PROTECTED] wrote:
[snipped]
Why not happy? Transfer rates from 53 to 92Mb/s, give or take; what's
wrong with that? On a plain sata disk I get:
Seek times:
Full stroke: 250 iter in 4.717248 sec = 18.869 msec
Half stroke: 250
Nikolas Britton wrote:
This and all the other benchmarks you've run are useless. Run a real
benchmark like iozone. It's in ports under benchmarks/iozone.
http://www.iozone.org/
Please can you be careful when you attribute your comments. You've sent
this email to me, and left only my name
On 3/2/06, Alex Zbyslaw [EMAIL PROTECTED] wrote:
Nikolas Britton wrote:
This and all the other benchmarks you've run are useless. Run a real
benchmark like iozone. It's in ports under benchmarks/iozone.
http://www.iozone.org/
Please can you be careful when you attribute your comments.
Beastie wrote:
Beastie wrote:
Robert Uzzi wrote:
That still dosen't connedt SATA to a non sata board though. That's my
situation I have 6 SATA drives but no SATA native board. Looking for a
cheap addin card to build this upon.
I'll buy Intel SRCS16 (500$) this week, will talk to u
Beastie wrote:
I try to test with dd simple command
dd if=/dev/amrd0s1d of=/dev/null
^C31297+0 records in
31297+0 records out
16024064 bytes transferred in 7.970548 secs (2010409 bytes/sec)
the result is very slow performance (-+ 2 Mbytes/sec), with write
cache enable on drive. :(
Your
Your performance sucks because, to quote the manual, Input data is
read and written in 512-byte blocks.
Try a sensible blocksize. 16k would mimic a standard file system
block, but even that is likely to underestimate. If you were, say,
copying the disk to another you could easily use
Beastie wrote:
Robert Uzzi wrote:
That still dosen't connedt SATA to a non sata board though. That's my
situation I have 6 SATA drives but no SATA native board. Looking for a
cheap addin card to build this upon.
I'll buy Intel SRCS16 (500$) this week, will talk to u later about
it's
14 matches
Mail list logo
