On Thu, 02 Aug 2007 20:42:31 +1000, Steve Adam
wrote:


>
>Hi again, Glenn,
>
>The Promise card arrived today, and I installed it

[CUT]

>Both show a touch over 40MB/second on each drive while
>synchronizing a mirror with no other system activity.
>
>Steve.

Thank you very much, Steve.

All of the above will be very useful for me, I'm evaluating a similar
promise model.

In article <176uZD2KcidF-pn2-HbDKF95Phdid@rikki.tavi.co.uk>,
Bob Eager wrote:
>On Fri, 3 Aug 2007 01:32:45 UTC, bv@wjv.com (Bill Vermillion) wrote:
>
>> In article <176uZD2KcidF-pn2-ZJdIDqxstdwk@rikki.tavi.co.uk>,
>> Bob Eager wrote:
>> >On Thu, 2 Aug 2007 13:36:47 UTC, Steve O'Hara-Smith
>> >wrote:
>> >
>> >> On Thu, 02 Aug 2007 20:42:31 +1000
>> >> Steve Adam wrote:
>> >>
>> >> > Another point of interest is that the new card
>> >> > did not show any performance difference that
>> >> > I could see, though it's SATA 300 while the
>> >> > other card is a 150.
>> >>
>> >> I don't think there exist any single drives that can produce data
>> >> faster than SATA 150 can handle, a RAID array with a single SATA connection
>> >> probably can.
>> >
>> >Surely they can deliver data from the cache faster than that?
>>
>> >--
>> >Bob Eager
>> >begin 123 a new life...take up Extreme Ironing!
>>
>> It's not the problem of delivering data from cache, but getting
>> the data from the platter into the cache.
>
>You miss the point.
>
>The burst rate from the cache is higher, and that is what can exceed the
>150kB/s.
>
>> Check the web-sites for you favorite drive, and go to the technical
>> specs section and look for the data transfer rate from platter to
>> cache.
>
>I'm perfectly aware of that, thank you. I never buy a disk without
>reading (and understanding) its specs first.

Then you and I are probably in the minority. Back when drives
started getting faster all everyone could talk about was the
7200RPM drives like the original Baracudda.

But I measured an IBM drive rotating at 5400RPM that had a faster
throughput than the 'cuddas.

The reason was that the IBMs had a smaller head gap and were
writing more data per track, and getting more bits of the platter
at 5400RPM than the 'cuddas did at 7200RPM.

So much of the raving about access time and RPMs came from those
run MS systems that had synchronous writes and that's what
DPT [a local company] started making caching controllers for
MS machines.

The previous year Steve, the owner, described the operation to me
at a demo they had at a Comdex in Atlanta. There were about
20 Wyse50 terminal spewing data to the screen faster than I had
ever seen on any multi-terminal system. The system was
a Heuricon - a company that was making their own Unix machines
along with close to 100 manufacturers - all with slightly different
versions of Unix. Sort of like the Linux world today :-(

Those were really interesting days.

Bill
>
>--
>Bob Eager
>begin 123 a new life...take up Extreme Ironing!


--
Bill Vermillion - bv @ wjv . com

Steve Adam wrote:
> Glenn Middleton wrote:
>> wrote:
>>
>>> I have arranged to buy a Promise SATA300 TX4 which
>>> has 4 ports, no RAID, and seems reasonably priced.
>>>
>>> I'll let you know how it goes, after it arrives.
>> Many thanks, Steve..
>
> Hi again, Glenn,

And again...

Just to let you know... Though the promise card
does seem more reliable than the adaptec, the
TX4 does have errors at times. I haven't seen
any problems during normal system activity (which
is very light on this system) but the following
sequence of commands resulted in a timeout within
about 2 minutes.

# dd if=/dev/ad4 of=/dev/null &
# dd if=/dev/ad6 of=/dev/null &
# find / | wc&
# find / | wc&
# find / | wc&
# find / | wc&

ad4: TIMEOUT - READ_DMA retrying (1 retry left) LBA=171247
ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly
ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly
ad4: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly
ad4: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly
ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly
ad4: TIMEOUT - READ_DMA retrying (1 retry left) LBA=567230
ad4: TIMEOUT - READ_DMA retrying (1 retry left) LBA=585491
ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly
ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly
ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly
ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly
ad6: WARNING - SET_MULTI taskqueue timeout - completing request directly
ad6: TIMEOUT - READ_DMA retrying (1 retry left) LBA=1327372
ad6: TIMEOUT - READ_DMA retrying (1 retry left) LBA=255625419
ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly
ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly
ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly
ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly
ad6: WARNING - SET_MULTI taskqueue timeout - completing request directly
ad6: TIMEOUT - READ_DMA48 retrying (1 retry left) LBA=304159067
ad6: WARNING - READ_DMA48 UDMA ICRC error (retrying request) LBA=304159067
ad6: FAILURE - READ_DMA48 timed out LBA=304159067
GEOM_MIRROR: Request failed (error=5). ad6[READ(offset=155729442304, length=2048)]
GEOM_MIRROR: Device gm0: provider ad6 disconnected.