I want to set up a network music server with one client, a single machine in
my listening room.

Since actual throughput on a 100 mb network depends to a great extent on
factors other than the actual physical layer, I'd appreciate any rules of
thumb determined by experience. A single channel is about 2.3 mb/second, 8
channels = 18.4 mb/second.

I want to feed an 8-channel D/A, at 96/24 resolution, directly from Adobe
Audition, but the files will be on the server. Both machines will run
Windows 2000, with Ethernet adaptors on standard 32 bit PCI buses.

Is this actually practical with desktop machines you've used?

"Robert Morein" wrote in message ...
I want to set up a network music server with one client, a single machine in
my listening room.

Since actual throughput on a 100 mb network depends to a great extent on
factors other than the actual physical layer, I'd appreciate any rules of
thumb determined by experience. A single channel is about 2.3 mb/second, 8
channels = 18.4 mb/second.

I want to feed an 8-channel D/A, at 96/24 resolution, directly from Adobe
Audition, but the files will be on the server. Both machines will run
Windows 2000, with Ethernet adaptors on standard 32 bit PCI buses.

Is this actually practical with desktop machines you've used?

Doing the math 100 Mb should handle the load. However, considering the
low cost of network adapters I would recommend going Gigabit anyway.

"Robert Morein" wrote in message

I want to set up a network music server with one client, a single
machine in my listening room.

Since actual throughput on a 100 mb network depends to a great extent
on factors other than the actual physical layer, I'd appreciate any
rules of thumb determined by experience. A single channel is about
2.3 mb/second, 8 channels = 18.4 mb/second.

I want to feed an 8-channel D/A, at 96/24 resolution, directly from
Adobe Audition, but the files will be on the server. Both machines
will run Windows 2000, with Ethernet adaptors on standard 32 bit PCI
buses.

Is this actually practical with desktop machines you've used?

What you're doing relates to me recording and mixing 12 32/44 channels which
I do reliably all the time, except you're talking about doubling the load.
The simple answer is bag the 96 KHz sampling, but I know your audio
politics.

100BTX is not the most efficient user of media around. Bursts of 20 MB/Sec
are doable, but for this application we need to look at the whole system. If
you have a disk subsystem that is capable of a sustained 20 MB/sec locally,
its not going to be 20 MB/Sec across a 100BTX network.

Based on my experience, getting a reliable, sustained 20 MB/sec off a
commodity 7200 rpm hard drive *without* a network layer in place can be iffy
unless the environment is pretty well controlled and the disks have pretty
high performance. For example, I would at minimum recommend a l hard drive
subsystem composed something like a well-defragged 2-way stripe set made up
of 7200 rpm 160 GB ATA drives. You don't need the striping for speed when
the array is nearly empty, but you probably will need striping when it is
nearly full. Striping gets you consistancy, not raw speed.

"Robert Morein" wrote in
:

Since actual throughput on a 100 mb network depends to a great extent
on factors other than the actual physical layer, I'd appreciate any
rules of thumb determined by experience. A single channel is about
2.3 mb/second, 8 channels = 18.4 mb/second.

Are these MegaBytes per second or Megabits? Because a 100 base T network
runs at a theoretical 100megabits or ~12.8MB/s. In reality you're
looking at 80mbits top or 10MB/s.

I want to feed an 8-channel D/A, at 96/24 resolution, directly from
Adobe Audition, but the files will be on the server. Both machines
will run Windows 2000, with Ethernet adaptors on standard 32 bit PCI
buses.

Is this actually practical with desktop machines you've used?

You may want to upgrade to Gigabit ethernet.

Someone else mentioned hard drive speed - modern hard drives can easily
sustain 30MB/s if the drive is not fragmented heavily. To ensure
reliability you might want to put a dedicated recording disk on the
server. Drives are cheap - you can pick up a very good 80GB disk for ~
60.00USD. The striped RAID idea is good too, if you have enough drive
bays. But just be aware... on a striped array, if one of the 2 disks
crash, you lose ALL the data on both drives.

