Hi,
Gus--thank you.
You are right. I mainly have to run programs on a small cluster (GiGE)
dedicated for my job only; and sometimes I might get some opportunity to run
my code on a shared cluster with hundreds of nodes.
My parallel CFD application involves (In its simplest form):
1) reading of inp
Hi Bogdan, list
Oh, well, this is definitely a peer reviewed list.
My answers were given in the context of Amjad's original
questions, and the perception, based on Amjad's previous
and current postings, that he is not dealing with a large cluster,
or with many users, and plans to both paralleliz
Dear Colleague:
This is to inform you that the International Workshop on High
Performance Interconnects for Distributed Computing (HPIDC) has extended
the paper submission deadline to July 10th, 2009.
A full CFP can be found below.
Regards,
-- Ada & Pavan
-
On Wed, 24 Jun 2009, Gus Correa wrote:
the "master" processor reads... broadcasts parameters that are used
by all "slave" processors, and scatters any data that will be
processed in a distributed fashion by each "slave" processor.
...
That always works, there is no file system contention.
I
Patrick Geoffray writes:
> So, if you set rx-frames to 1, there will be an interrupt after each
> packet.
Isn't that turning off coalescence, as you recommended?
> Not many devices implement rx-frames, since it does not
> distinguish between small and large frames. Adaptive coalescing methods
Dave Love wrote:
Gerry Creager writes:
I had rather nasty results with tg3 and abandoned it. We're using bnx2
now. The latest iteration seems (guardedly) better than the last one.
I thought that they were for different hardware (NetXtreme I
c.f. NetXtreme II, according to broadcom.com). I
Patrick Geoffray writes:
> Instead of rx-usecs being the time between interrupts, it is sometimes
> implemented as the delay between the the first packet and the following
> interrupt, which is obviously wrong.
Ah. Is that likely to be in the driver, where it might be fixed, or the
NIC firmwa
2009/6/29 Rahul Nabar :
> On Mon, Jun 29, 2009 at 3:15 PM, Mark Hahn wrote:
>
> Thanks for all the help Mark!
>
>
>> well, ping is not _really_ a benchmark ;)
>
> I thought so! :) Lazy person's first shot. Now I will try ethtool.
>
Rahul, its maybe worth making something explicitly clear.
When fol
