Just fwiw, as something of an outsider, I wasn't able to meaningfully parse
this exchange.
Peter
On 5/19/08, Jeffrey B. Layton <[EMAIL PROTECTED]> wrote:
>
> Perry E. Metzger wrote:
>
>> "Jeffrey B. Layton" <[EMAIL PROTECTED]> writes
>>
>>> In any case, let me note the most important rule: if your
"Jeffrey B. Layton" <[EMAIL PROTECTED]> writes:
> Evidently you don't know jack about real codes.
Evidently. But I do know how to be polite, so I'll bow out of this
conversation.
Perry
___
Beowulf mailing list, Beowulf@beowulf.org
To change your subscr
Perry E. Metzger wrote:
"Jeffrey B. Layton" <[EMAIL PROTECTED]> writes
In any case, let me note the most important rule: if your CPUs aren't
doing work most of the time, you're not allocating resources
properly. If the task is really I/O bound, there is no point in having
more CPU than I/O can p
"Jeffrey B. Layton" <[EMAIL PROTECTED]> writes:
>> Third, you could be doing lots of file i/o to legitimate data
>> files. Here again, it is possible that if the files are small enough
>> and your access patterns are repetitive enough that increasing your
>> RAM could be enough to make everything
Jeffrey B. Layton wrote:
Here comes the $64 question - how do you benchmark the IO portion of your
code so you can understand whether you need a parallel file system, what
kind
of connection do you need from a client to the storage, etc. This is a
difficult
problem and one in which I have an
Perry E. Metzger wrote:
"Jeffrey B. Layton" <[EMAIL PROTECTED]> writes:
Here comes the $64 question - how do you benchmark the IO portion of
your code so you can understand whether you need a parallel file
system, what kind of connection do you need from a client to the
storage, etc. This is
"Jeffrey B. Layton" <[EMAIL PROTECTED]> writes:
> Here comes the $64 question - how do you benchmark the IO portion of
> your code so you can understand whether you need a parallel file
> system, what kind of connection do you need from a client to the
> storage, etc. This is a difficult problem a
Joe Landman wrote:
Perry E. Metzger wrote:
checking. A very fast RAID array may be in order -- or it may be
completely unnecessary. One can't know without understanding one's
application intimately, and that requires testing.
Of course. But there are quite a few people/groups on this list wit
Vlad Manea wrote:
Hi Joe,
The codes are not commercial, they are developed together with
Mike Gurnis's group at Caltech (CIG). The codes are parallel and use
MPICH. I use a small 24 ports Gigabit switch
from Netgear for the moment (it is full-duplex and supports jumbo frames...).
I had a very t
Vlad Manea wrote:
Hi Joe,
Thanks. Probably I will go with ROCKS.
For the moment I have 5 machines with 4 AMDs on them
and I will use one as headnode and the other 4 as comp. nodes.
The cluster will be dedicated to run fluid dynamics codes.
Hi Vlad:
Are these locally developed codes or comme
Hi Vlad:
Vlad Manea wrote:
Hi guys,
I have a question regarding the head node for a small cluster that I
would like
to build:
which are the disadvantages of using the head node as a computation node?
Since I plan to have NFS on it, I guess there will be problems with
comunication
which prob
Perry E. Metzger wrote:
Joe Landman <[EMAIL PROTECTED]> writes:
[...]
We approach it from a different view. Start out with a very fast RAID
and attach good networking to it. Here is a RAID6 across 12 disks.
[...]
I have to emphasize, yet again, that the correct approach is not to
assume that
Joe Landman <[EMAIL PROTECTED]> writes:
>[...]
> We approach it from a different view. Start out with a very fast RAID
> and attach good networking to it. Here is a RAID6 across 12 disks.
>[...]
I have to emphasize, yet again, that the correct approach is not to
assume that you need a fast file
Vlad Manea wrote:
Thanks Perry,
I would probably go with a separate file server.
I have seen a lot of NAS on the market recently (i.e. Netgear ReadyNAS
NV+ 4Tb X-RAID)
and I am wandering if they might be a good/bad choice (the price is
appealing...).
You get what you pay for ... c.f.
http:
Thanks Perry,
I would probably go with a separate file server.
I have seen a lot of NAS on the market recently (i.e. Netgear ReadyNAS
NV+ 4Tb X-RAID)
and I am wandering if they might be a good/bad choice (the price is
appealing...).
On the other hand I do not want to see all may cluster idle wa
Vlad Manea <[EMAIL PROTECTED]> writes:
> On the other hand I do not want to see all may cluster idle waiting
> for the file server. The w/r rate transfer for these NAS is ~30-40
> MB/sec which probably is a modest one.
>
> Do you have any recommendations for the file server?
I would suggest, aga
which are the disadvantages of using the head node as a computation node?
just that other headnode activities will interfere with compute jobs
and vice versa. this may not matter, depending on your workload,
habits of users (compilation, etc). mainly you can just pick out
certain cases where
Vlad Manea <[EMAIL PROTECTED]> writes:
> I have a question regarding the head node for a small cluster that I
> would like to build:
>
> which are the disadvantages of using the head node as a computation
> node? Since I plan to have NFS on it, I guess there will be
> problems with comunication w
Hi guys,
I have a question regarding the head node for a small cluster that I
would like
to build:
which are the disadvantages of using the head node as a computation node?
Since I plan to have NFS on it, I guess there will be problems with
comunication
which probably will slow down the whole
19 matches
Mail list logo