--
Lucas Tam )
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/

Lucas Tam wrote:

"Robert Morein" wrote in
:


Since actual throughput on a 100 mb network depends to a great extent
on factors other than the actual physical layer, I'd appreciate any
rules of thumb determined by experience. A single channel is about
2.3 mb/second, 8 channels = 18.4 mb/second.


Are these MegaBytes per second or Megabits? Because a 100 base T network
runs at a theoretical 100megabits or ~12.8MB/s. In reality you're
looking at 80mbits top or 10MB/s.

I'm pretty sure he means megabits/second. The calculation he's
using is probably this:

96000 samples/second * 24 bits/sample = 2,304,000 bits/second

and

2,304,000 bits/second/channel * 8 channels = 18,432,000 bits/second

So, those numbers would be 288 kbytes/second and 2304 kbytes/second,
respectively.

In which case, this is well within the bandwidth that 100BaseT can handle.
The only question is whether the actual hardware and software involved is
able to sustain an average of 2.3 megabytes/second. Most fast PCs these
days should be able to do that. Of course, it really depends on the
software involved and also whether the network cards are cheap pieces
of junk or something reasonable.

- Logan

Logan Shaw wrote in
:

In which case, this is well within the bandwidth that 100BaseT can
handle. The only question is whether the actual hardware and software
involved is able to sustain an average of 2.3 megabytes/second. Most
fast PCs these days should be able to do that.

Yes definately, most modern harddrives made within the last 2 years can
sustain between 30MB/s - 60MB/s depending on the location of the data.


Of course, it really
depends on the software involved and also whether the network cards
are cheap pieces of junk or something reasonable.

Even an el cheapo network card should be able to do 70 - 80mbit/s no
problem : )

--
Lucas Tam )
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/

"Arny Krueger" wrote in message
...
"Robert Morein" wrote in message

I want to set up a network music server with one client, a single
machine in my listening room.

Since actual throughput on a 100 mb network depends to a great extent
on factors other than the actual physical layer, I'd appreciate any
rules of thumb determined by experience. A single channel is about
2.3 mb/second, 8 channels = 18.4 mb/second.

I want to feed an 8-channel D/A, at 96/24 resolution, directly from
Adobe Audition, but the files will be on the server. Both machines
will run Windows 2000, with Ethernet adaptors on standard 32 bit PCI
buses.

Is this actually practical with desktop machines you've used?

What you're doing relates to me recording and mixing 12 32/44 channels
which
I do reliably all the time, except you're talking about doubling the load.
The simple answer is bag the 96 KHz sampling, but I know your audio
politics.

100BTX is not the most efficient user of media around. Bursts of 20 MB/Sec
are doable, but for this application we need to look at the whole system.
If
you have a disk subsystem that is capable of a sustained 20 MB/sec
locally,
its not going to be 20 MB/Sec across a 100BTX network.

Based on my experience, getting a reliable, sustained 20 MB/sec off a
commodity 7200 rpm hard drive *without* a network layer in place can be
iffy
unless the environment is pretty well controlled and the disks have pretty
high performance. For example, I would at minimum recommend a l hard
drive
subsystem composed something like a well-defragged 2-way stripe set made
up
of 7200 rpm 160 GB ATA drives. You don't need the striping for speed when
the array is nearly empty, but you probably will need striping when it is
nearly full. Striping gets you consistancy, not raw speed.

Arny, thanks for your constructive answer.
As some of the other posters have commented, there may be a confusion
between bits and bytes.
Here are some measurements I've made using a DVD burning program, a similar,
but not identical problem:
Via P4X266 chipset with 2.6g P4: 5.2 megabytes/second streaming to a DVD
burner = 40 megabits/second
Via 266 Socket 370 chipset with Via C3 Nehemiah : exactly the same.
Tyan S2460 dual MP chipset: 14.4 megabytes/second = 115 megabits/second

In each case, a single 7200 rpm disk is the source. Raw speed for this type
of device is approximately 500 megabits/second.
This leads me to think that striping is not required.
The question is, how much will the network interface slow it down?

