http://www.wwpi.com/cables-a-connect...idth-selection
It looks like this link indicates 1600 MB per second, yet it
does not specify that this is sustained throughput. Can
someone please confirm this?

"Peter Olcott" <NoSpam@SeeScreen.com> wrote in message
news:Kzbtk.23893$9u1.9876@newsfe09.iad...
>
> http://www.wwpi.com/cables-a-connect...idth-selection
> It looks like this link indicates 1600 MB per second, yet it does not
> specify that this is sustained throughput. Can someone please confirm
> this?

This is not the speed of the drives in the setup, its the speed of the bus.
There are no moving parts or seek times to consider, so through can be
sustained on the bus as long as the hardware at each end can cope.

Not sure where you will find hard disks (in any sort of array) that can
sustain those kinds of speeds though.

"GT" <ContactGT_rem_ove_this_@hotmail.com> wrote in message
news:03261fad$0$11425$c3e8da3@news.astraweb.com...
> "Peter Olcott" <NoSpam@SeeScreen.com> wrote in message
> news:Kzbtk.23893$9u1.9876@newsfe09.iad...
>>
>> http://www.wwpi.com/cables-a-connect...idth-selection
>> It looks like this link indicates 1600 MB per second, yet
>> it does not specify that this is sustained throughput.
>> Can someone please confirm this?
>
> This is not the speed of the drives in the setup, its the
> speed of the bus. There are no moving parts or seek times
> to consider, so through can be sustained on the bus as
> long as the hardware at each end can cope.
>
> Not sure where you will find hard disks (in any sort of
> array) that can sustain those kinds of speeds though.
>

http://www.dulcesystems.com:80/html/pro_rx.html
This system will do 800 MB / second, that may be the limit
of current technology.

"GT" <ContactGT_rem_ove_this_@hotmail.com> wrote in message
news:03261fad$0$11425$c3e8da3@news.astraweb.com...
> "Peter Olcott" <NoSpam@SeeScreen.com> wrote in message
> news:Kzbtk.23893$9u1.9876@newsfe09.iad...
>>
>> http://www.wwpi.com/cables-a-connect...idth-selection
>> It looks like this link indicates 1600 MB per second, yet
>> it does not specify that this is sustained throughput.
>> Can someone please confirm this?
>
> This is not the speed of the drives in the setup, its the
> speed of the bus. There are no moving parts or seek times
> to consider, so through can be sustained on the bus as
> long as the hardware at each end can cope.
>
> Not sure where you will find hard disks (in any sort of
> array) that can sustain those kinds of speeds though.
>

http://www.violin-memory.com/assets/techbrief_gen1.pdf
Here is another option in case anyone cares, 1400 mb per
second.

Peter Olcott wrote:
> "GT" <ContactGT_rem_ove_this_@hotmail.com> wrote in message
> news:03261fad$0$11425$c3e8da3@news.astraweb.com...
>> "Peter Olcott" <NoSpam@SeeScreen.com> wrote in message
>> news:Kzbtk.23893$9u1.9876@newsfe09.iad...
>>> http://www.wwpi.com/cables-a-connect...idth-selection
>>> It looks like this link indicates 1600 MB per second, yet
>>> it does not specify that this is sustained throughput.
>>> Can someone please confirm this?
>> This is not the speed of the drives in the setup, its the
>> speed of the bus. There are no moving parts or seek times
>> to consider, so through can be sustained on the bus as
>> long as the hardware at each end can cope.
>>
>> Not sure where you will find hard disks (in any sort of
>> array) that can sustain those kinds of speeds though.
>>
>
> http://www.violin-memory.com/assets/techbrief_gen1.pdf
> Here is another option in case anyone cares, 1400 mb per
> second.
>
>

The big win on an appliance like that, is the seek time.

Seek is one of the irritating limits of something like
a 16 disk RAID array. Plenty of bandwidth, but relatively
long delays before the array is returning data. That SSD/Ramdisk
is one way to fix it, even if it "only" supports 504GB of
RAM.

Paul

