>> > random access times are dominated primarily by disk head seek time,
which is gonna be the same no matter what the transport to the drive
>> is.
>> > So the slower transport won't matter nearly as much with random I/O
as it will with sequential.
>>
>> This is not quite correct,
>
> i never said it was completely "correct", i said "dominated primarily"
and "won't matter nearly as much".

I meant, of course, that your statements aren't quite correct, but I had
misunderstood what you meant.  Disk head seek time does dominate over
transfer time at the disk level for random reads, but it doesn't
necessarily dominate over the latency and bandwidth constraints imposed by
USB (some of which will naturally be hardware and software dependent, and
certainly depending on the seek speed of the drive, by way of comparison.)

I should probably explain a bit better, which I think I can do using a
thought experiment, wherein the computer tells a hard drive to seek to the
middle, then the edge of the disk, once using SATA, and once adding USB to
the commands in each direction -- the drive head won't actually start
moving to the edge of the disk until it receives the second command.  So,
for simplicity's sake, if we say the drive seeks middle-to-edge in 10 ms,
and there's a 1 ms latency in USB, the SATA seek will take 10 ms, and the
USB seek will take 12 ms before the data can be transferred.

My point is that the drive can't take advantage of the fact that it's not
receiving data from the USB bus to position the head, because it doesn't
know where the head's supposed to be until it receives the USB command --
so slow seek times tend to be magnified by slower transport methods for
random access.

THAT being said, since the bandwidth constraint is less relevant due to
waiting for data, you're right in the sense that if drive heads need to
seek to the extent that they can't saturate the USB bus, then the speed of
the bus doesn't matter as much.

> I don't know what kind of additional latency USB has vs. SATA, a quick
web search didn't show me anything useful.

I haven't found anything particularly useful either, I'm afraid, and some
of the numbers out there are hard to believe.

> I'm sure there's some, but I'd be surprised to see numbers that showed
that the extra latency for USB is significant compared to the average
time-to-access inherent in the disk mechanism (avg seek + avg rotational
latency).  Let's guess that it adds 10% to the total latency of a
request. Maybe i'm way off-base here, feel free to provide data.

My point is that any latency tends to magnify the seek times, while drive
seeking tends to desaturate the USB bus.  (This probably isn't much
different from what you're saying.)

> My own real-world measurements showed, with the same target hard disk,
25 MB/sec bulk throughput via USB2 and 40MB/sec throughput via eSATA.
>
> I was surprised at how slow the eSATA throughput was, actually, but did
not investigate further.
>
> The test was done on a linux system, dd'ing from a fast disk array to
the target hard disk.
>
>> It's probably worth keeping in mind that a USB 2.0 attached drive is
actually attached to either a SATA or an IDE controller; so you're
either
>> comparing USB+SATA or USB+IDE to eSATA.
>
> sure, and it's easy to remove this source of error by using the same
sata hard disk for each set of measurements.

If you're using the same drive, then it would seem you're only measuring
the additional bandwidth and latency constraints of USB.  What I'd expect
from a curve is that as the amount of raw data transferred *from* the
drive gets smaller, then the speed difference between USB and SATA would
tend to decrease.  As data is *written,* however, I'd expect the curve to
be gentler if the data needs to be flushed, and sharper if it doesn't need
to wait and can simply saturate the bus.

My interpretation of when you said "random I/O" is that it included both
reads and writes, in which case, I'd expect the slowness to experience a
magnifying effect -- which is what I've seen in quite limited and
unscientific tests I've done with BackupPC.



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/