On 12/2/2004 6:39 PM, Robert Morein wrote:

"Arny Krueger" wrote in message
...

"Robert Morein" wrote in message


I want to set up a network music server with one client, a single
machine in my listening room.

Since actual throughput on a 100 mb network depends to a great extent
on factors other than the actual physical layer, I'd appreciate any
rules of thumb determined by experience. A single channel is about
2.3 mb/second, 8 channels = 18.4 mb/second.

I want to feed an 8-channel D/A, at 96/24 resolution, directly from
Adobe Audition, but the files will be on the server. Both machines
will run Windows 2000, with Ethernet adaptors on standard 32 bit PCI
buses.

Is this actually practical with desktop machines you've used?

What you're doing relates to me recording and mixing 12 32/44 channels

which

I do reliably all the time, except you're talking about doubling the load.
The simple answer is bag the 96 KHz sampling, but I know your audio
politics.

100BTX is not the most efficient user of media around. Bursts of 20 MB/Sec
are doable, but for this application we need to look at the whole system.

If

you have a disk subsystem that is capable of a sustained 20 MB/sec

locally,

its not going to be 20 MB/Sec across a 100BTX network.

Based on my experience, getting a reliable, sustained 20 MB/sec off a
commodity 7200 rpm hard drive *without* a network layer in place can be

iffy

unless the environment is pretty well controlled and the disks have pretty
high performance. For example, I would at minimum recommend a l hard

drive

subsystem composed something like a well-defragged 2-way stripe set made

up

of 7200 rpm 160 GB ATA drives. You don't need the striping for speed when
the array is nearly empty, but you probably will need striping when it is
nearly full. Striping gets you consistancy, not raw speed.


Arny, thanks for your constructive answer.
As some of the other posters have commented, there may be a confusion
between bits and bytes.
Here are some measurements I've made using a DVD burning program, a similar,
but not identical problem:
Via P4X266 chipset with 2.6g P4: 5.2 megabytes/second streaming to a DVD
burner = 40 megabits/second
Via 266 Socket 370 chipset with Via C3 Nehemiah : exactly the same.
Tyan S2460 dual MP chipset: 14.4 megabytes/second = 115 megabits/second

In each case, a single 7200 rpm disk is the source. Raw speed for this type
of device is approximately 500 megabits/second.
This leads me to think that striping is not required.
The question is, how much will the network interface slow it down?




Make sure the network is switched, not hub. Get RAID 1 of 2 SATA drives
or Ultra 320 SCSI and 1 GB of DDR RAM and Windows XP in the music
server. Make sure FULL DUPLEX is enabled for all computers on LAN.

"Robert Morein" wrote in
:

In each case, a single 7200 rpm disk is the source. Raw speed for this
type of device is approximately 500 megabits/second.
This leads me to think that striping is not required.
The question is, how much will the network interface slow it down?


The disk is much faster than the network interface, so the interface will
run at full speed - which is usually ~60 - 80% of capacity, depend on the
number of machines on the network.

--
Lucas Tam )
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/

"Lucas Tam" wrote in message
.. .
"Robert Morein" wrote in
:

In each case, a single 7200 rpm disk is the source. Raw speed for this
type of device is approximately 500 megabits/second.
This leads me to think that striping is not required.
The question is, how much will the network interface slow it down?


The disk is much faster than the network interface, so the interface will
run at full speed - which is usually ~60 - 80% of capacity, depend on the
number of machines on the network.

Full speed, but there must be some overhead in handling the packets.
I understand some network cards are faster than others, depending upon how
much work the driver gives the CPU.
Afew network cards do all the low level processing on the card.
???

"Robert Morein" wrote in
:

The disk is much faster than the network interface, so the interface
will run at full speed - which is usually ~60 - 80% of capacity,
depend on the number of machines on the network.

Full speed, but there must be some overhead in handling the packets.

Yes there are bottlenecks on several levels, MAC level, TCP, and software.
Hence that is why the interface will probably run at 60 - 80% of the
maximum theoretical speed. You'll never hit 100mbit on ethernet.


