Sign in with
Sign up | Sign in
Your question

100 base T network capacity

Last response: in Home Audio
Share
Anonymous
December 2, 2004 8:48:50 AM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

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?
Anonymous
December 2, 2004 11:56:36 AM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

"Robert Morein" <nowhere@nowhere.com> wrote in message news:<3IGdncsdxOyObjPcRVn-oA@comcast.com>...
> 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.
Anonymous
December 2, 2004 1:07:35 PM

Archived from groups: rec.audio.pro (More info?)

"Robert Morein" <nowhere@nowhere.com> wrote in message news:<3IGdncsdxOyObjPcRVn-oA@comcast.com>...
> 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 are the cpu clock speeds of the clients on your network? Who
makes the NIC cards (they may support larger than standard MTU sizes)?
What size files will you be moving across the net? Are you using a
switch, a hub, or a 100BaseT crossover cable to link the devices?

A two node network should be fine with a 100 meg pipe. If I
understand your question, you want music files to live on a server,
and load them up on a client when you want to review them. Your
network speed will only determine how long it takes to get from the
server to the client.

100 meg ethernet is pretty robust and should be fine here.

~Joe (more of a network guy than a studio guy!)
Related resources
Anonymous
December 2, 2004 3:17:52 PM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

"Robert Morein" <nowhere@nowhere.com> wrote in message
news:3IGdncsdxOyObjPcRVn-oA@comcast.com
> 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.
Anonymous
December 2, 2004 10:03:49 PM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

"Robert Morein" <nowhere@nowhere.com> wrote in
news:3IGdncsdxOyObjPcRVn-oA@comcast.com:

