F
Folkert Rienstra
Ron Reaugh said:
On dual reads.
Not with one read and the other write or with dual writes.
On dual reads.
Not with one read and the other write or with dual writes.
M
Michael Brown
Folkert Rienstra wrote:
[...]
If you're referring to tact, I'd say I very definately fall into the latter
Although I don't think my tone was right, I still stand by (most of) my
original comments (see my longer reply to Eric Gisin). They're based on both
reading of the specs and a substantial amount of testing (though admittedly
a lot of it not directly related to large-file copying [*]). If you or Ron
have something to contribute other than single-word responses or personal
attacks (though I regretfully admit I fired the first shot for this one)
then I'd be interested to hear them. Otherwise, I don't see much point in
continuing this thread.
[*] At one point in time, I was doing the planning for an MP3 player (as
many people have) and completed about half the IDE interface before I lost
interest due to cost reasons (I picked an overly powerful DSP that required
a rather expensive PCB layout). I did a substantial amount of testing with
low-level ATA stuff, since I was hoping to run both a (normal, desktop)
CDRom drive and a (laptop) hard drive off a single channel. The idea was to
buffer the file from the CDRom into the more shock-resistant hard disk, and
play it from there. The issue I ran into was that due to the continuous
needs of the DSP, and the effectively zero buffer on the microcontroller,
things stuffed up at the end of the song as the CDRom drive was stalling the
bus sufficiently to break up the stream of data from the HDD to the DSP.
This got me curious as to exactly how stalls affected the bus, and one part
of that was the test I did with the Seagates.
[...]
If you're referring to tact, I'd say I very definately fall into the latter
Although I don't think my tone was right, I still stand by (most of) myoriginal comments (see my longer reply to Eric Gisin). They're based on both
reading of the specs and a substantial amount of testing (though admittedly
a lot of it not directly related to large-file copying [*]). If you or Ron
have something to contribute other than single-word responses or personal
attacks (though I regretfully admit I fired the first shot for this one)
then I'd be interested to hear them. Otherwise, I don't see much point in
continuing this thread.
[*] At one point in time, I was doing the planning for an MP3 player (as
many people have) and completed about half the IDE interface before I lost
interest due to cost reasons (I picked an overly powerful DSP that required
a rather expensive PCB layout). I did a substantial amount of testing with
low-level ATA stuff, since I was hoping to run both a (normal, desktop)
CDRom drive and a (laptop) hard drive off a single channel. The idea was to
buffer the file from the CDRom into the more shock-resistant hard disk, and
play it from there. The issue I ran into was that due to the continuous
needs of the DSP, and the effectively zero buffer on the microcontroller,
things stuffed up at the end of the song as the CDRom drive was stalling the
bus sufficiently to break up the stream of data from the HDD to the DSP.
This got me curious as to exactly how stalls affected the bus, and one part
of that was the test I did with the Seagates.
F
Folkert Rienstra
Michael Brown said:
It appears about normal from what usually comes from your part of the world.
Not in that post.
Maybe because that is what you really think and why you had to correct yourself?
Twice.
Which because of the sheer size of it and the odd linebreaks nobody might
read. And when you use mbytes (millibytes) when you mean MB (MegaBytes)
and that drives read and send sector for sector to the interface or read sector
for sector from the interface then I won't even bother to read further.
F
Folkert Rienstra
Michael Brown said:
Yes, it does. That is exactly the situation where 2 drives on a channel
do not sit in each others way:
Sequential reading which caches ahead and writing that doesn't hog the bus.
Write buffer?
What write buffer?
Gee, wonder what read-ahead caching is for then when it can't do anything.
That is why it is called a cache, a place where the data can be held until the
host requests it the next time that the bus is free.
Pure nonsense.
So what?
That is to the host. The host then sends it to the destination.
The action is serial whether single channel or dual channel. The interface runs
at twice the speed a single drive needs so running the action in series doesn't
loose them any transfer speed when run from read ahead cache to write buffer.
When the source drive reads 128kB to the transfer buffer that is transferred
to the host and then send to destination, it reads another chunk to the readahead
cache. The destination drive accepts the data in its buffer and then releases the
bus immediately. While the destination drive is writing from it's buffer the next
command is send to the source drive which then already finds it's requested data
filling the cache.
So as Eric said:
"so the host is transfering to/from the cache and both drives read and write at the same time".
[gibber snipped]
R
Ron Reaugh
Michael Brown said:
That's flat false. The drive's onboard read and write caching are CRITICAL
to such an operation.
Just NO!
NO, what HDs have either a 12mb or 12 MB buffer?
Drivel ignored.
F
Folkert Rienstra
- HAL9000 said:
A command is always for a contiguous part of data so there is no waiting for
revolutions other than as part of the access time directly from the start of
the command. Commands are limited to a maximum of 128kB (256 sectors).
If you mean 1) for the read and 3) for the write, then yes.
The system however doesn't need to wait for the write to finish, so the
read drive can get its follow-up command while the write drive is writing.
Of course the write drive isn't available until it has finished the writing.
Because of the commands are for contiguous data there is only head and
cylinder switches to deal with after the initial access seek and latency.
For OS related overhead only.