I understand some network cards are faster than others, depending upon
how much work the driver gives the CPU.
Afew network cards do all the low level processing on the card.
???

Yes some cards do - mostly server grade network cards. But considering how
fast modern computers are... any computer built within the last 3 - 5 years
will saturate a 100mbit connection.

--
Lucas Tam )
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/

I have experienced about 40 megabits per second on a 100 megabit ethernet, 2
computers on the network.

Bob

"Robert Morein" wrote in message
...
I want to set up a network music server with one client, a single machine
in
my listening room.

Since actual throughput on a 100 mb network depends to a great extent on
factors other than the actual physical layer, I'd appreciate any rules of
thumb determined by experience. A single channel is about 2.3 mb/second,
8
channels = 18.4 mb/second.

I want to feed an 8-channel D/A, at 96/24 resolution, directly from Adobe
Audition, but the files will be on the server. Both machines will run
Windows 2000, with Ethernet adaptors on standard 32 bit PCI buses.

Is this actually practical with desktop machines you've used?

In article ,
"Robert Morein" wrote:

I want to set up a network music server with one client, a single machine in
my listening room.

Since actual throughput on a 100 mb network depends to a great extent on
factors other than the actual physical layer, I'd appreciate any rules of
thumb determined by experience. A single channel is about 2.3 mb/second, 8
channels = 18.4 mb/second.

I want to feed an 8-channel D/A, at 96/24 resolution, directly from Adobe
Audition, but the files will be on the server. Both machines will run
Windows 2000, with Ethernet adaptors on standard 32 bit PCI buses.

Is this actually practical with desktop machines you've used?

You might be better off with Gigabit with jumbo frames. Jumbo frames
enlarge the data capacity of a packet from 1500 bytes to 9000 bytes. It
cuts down on the CPU overhead needed to manage each packet. The
downside is that jumbo frames aren't quite mainstream yet. It's hard to
find hardware that handles it properly at a reasonable cost.

"Robert Morein" wrote in message

I want to set up a network music server with one client, a single
machine in my listening room.

Since actual throughput on a 100 mb network depends to a great extent
on factors other than the actual physical layer, I'd appreciate any
rules of thumb determined by experience. A single channel is about
2.3 mb/second, 8 channels = 18.4 mb/second.

Since PC data rates are usually given in bytes per second, I missed the fact
that these numbers use the lower case b, and are bits per second.

Using standard units, a 24/96 channel moves 96,000 3 byte words per second
or 288,000 bytes per second.

8 24/96 audio channels is a modest 2,304,000 bytes per second or 2.3
megabytes per second.

2.3 megabytes per second is a modest load, compared to the real-world
sustaned data rates possible with modern 7200 rpm drives in the 100-200
gigabyte range on modern 2 GHz plus CPU-type machines.. It's something like
a tenth of their typical data transfer capacity if they aren't badly
fragmented.

2.3 megabytes per second is even well within the capacity of a legacy file
server, such as a P2-233 running windows NT 4 with 256 megs of RAM and old 6
gigabyte 5400 rpm hard drives on a 100BTX network. That sort of a system
can be expected to deliver data at a sustained rate of about 6 megabytes per
second.

I want to feed an 8-channel D/A, at 96/24 resolution, directly from
Adobe Audition, but the files will be on the server. Both machines
will run Windows 2000, with Ethernet adaptors on standard 32 bit PCI
buses.

Is this actually practical with desktop machines you've used?

With modern equipment, it is a cakewalk. Been there done that routinely. As
others have pointed out, the most serious bottleneck in a modern system is
the 12.5 megabyte per second absolute maximum theoretical data rate of the
core of a 100BTX network. In the real world only about 80 or 90 percent of
that is available.

Last time I moved bulk data over a 100BTX network data sustained data rates
were on the order of 8 megs per second as observed with a stopwatch. That
was a disk-disk transfer over a network with about a half dozen machines on
it.

Arny Krueger wrote:
"Robert Morein" wrote in message