> 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 (REMOVEnntp@rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/
Anonymous
December 2, 2004 10:14:02 PM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

Lucas Tam wrote:

> "Robert Morein" <nowhere@nowhere.com> wrote in
> news:3IGdncsdxOyObjPcRVn-oA@comcast.com:
>
>
>>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
Anonymous
December 2, 2004 10:39:47 PM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

"Arny Krueger" <arnyk@hotpop.com> wrote in message
news:QsednR6EkNet0zLcRVn-iw@comcast.com...
> "Robert Morein" <nowhere@nowhere.com> wrote in message
> news:3IGdncsdxOyObjPcRVn-oA@comcast.com
> > 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?
Anonymous
December 2, 2004 11:01:55 PM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

Logan Shaw <lshaw-usenet@austin.rr.com> wrote in
news:_PJrd.65957$g21.1749@fe1.texas.rr.com:

> 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 (REMOVEnntp@rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/
Anonymous
December 3, 2004 1:36:46 AM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

In article <3IGdncsdxOyObjPcRVn-oA@comcast.com>,
"Robert Morein" <nowhere@nowhere.com> 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.
Anonymous
December 3, 2004 4:04:07 AM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

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

> "Arny Krueger" <arnyk@hotpop.com> wrote in message
> news:QsednR6EkNet0zLcRVn-iw@comcast.com...
>
>>"Robert Morein" <nowhere@nowhere.com> wrote in message
>>news:3IGdncsdxOyObjPcRVn-oA@comcast.com
>>
>>>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.
Anonymous
December 3, 2004 4:19:14 AM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

"Robert Morein" <nowhere@nowhere.com> wrote in
news:0NednfTecslOKDLcRVn-rQ@comcast.com:

> 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 (REMOVEnntp@rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/
Anonymous
December 3, 2004 4:19:15 AM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

"Lucas Tam" <REMOVEnntp@rogers.com> wrote in message
news:Xns95B3CF04E4119nntprogerscom@140.99.99.130...
> "Robert Morein" <nowhere@nowhere.com> wrote in
> news:0NednfTecslOKDLcRVn-rQ@comcast.com:
>
> > 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.
???
Anonymous
December 3, 2004 4:56:39 AM

Archived from groups: rec.audio.pro (More info?)

On Thu, 2 Dec 2004 05:48:50 -0500, "Robert Morein"
<nowhere@nowhere.com> wrote:

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

Hard drives are cheap. How about updating local drives periodically?

Chris Hornbeck
" ** .......... :-0 !!!! "
Anonymous
December 3, 2004 5:45:10 AM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

"Robert Morein" <nowhere@nowhere.com> wrote in
news:h4idndYAktVKXjLcRVn-tg@comcast.com:

>> 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 (REMOVEnntp@rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/
Anonymous
December 3, 2004 7:13:26 AM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

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

Bob

"Robert Morein" <nowhere@nowhere.com> wrote in message
news:3IGdncsdxOyObjPcRVn-oA@comcast.com...
> 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?
>
>
Anonymous
December 3, 2004 11:01:53 AM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

"Robert Morein" <nowhere@nowhere.com> wrote in message
news:3IGdncsdxOyObjPcRVn-oA@comcast.com
> 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.
Anonymous
December 4, 2004 9:32:39 PM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

Arny Krueger wrote:
> "Robert Morein" <nowhere@nowhere.com> wrote in message
> news:3IGdncsdxOyObjPcRVn-oA@comcast.com
>
>>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
Anonymous
January 25, 2005 11:06:52 PM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

"Robert Morein" <nowhere@nowhere.com> wrote in message
news:0NednfTecslOKDLcRVn-rQ@comcast.com
> "Arny Krueger" <arnyk@hotpop.com> 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.
Anonymous
January 25, 2005 11:06:53 PM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

In article <E4OdnfrYkJeycGvcRVn-ug@comcast.com>, "Arny Krueger"
<arnyk@hotpop.com> 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.
Anonymous
January 26, 2005 12:50:56 AM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

"jackfish" <jackfish@north.org> wrote in message
news:jackfish-7017E5.19445425012005@news.mts.net
> In article <E4OdnfrYkJeycGvcRVn-ug@comcast.com>, "Arny Krueger"
> <arnyk@hotpop.com> 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.
Anonymous
January 26, 2005 3:55:49 AM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

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

Bob

"Lucas Tam" <REMOVEnntp@rogers.com> wrote in message
news:Xns95B38F10C397Fnntprogerscom@140.99.99.130...
> "Robert Morein" <nowhere@nowhere.com> wrote in
> news:3IGdncsdxOyObjPcRVn-oA@comcast.com:
>
> > 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 (REMOVEnntp@rogers.com)
> Please delete "REMOVE" from the e-mail address when replying.
> http://members.ebay.com/aboutme/coolspot18/
Anonymous
January 26, 2005 5:07:23 AM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

jackfish wrote:
> In article <E4OdnfrYkJeycGvcRVn-ug@comcast.com>, "Arny Krueger"
> <arnyk@hotpop.com> 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.
Anonymous
January 26, 2005 7:34:12 AM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

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
Anonymous
January 26, 2005 1:27:31 PM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

"Logan Shaw" <lshaw-usenet@austin.rr.com> wrote in message
news:85FJd.58637$_56.54566@fe2.texas.rr.com
> 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.
Anonymous
January 26, 2005 2:48:58 PM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

"Arny Krueger" <arnyk@hotpop.com> wrote in
news:nsadncO4S5sOmGrcRVn-uA@comcast.com:

> "jackfish" <jackfish@north.org> wrote in message
> news:jackfish-7017E5.19445425012005@news.mts.net
>> In article <E4OdnfrYkJeycGvcRVn-ug@comcast.com>, "Arny Krueger"
>> <arnyk@hotpop.com> 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.
Anonymous
January 27, 2005 5:04:31 AM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

Logan Shaw <lshaw-usenet@austin.rr.com> wrote in
news:85FJd.58637$_56.54566@fe2.texas.rr.com:

> 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
Anonymous
January 27, 2005 1:50:35 PM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

Arny Krueger wrote:

> "Logan Shaw" <lshaw-usenet@austin.rr.com> wrote in message
> news:85FJd.58637$_56.54566@fe2.texas.rr.com

>>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.
Anonymous
January 27, 2005 2:10:49 PM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

"Logan Shaw" <lshaw-usenet@austin.rr.com> wrote in message
news:%H3Kd.87809$Z%.20045@fe1.texas.rr.com
> Arny Krueger wrote:
>
>> "Logan Shaw" <lshaw-usenet@austin.rr.com> wrote in message
>> news:85FJd.58637$_56.54566@fe2.texas.rr.com
>
>>> 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.
Anonymous
January 28, 2005 10:42:47 AM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

"Rich.Andrews" <spmaway@ylhoo.com> wrote in message
news:Xns95EACC37DB448bvzxrpl@10.232.1.1

> 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.
Anonymous
January 28, 2005 6:04:30 PM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

"Arny Krueger" <arnyk@hotpop.com> wrote in
news:TsednSSVMLWirmfcRVn-1Q@comcast.com:

> "Rich.Andrews" <spmaway@ylhoo.com> wrote in message
> news:Xns95EACC37DB448bvzxrpl@10.232.1.1
>
>> 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.
Anonymous
January 28, 2005 9:39:05 PM

Archived from groups: rec.audio.pro,rec.audio.tech (More info?)

On Fri, 28 Jan 2005 16:04:30 +0100, R wrote:

> There is something called interleaving that is done to take care of any
> potential geometry related speed issues.

Interleaving is changing the sequence of sectors on the surface of the
disk to reduce the througput so controler hardware can handle it, for a
track with 20 sectors this would look like: 1 11 2 12 3 13 4 14 5 15 6 16
7 17 8 18 9 19 10 20. I don't think this is used now hardware is
sufficiently fast and drives have caches of megabytes. Interleaving was
common in the 70's and 80's less common in the 90's and absent now.

> The limiting factor is all cases was the speed of the SCSI bus, not the
> disks and that includes fiber attached controllers.

Disks and busses both have been limmiting factors. One of the reasons to
implement RAID arrays was the increased throughput by the simultanous use
of disks. At the moment I think there is some balance. A PCI RAID
controler can supply sufficient bandwith for a not too big array, only a
few disks in an array can supply the bandwith of a 2Gbit FC. As the
development in disks and busses moves, this balance can shift both ways.

I don't think any of this matters any more for audio purposes. A 96/24
channel neeads about 300kbyte/sec. It is not even a problem for a single
IDE drive to support many schannels at this speed.

> 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.

???

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

End to end bandwith?

--
Chel van Gennip
Visit Serg van Gennip's site http://www.serg.vangennip.com
!