From: "William J. Earl" <wje@fir.engr.sgi.com>
To: <pjlahaie@atlsci.com>
Cc: Ariel Faigon <ariel@cthulhu.engr.sgi.com>,
Olivier Galibert <galibert@pobox.com>,
linux@cthulhu.engr.sgi.com
Subject: Re: help offered
Date: Wed, 25 Nov 1998 13:18:12 -0800 [thread overview]
Message-ID: <199811252118.NAA22913@fir.engr.sgi.com> (raw)
In-Reply-To: <Pine.LNX.4.04.9811251542540.3207-100000@elenuial.atlsci.com>
pjlahaie@atlsci.com writes:
> On Wed, 25 Nov 1998, Ariel Faigon wrote:
>
> > I've seen way much higher numbers. They are not official, and
> > are not supposed to be used in sales situations, but were obtained
> > in our labs with XFS and arrays that were designed and tuned to
> > maximize bandwidth and to prove that XFS is not the bottleneck.
> > I believe they also used fiberchannel etc. Anyway, there are
> > some much greater experts on this subject on this list if they
> > care to give the details.
>
> I was under the impression the O2k memory bandwidth was limited to
> ~800MB/s. If so, even if you can read 4GB/s what are you foing to do with
> it? It would have to go over the CrayLink "network" and that doesn't do
> 4GB/s. The only way I can see 4GB/s disk throughput is multiple of the
> node accessing "local" drives and adding all the bandwidth together.
A single node is only 800 MB/s, but an 8P Origin 2000 has four nodes,
and a 32P has 16 nodes. The router network bandwidth scales with the number
of nodes, so the memory bandwidth of a 32P Origin 2000 is far more than enough
for 4 GB/s. If you attach the drives to multiple controllers on multiple
nodes, then it is easy to stripe across them with the volume manager to
get high bandwidth. The volume manager does requests in parallel, so it
is not a bottleneck.
The Origin architecture does not have a central bus, so it is not bus
limited. Just add boxes until the bandwidth is enough for what you need.
WARNING: multiple messages have this Message-ID (diff)
From: "William J. Earl" <wje@fir.engr.sgi.com>
To: pjlahaie@atlsci.com
Cc: Ariel Faigon <ariel@cthulhu.engr.sgi.com>,
Olivier Galibert <galibert@pobox.com>,
linux@cthulhu.engr.sgi.com
Subject: Re: help offered
Date: Wed, 25 Nov 1998 13:18:12 -0800 [thread overview]
Message-ID: <199811252118.NAA22913@fir.engr.sgi.com> (raw)
Message-ID: <19981125211812.ZHE4yFwW24h18TMHe_C3MRwCVeWh6D9A_EmuqkSW65s@z> (raw)
In-Reply-To: <Pine.LNX.4.04.9811251542540.3207-100000@elenuial.atlsci.com>
pjlahaie@atlsci.com writes:
> On Wed, 25 Nov 1998, Ariel Faigon wrote:
>
> > I've seen way much higher numbers. They are not official, and
> > are not supposed to be used in sales situations, but were obtained
> > in our labs with XFS and arrays that were designed and tuned to
> > maximize bandwidth and to prove that XFS is not the bottleneck.
> > I believe they also used fiberchannel etc. Anyway, there are
> > some much greater experts on this subject on this list if they
> > care to give the details.
>
> I was under the impression the O2k memory bandwidth was limited to
> ~800MB/s. If so, even if you can read 4GB/s what are you foing to do with
> it? It would have to go over the CrayLink "network" and that doesn't do
> 4GB/s. The only way I can see 4GB/s disk throughput is multiple of the
> node accessing "local" drives and adding all the bandwidth together.
A single node is only 800 MB/s, but an 8P Origin 2000 has four nodes,
and a 32P has 16 nodes. The router network bandwidth scales with the number
of nodes, so the memory bandwidth of a 32P Origin 2000 is far more than enough
for 4 GB/s. If you attach the drives to multiple controllers on multiple
nodes, then it is easy to stripe across them with the volume manager to
get high bandwidth. The volume manager does requests in parallel, so it
is not a bottleneck.
The Origin architecture does not have a central bus, so it is not bus
limited. Just add boxes until the bandwidth is enough for what you need.
next prev parent reply other threads:[~1998-11-25 21:19 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-11-24 12:27 help offered Torbjörn Gannholm
1998-11-24 20:33 ` Ariel Faigon
1998-11-25 19:49 ` Olivier Galibert
1998-11-25 19:57 ` John E. Schimmel
1998-11-25 19:57 ` John E. Schimmel
1998-11-25 20:11 ` Jeffrey Watts
1998-11-25 20:43 ` Greg Chesson
1998-11-25 20:37 ` Ariel Faigon
1998-11-25 20:37 ` Ariel Faigon
1998-11-25 20:51 ` pjlahaie
1998-11-25 21:18 ` William J. Earl [this message]
1998-11-25 21:18 ` William J. Earl
1998-11-25 21:24 ` Greg Chesson
1998-11-25 21:24 ` Greg Chesson
1998-11-25 21:38 ` pjlahaie
1998-11-25 21:57 ` Greg Chesson
1998-11-25 21:57 ` Greg Chesson
1998-11-25 22:09 ` pjlahaie
1998-11-25 22:57 ` Greg Chesson
1998-11-25 22:57 ` Greg Chesson
1998-11-25 22:08 ` William J. Earl
1998-11-25 22:08 ` William J. Earl
1998-11-25 22:13 ` Alex Kozlov
1998-11-25 22:15 ` pjlahaie
1998-11-25 22:25 ` William J. Earl
1998-11-25 22:25 ` William J. Earl
1998-11-25 21:46 ` Alan Cox
1998-11-25 21:04 ` Greg Chesson
1998-11-25 21:04 ` Greg Chesson
1998-11-26 12:28 ` ralf
[not found] ` <19981126085407.A2201@uni-koblenz.de>
1998-11-27 22:59 ` Olivier Galibert
1998-11-28 2:45 ` ralf
1998-11-26 22:17 ` Miguel de Icaza
1998-11-25 20:56 ` Greg Chesson
1998-11-25 21:12 ` Olivier Galibert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199811252118.NAA22913@fir.engr.sgi.com \
--to=wje@fir.engr.sgi.com \
--cc=ariel@cthulhu.engr.sgi.com \
--cc=galibert@pobox.com \
--cc=linux@cthulhu.engr.sgi.com \
--cc=pjlahaie@atlsci.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.