I want to set up a network music server with one client, a single
machine in my listening room.

Since actual throughput on a 100 mb network depends to a great extent
on factors other than the actual physical layer, I'd appreciate any
rules of thumb determined by experience. A single channel is about
2.3 mb/second, 8 channels = 18.4 mb/second.

Since PC data rates are usually given in bytes per second, I missed the fact
that these numbers use the lower case b, and are bits per second.

Using standard units, a 24/96 channel moves 96,000 3 byte words per second
or 288,000 bytes per second.

It's not 3 byte but 4 byte. No CPU handles 24bit, but 32bit.
The sampled 24bit are either left-aligned or right-aligned 32bit integers.

Concerning the network speed: The error correction might take another
10% of speed. I would guess a 50% of 5-6 MB/s is realistic in case
of 100 mb network.

Kind Regards
Nudge

--
Nudge // PCS Records Studio Leipzig
http://studio.lieber-media.de

Your actual throughput would probably be around 5 megabytes per second.

Bob

"Lucas Tam" wrote in message
.. .
"Robert Morein" wrote in
:

Since actual throughput on a 100 mb network depends to a great extent
on factors other than the actual physical layer, I'd appreciate any
rules of thumb determined by experience. A single channel is about
2.3 mb/second, 8 channels = 18.4 mb/second.

Are these MegaBytes per second or Megabits? Because a 100 base T network
runs at a theoretical 100megabits or ~12.8MB/s. In reality you're
looking at 80mbits top or 10MB/s.

I want to feed an 8-channel D/A, at 96/24 resolution, directly from
Adobe Audition, but the files will be on the server. Both machines
will run Windows 2000, with Ethernet adaptors on standard 32 bit PCI
buses.

Is this actually practical with desktop machines you've used?

You may want to upgrade to Gigabit ethernet.

Someone else mentioned hard drive speed - modern hard drives can easily
sustain 30MB/s if the drive is not fragmented heavily. To ensure
reliability you might want to put a dedicated recording disk on the
server. Drives are cheap - you can pick up a very good 80GB disk for ~
60.00USD. The striped RAID idea is good too, if you have enough drive
bays. But just be aware... on a striped array, if one of the 2 disks
crash, you lose ALL the data on both drives.

--
Lucas Tam )
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/

"Robert Morein" wrote in message

"Arny Krueger" wrote in message

In each case, a single 7200 rpm disk is the source. Raw speed for
this type of device is approximately 500 megabits/second.
This leads me to think that striping is not required.

Striping is for reliability, not maximum speed. Disks have vastly different
speeds as they fill up. Striping addresses that.

The question is, how much will the network interface slow it down?

I don't think I've ever seen file copies at more than 8 megabytes per second
on a 100BTX network. Theoretical max is more like 12 megabytes per second.
Of course, other network activity will also impact it.

In article , "Arny Krueger"
wrote:

In each case, a single 7200 rpm disk is the source. Raw speed for
this type of device is approximately 500 megabits/second.
This leads me to think that striping is not required.

Striping is for reliability, not maximum speed. Disks have vastly
different
speeds as they fill up. Striping addresses that.


You mean of course, that RAID striping "1" is for reliability and RAID
striping "0" is for speed, to clarify. In addition, there are variations
of these two basic types.

jackfish wrote:
In article , "Arny Krueger"
wrote:

In each case, a single 7200 rpm disk is the source. Raw speed for
this type of device is approximately 500 megabits/second.
This leads me to think that striping is not required.

Striping is for reliability, not maximum speed. Disks have vastly
different
speeds as they fill up. Striping addresses that.

You mean of course, that RAID striping "1" is for reliability and RAID
striping "0" is for speed, to clarify. In addition, there are variations
of these two basic types.

As long as we're clarifying, the "R" in RAID means "redundant".
Since striping by itself is not redundant, it is strictly speaking
not a form of RAID.

That's why people often calling it RAID 0. The official levels of
RAID start with RAID 1, so calling it RAID 0 indicates that it's
not really a part of the club.