"Paul" <nospam@needed.com> wrote in message
news:g97khg$jc6$1@aioe.org...
> Peter Olcott wrote:
>> "GT" <ContactGT_rem_ove_this_@hotmail.com> wrote in
>> message
>> news:03261fad$0$11425$c3e8da3@news.astraweb.com...
>>> "Peter Olcott" <NoSpam@SeeScreen.com> wrote in message
>>> news:Kzbtk.23893$9u1.9876@newsfe09.iad...
>>>> http://www.wwpi.com/cables-a-connect...idth-selection
>>>> It looks like this link indicates 1600 MB per second,
>>>> yet it does not specify that this is sustained
>>>> throughput. Can someone please confirm this?
>>> This is not the speed of the drives in the setup, its
>>> the speed of the bus. There are no moving parts or seek
>>> times to consider, so through can be sustained on the
>>> bus as long as the hardware at each end can cope.
>>>
>>> Not sure where you will find hard disks (in any sort of
>>> array) that can sustain those kinds of speeds though.
>>>
>>
>> http://www.violin-memory.com/assets/techbrief_gen1.pdf
>> Here is another option in case anyone cares, 1400 mb per
>> second.
>
> The big win on an appliance like that, is the seek time.
>
> Seek is one of the irritating limits of something like
> a 16 disk RAID array. Plenty of bandwidth, but relatively
> long delays before the array is returning data. That
> SSD/Ramdisk
> is one way to fix it, even if it "only" supports 504GB of
> RAM.
>
> Paul

I don't seek why seek time can not be amortized across
multiple disks.

Peter Olcott wrote:
> "Paul" <nospam@needed.com> wrote in message
> news:g97khg$jc6$1@aioe.org...
>> Peter Olcott wrote:
>>> "GT" <ContactGT_rem_ove_this_@hotmail.com> wrote in
>>> message
>>> news:03261fad$0$11425$c3e8da3@news.astraweb.com...
>>>> "Peter Olcott" <NoSpam@SeeScreen.com> wrote in message
>>>> news:Kzbtk.23893$9u1.9876@newsfe09.iad...
>>>>> http://www.wwpi.com/cables-a-connect...idth-selection
>>>>> It looks like this link indicates 1600 MB per second,
>>>>> yet it does not specify that this is sustained
>>>>> throughput. Can someone please confirm this?
>>>> This is not the speed of the drives in the setup, its
>>>> the speed of the bus. There are no moving parts or seek
>>>> times to consider, so through can be sustained on the
>>>> bus as long as the hardware at each end can cope.
>>>>
>>>> Not sure where you will find hard disks (in any sort of
>>>> array) that can sustain those kinds of speeds though.
>>>>
>>> http://www.violin-memory.com/assets/techbrief_gen1.pdf
>>> Here is another option in case anyone cares, 1400 mb per
>>> second.
>> The big win on an appliance like that, is the seek time.
>>
>> Seek is one of the irritating limits of something like
>> a 16 disk RAID array. Plenty of bandwidth, but relatively
>> long delays before the array is returning data. That
>> SSD/Ramdisk
>> is one way to fix it, even if it "only" supports 504GB of
>> RAM.
>>
>> Paul
>
> I don't seek why seek time can not be amortized across
> multiple disks.
>

If the seek time is 3 microseconds on that DRAM based SSD, and
11 milliseconds on a hard drive, it is pretty hard to make the
thousandfold difference go away. The SSD is just blindingly fast,
and perfect for things like databases. Too bad the purchase
price would be so high. They're priced for enterprise usage,
so the price is not even a reflection of the price of the
RAM used in them - 500GB of RAM would cost about $12500, and
the SSD would be priced at many times that number. It would be
a bargain at $50000, and depending on the patent situation, and
how many companies make them, it could be a lot more expensive.
Maybe closer to $100000. And that is why lowly hard drives
are so attractive :-)

Paul