Actually, a lot of this stuff is very complex. For large data
transfers (such as is done in audio, *if* your drive is not
too fragmented) striping helps. But for lots of small random
access transfers, mirroring (RAID 1) can actually be faster,
but only for reading and not for writing.

RAID 5 is an attractive option because it can (if properly
implemented) do fast sequential reads and writes[1] and it
provides increased reliability in that TWO drives have to
fail for you to actually lose any data, and the odds of two
drives failing are generally much lower than double the
odds of one failing. (But if they do fail, then you've still
lost all your data, just like with striping.)

- Logan

[1] If you issue a write for an entire stripe width, there
is no need to read any data from anywhere to recompute
new parity data; you can just compute fresh parity data
for the whole stripe and overwrite the other data.

"jackfish" wrote in message

In article , "Arny Krueger"
wrote:

In each case, a single 7200 rpm disk is the source. Raw speed for
this type of device is approximately 500 megabits/second.
This leads me to think that striping is not required.

Striping is for reliability, not maximum speed. Disks have vastly
different
speeds as they fill up. Striping addresses that.


You mean of course, that RAID striping "1" is for reliability and RAID
striping "0" is for speed, to clarify. In addition, there are
variations of these two basic types.

Actually, I mean that conventionally, disks striped for speed are striped
complementarily. IOW one disc is striped from the outside in, and the other
is striped from the inside out. This effectively takes the average DTR of
the inner and out tracks and multiplies it by two. Thus, the pair of discs
striped in this fashion has more reliable performance characteristics, its
speed does not drop nearly as preciptously when it fills up, as does a
single disk. Ironically, the outer tracks of a single disk may be faster
than the pair of discs striped this way.

Arny Krueger wrote:
Actually, I mean that conventionally, disks striped for speed are striped
complementarily. IOW one disc is striped from the outside in, and the other
is striped from the inside out. This effectively takes the average DTR of
the inner and out tracks and multiplies it by two.

Yes, when you take the sum of two things and divide it by two and then
multiply it again, you get the sum again. :-) :-)

Thus, the pair of discs
striped in this fashion has more reliable performance characteristics,

I think I might call it consistent rather than reliable. But I do
see the point.

By the way, I have never seen a system that actually does striping
the way you describe, even though it is a useful idea.

One other concept is to just leave the first 1/3 or so of the capacity
of both drives empty. If the filesystem doesn't even include those
parts of the disks, there's little chance of them being used when
the disk fills up. If you want, use the first 1/3 of both disks
for scratch space or archives or backups or something (as long as
it's not something you need to access during the time you expect
to get good performance out of the stripe set).

- Logan

"Arny Krueger" wrote in
:

"jackfish" wrote in message

In article , "Arny Krueger"
wrote:

In each case, a single 7200 rpm disk is the source. Raw speed for
this type of device is approximately 500 megabits/second.
This leads me to think that striping is not required.

Striping is for reliability, not maximum speed. Disks have vastly
different
speeds as they fill up. Striping addresses that.


You mean of course, that RAID striping "1" is for reliability and RAID
striping "0" is for speed, to clarify. In addition, there are
variations of these two basic types.

Actually, I mean that conventionally, disks striped for speed are
striped complementarily. IOW one disc is striped from the outside in,
and the other is striped from the inside out. This effectively takes the
average DTR of the inner and out tracks and multiplies it by two. Thus,
the pair of discs striped in this fashion has more reliable performance
characteristics, its speed does not drop nearly as preciptously when it
fills up, as does a single disk. Ironically, the outer tracks of a
single disk may be faster than the pair of discs striped this way.



For reliability and speed the best raid option available is RAID 1+0
sometime called RAID 10. Not all vendors have that available so the next
best is RAID5 which means that you can lose one disc and your data is
safe. WIth raid 10 you can lose multiple disks and your data will be
safe.

r

--
Nothing beats the bandwidth of a station wagon filled with DLT tapes.

"Logan Shaw" wrote in message

Arny Krueger wrote:
Actually, I mean that conventionally, disks striped for speed are
striped complementarily. IOW one disc is striped from the outside
in, and the other is striped from the inside out. This effectively
takes the average DTR of the inner and out tracks and multiplies it
by two.

Yes, when you take the sum of two things and divide it by two and then
multiply it again, you get the sum again. :-) :-)

Thus, the pair of discs
striped in this fashion has more reliable performance
characteristics,

I think I might call it consistent rather than reliable. But I do
see the point.

I agree that consistent might be a better choice of words.

By the way, I have never seen a system that actually does striping
the way you describe, even though it is a useful idea.

Interesting. I've never seen one that doesn't do it this way. Vendors don't
seem to talk much about this, but it explains why striping a pair of disks
can yield a stripe set that runs slower than either disck, when the disks
are mostly empty.

One other concept is to just leave the first 1/3 or so of the capacity
of both drives empty. If the filesystem doesn't even include those
parts of the disks, there's little chance of them being used when
the disk fills up. If you want, use the first 1/3 of both disks
for scratch space or archives or backups or something (as long as
it's not something you need to access during the time you expect
to get good performance out of the stripe set).

My view of this is that it might make sense to partition a disk into
multiple regions that inherently vary in terms of perforamnce. Then assign
data to the appropriate region based on its performance needs.

Logan Shaw wrote in
:

Arny Krueger wrote:
Actually, I mean that conventionally, disks striped for speed are
striped complementarily. IOW one disc is striped from the outside in,
and the other is striped from the inside out. This effectively takes
the average DTR of the inner and out tracks and multiplies it by two.

Yes, when you take the sum of two things and divide it by two and then
multiply it again, you get the sum again. :-) :-)

Thus, the pair of discs
striped in this fashion has more reliable performance characteristics,

I think I might call it consistent rather than reliable. But I do
see the point.

By the way, I have never seen a system that actually does striping
the way you describe, even though it is a useful idea.

One other concept is to just leave the first 1/3 or so of the capacity
of both drives empty. If the filesystem doesn't even include those
parts of the disks, there's little chance of them being used when
the disk fills up. If you want, use the first 1/3 of both disks
for scratch space or archives or backups or something (as long as
it's not something you need to access during the time you expect
to get good performance out of the stripe set).

- Logan


I don't know where Arny got the idea that disks are striped as described,
but that isn't how it is done in the real world. On a write it would not
matter one bit if one disc was writing from the outside in or inside out.
The point of striping is to improve speed and improve speed it does
dramatically. I have seen large arrays write a gigabyte of data per
second and there was none of that business of one disk starting at block 0
and the other starting at EOF.


r

Arny Krueger wrote:

"Logan Shaw" wrote in message


By the way, I have never seen a system that actually does striping
the way you describe, even though it is a useful idea.

Interesting. I've never seen one that doesn't do it this way. Vendors don't
seem to talk much about this, but it explains why striping a pair of disks
can yield a stripe set that runs slower than either disck, when the disks
are mostly empty.

There are a couple of miscellaneous reasons that a striped set can
run slower than an individual disk.

The first reason is that both disk heads may have to seek to satisfy
an I/O. Let's say you want to read a small amount of data, and it
stretches across the boundary from one stripe to the next. If you
had just one drive, it would seek to the beginning of your data
and 99% chance it would read it all in one continuous transfer.
But with striped disks, both disks' heads are in the wrong position
(probably), and both have to move to the right position and read
before you get back the data you want. In most cases, they aren't
in the same position to start with, so you have to wait longer for
one than the other. Another way of looking at this is that if you
do an I/O that is larger than the stripe width (or overlaps a
stripe boundary), then you are getting several disks involved and
you have to wait around for *all* of them to finish before you can
proceed.

The second reason is sort of similar to the first, but different.
When you want to get some data off a disk, you have to wait for
the head to get where it needs to be (near the center or out on
the edge), but you also have to wait for the platter to spin
around until your data passes under the head. Most striped
disk sets do not have the spindles synchronized[1], so if the
host tells both drives to move to the same track and they both
arrive at the same time, you still must wait for both of them
to get the data, which won't happen until the appropriate
region on each one has passed by the head. In practice, I think
the spindle thing is a relatively small problem.