On Aug 29, 5:57*am, Paul <nos...@needed.com> wrote:
> Peter Olcott wrote:
> > "Paul" <nos...@needed.com> wrote in message
> >news:g97khg$jc6$1@aioe.org...
> >> Peter Olcott wrote:
> >>> "GT" <ContactGT_rem_ove_th...@hotmail.com> wrote in
> >>> message
> >>>news:03261fad$0$11425$c3e8da3@news.astraweb.com ...
> >>>> "Peter Olcott" <NoS...@SeeScreen.com> wrote in message
> >>>>news:Kzbtk.23893$9u1.9876@newsfe09.iad...
> >>>>>http://www.wwpi.com/cables-a-connect...rformance-unpr...
> >>>>> It looks like this link indicates 1600 MB per second,
> >>>>> yet it does not specify that this is sustained
> >>>>> throughput. Can someone please confirm this?
> >>>> This is not the speed of the drives in the setup, its
> >>>> the speed of the bus. There are no moving parts or seek
> >>>> times to consider, so through can be sustained on the
> >>>> bus as long as the hardware at each end can cope.
>
> >>>> Not sure where you will find hard disks (in any sort of
> >>>> array) that can sustain those kinds of speeds though.
>
> >>> * *http://www.violin-memory.com/assets/techbrief_gen1.pdf
> >>> Here is another option in case anyone cares, 1400 mb per
> >>> second.
> >> The big win on an appliance like that, is the seek time.
>
> >> Seek is one of the irritating limits of something like
> >> a 16 disk RAID array. Plenty of bandwidth, but relatively
> >> long delays before the array is returning data. That
> >> SSD/Ramdisk
> >> is one way to fix it, even if it "only" supports 504GB of
> >> RAM.
>
> >> * *Paul
>
> > I don't seek why seek time can not be amortized across
> > multiple disks.
>
> If the seek time is 3 microseconds on that DRAM based SSD, and
> 11 milliseconds on a hard drive, it is pretty hard to make the
> thousandfold difference go away. The SSD is just blindingly fast,
> and perfect for things like databases. Too bad the purchase
> price would be so high. They're priced for enterprise usage,
> so the price is not even a reflection of the price of the
> RAM used in them - 500GB of RAM would cost about $12500, and
> the SSD would be priced at many times that number. It would be
> a bargain at $50000, and depending on the patent situation, and
> how many companies make them, it could be a lot more expensive.
> Maybe closer to $100000. And that is why lowly hard drives
> are so attractive :-)
>
> * * Paul- Hide quoted text -
>
> - Show quoted text -

http://www.nextlevelhardware.com/storage/barracuda/
Using these numbers for the Seagate Barracuda 7200.11
(1) Access time 12.4 MS or 80 random Accesses per second
(2) Sustained read rate 89.6 MB per second

Assuming that all of the data is contiguous, (no file fragmentation),
why couldn't 24 drive RAID 1 system provide this sustained read rate:
23/24 * 89.6 * 24 = 2060 MB per second?

23/24 is because each drive only has to spend 1/24 of its time
seeking, and the remaining time can be spent reading.

PeteOlcott wrote:
> On Aug 29, 5:57 am, Paul <nos...@needed.com> wrote:
>> Peter Olcott wrote:
>>> "Paul" <nos...@needed.com> wrote in message
>>> news:g97khg$jc6$1@aioe.org...
>>>> Peter Olcott wrote:
>>>>> "GT" <ContactGT_rem_ove_th...@hotmail.com> wrote in
>>>>> message
>>>>> news:03261fad$0$11425$c3e8da3@news.astraweb.com...
>>>>>> "Peter Olcott" <NoS...@SeeScreen.com> wrote in message
>>>>>> news:Kzbtk.23893$9u1.9876@newsfe09.iad...
>>>>>>> http://www.wwpi.com/cables-a-connect...rformance-unpr...
>>>>>>> It looks like this link indicates 1600 MB per second,
>>>>>>> yet it does not specify that this is sustained
>>>>>>> throughput. Can someone please confirm this?
>>>>>> This is not the speed of the drives in the setup, its
>>>>>> the speed of the bus. There are no moving parts or seek
>>>>>> times to consider, so through can be sustained on the
>>>>>> bus as long as the hardware at each end can cope.
>>>>>> Not sure where you will find hard disks (in any sort of
>>>>>> array) that can sustain those kinds of speeds though.
>>>>> http://www.violin-memory.com/assets/techbrief_gen1.pdf
>>>>> Here is another option in case anyone cares, 1400 mb per
>>>>> second.
>>>> The big win on an appliance like that, is the seek time.
>>>> Seek is one of the irritating limits of something like
>>>> a 16 disk RAID array. Plenty of bandwidth, but relatively
>>>> long delays before the array is returning data. That
>>>> SSD/Ramdisk
>>>> is one way to fix it, even if it "only" supports 504GB of
>>>> RAM.
>>>> Paul
>>> I don't seek why seek time can not be amortized across
>>> multiple disks.
>> If the seek time is 3 microseconds on that DRAM based SSD, and
>> 11 milliseconds on a hard drive, it is pretty hard to make the
>> thousandfold difference go away. The SSD is just blindingly fast,
>> and perfect for things like databases. Too bad the purchase
>> price would be so high. They're priced for enterprise usage,
>> so the price is not even a reflection of the price of the
>> RAM used in them - 500GB of RAM would cost about $12500, and
>> the SSD would be priced at many times that number. It would be
>> a bargain at $50000, and depending on the patent situation, and
>> how many companies make them, it could be a lot more expensive.
>> Maybe closer to $100000. And that is why lowly hard drives
>> are so attractive :-)
>>
>> Paul- Hide quoted text -
>>
>> - Show quoted text -
>
> http://www.nextlevelhardware.com/storage/barracuda/
> Using these numbers for the Seagate Barracuda 7200.11
> (1) Access time 12.4 MS or 80 random Accesses per second
> (2) Sustained read rate 89.6 MB per second
>
> Assuming that all of the data is contiguous, (no file fragmentation),
> why couldn't 24 drive RAID 1 system provide this sustained read rate:
> 23/24 * 89.6 * 24 = 2060 MB per second?
>
> 23/24 is because each drive only has to spend 1/24 of its time
> seeking, and the remaining time can be spent reading.
>
>