Actually, both of them are probably relatively small, but the
point is that striping gains you something when you are doing
big bulk transfers, but it's not totally without cost.

- Logan

[1] It's been a while, but I believe server-class SCSI drives
used to have a connector you could use to synchronize
the spindles of several drives.

"Logan Shaw" wrote in message

Arny Krueger wrote:

"Logan Shaw" wrote in message


By the way, I have never seen a system that actually does striping
the way you describe, even though it is a useful idea.

Interesting. I've never seen one that doesn't do it this way.
Vendors don't seem to talk much about this, but it explains why
striping a pair of disks can yield a stripe set that runs slower
than either disck, when the disks are mostly empty.

There are a couple of miscellaneous reasons that a striped set can
run slower than an individual disk.

The first reason is that both disk heads may have to seek to satisfy
an I/O. Let's say you want to read a small amount of data, and it
stretches across the boundary from one stripe to the next. If you
had just one drive, it would seek to the beginning of your data
and 99% chance it would read it all in one continuous transfer.

I'm including sequential reads on a defregged disks.

But with striped disks, both disks' heads are in the wrong position
(probably), and both have to move to the right position and read
before you get back the data you want.

Aagin, not a prolblem with sequential reads on a defragged disc.

"Rich.Andrews" wrote in message


I don't know where Arny got the idea that disks are striped as
described, but that isn't how it is done in the real world.

Sez you.

On a
write it would not matter one bit if one disc was writing from the
outside in or inside out.

Not true. Writes on the inside tracks are far slower than writes on the
outside track. I can't imagine how anybody can call this mattering not one
bit!

The point of striping is to improve speed
and improve speed it does dramatically.

Of course. However, the speed of a disk also varies dramatically as it fills
up and data is written closer and closer to the inside of the disk.

I have seen large arrays write a gigabyte of data per second and there
was none of that
business of one disk starting at block 0 and the other starting at

All fine and good, but in the context of a discussion of how striping can
even out the performance of a disk, its a red herring.

"Arny Krueger" wrote in
:

"Rich.Andrews" wrote in message


I don't know where Arny got the idea that disks are striped as
described, but that isn't how it is done in the real world.

Sez you.

On a
write it would not matter one bit if one disc was writing from the
outside in or inside out.

Not true. Writes on the inside tracks are far slower than writes on the
outside track. I can't imagine how anybody can call this mattering not
one bit!

The point of striping is to improve speed
and improve speed it does dramatically.

Of course. However, the speed of a disk also varies dramatically as it
fills up and data is written closer and closer to the inside of the
disk.

I have seen large arrays write a gigabyte of data per second and
there
was none of that business of one disk starting at block 0 and the other
starting at

All fine and good, but in the context of a discussion of how striping
can even out the performance of a disk, its a red herring.




Arny,

There is something called interleaving that is done to take care of any
potential geometry related speed issues. I worked for AT&T Computer
Systems in the SCSI lab for a while. I know how many raid controller work
including hardware and software raid solutions and none of them that we
worked with ever did that "complementary striping" you mention. Even
current software raid solutions like Veritas and Sun do not do that. That
also includes hardware solutions like EMC, DPT, Adaptec, and a few others.

We never had any issues with data transfer rates no matter if it was at
the beginning or the end of the discs. When I mean issues, I mean the
speed did not change end to end. The limiting factor is all cases was the
speed of the SCSI bus, not the disks and that includes fiber attached
controllers. Now if you can find a disc that does not change its
interleaving from end to end, I suggest you throw that POS away and buy
something else.

Might I suggest you do some additional research with a review of some
pertinent source code. Review some hard drive conroller software if you
can find it. The interleaving maps are there.

Sorry Arny, in this case you are clearly wrong.

r


-- Nothing beats the bandwidth of a station wagon filled with DLT tapes.