I'm not arguing that you cannot sustain some large transfer rate
using hard drives (with the right access pattern). But once random
access is added to the picture, and relatively small transfers are
involved, most of the performance time is dominated by head movement.
11 milliseconds moving the head, read 4KB of data, 11 milliseconds
moving the head, read another 4KB of data. Real world applications
do some amount of head movement.

Take my machine as an example. If I use the Search command in Windows,
it might take 2 minutes to run and search all the files. The computer
is not reading a lot of data during that time, but there is a ton of
head movement. If I had that SSD, my search would complete in a couple
seconds. (The 2 minute figure, might be after a reboot, when the
OS file cache is empty.)

On RAID1 with two disks, in theory, on a read, both disks can return
data, and the controller can accept the data from the drive that
finishes first. That helps to reduce the average seek time, by a bit.
Whether that optimization is used on motherboard "soft RAID"
implementations, is unclear to me. That would be one way to reduce
the effects of the seek time, but only on read operations.

Paul

"Paul" <nospam@needed.com> wrote in message
news:g98kec$fac$1@aioe.org...
> Peter Olcott wrote:
>> "Paul" <nospam@needed.com> wrote in message
>> news:g97khg$jc6$1@aioe.org...
>>> Peter Olcott wrote:
>>>> "GT" <ContactGT_rem_ove_this_@hotmail.com> wrote in
>>>> message
>>>> news:03261fad$0$11425$c3e8da3@news.astraweb.com...
>>>>> "Peter Olcott" <NoSpam@SeeScreen.com> wrote in message
>>>>> news:Kzbtk.23893$9u1.9876@newsfe09.iad...
>>>>>> http://www.wwpi.com/cables-a-connect...idth-selection
>>>>>> It looks like this link indicates 1600 MB per second,
>>>>>> yet it does not specify that this is sustained
>>>>>> throughput. Can someone please confirm this?
>>>>> This is not the speed of the drives in the setup, its
>>>>> the speed of the bus. There are no moving parts or
>>>>> seek times to consider, so through can be sustained on
>>>>> the bus as long as the hardware at each end can cope.
>>>>>
>>>>> Not sure where you will find hard disks (in any sort
>>>>> of array) that can sustain those kinds of speeds
>>>>> though.
>>>>>
>>>>
>>>> http://www.violin-memory.com/assets/techbrief_gen1.pdf
>>>> Here is another option in case anyone cares, 1400 mb
>>>> per second.
>>> The big win on an appliance like that, is the seek time.
>>>
>>> Seek is one of the irritating limits of something like
>>> a 16 disk RAID array. Plenty of bandwidth, but
>>> relatively
>>> long delays before the array is returning data. That
>>> SSD/Ramdisk
>>> is one way to fix it, even if it "only" supports 504GB
>>> of
>>> RAM.
>>>
>>> Paul
>>
>> I don't seek why seek time can not be amortized across
>> multiple disks.
>
> If the seek time is 3 microseconds on that DRAM based SSD,
> and
> 11 milliseconds on a hard drive, it is pretty hard to make
> the
> thousandfold difference go away. The SSD is just
> blindingly fast,
> and perfect for things like databases. Too bad the
> purchase
> price would be so high. They're priced for enterprise
> usage,
> so the price is not even a reflection of the price of the
> RAM used in them - 500GB of RAM would cost about $12500,
> and
> the SSD would be priced at many times that number. It
> would be
> a bargain at $50000, and depending on the patent
> situation, and
> how many companies make them, it could be a lot more
> expensive.
> Maybe closer to $100000. And that is why lowly hard drives
> are so attractive :-)
>
> Paul

All that I would need is a pc that can handle 24 hard-drives
and run windows and I would make my own RAID-1 system that
would provide 2000 MB per second sustained read performance.
I would merely seek once per drive, to a place that is in
increments of 1/24 of the size of the file into a different
(1/24th of the file sized increment) offsets of a single
contiguous buffer, and read a block that is 1/24 of the file
size from each drive. For writing I would have to write
every block to every drive. I may be able to get by with 12
hard-drive controller cards.