At 17:55 24.04.2007, Ashley Pittman wrote:
That would explain why qlogic use PIO for up to 64k messages and we
switch to DMA at only a few hundred. For small messages you could best
describe what we use as a hybrid of the above descriptions, we write the
a network packet across the PCI bus and d
Bogdan Costescu wrote:
I don't quite follow you here: the link that was sent earlier had
shown some kernel level autoconfig problem. If this is indeed still
the case with newer kernels, this should only affect the root FS -
before mounting the other NFS exports, you should have the chance to
On Wed, 25 Apr 2007, Tim Cutts wrote:
With our queueing system that forces the job into a lower priority queue.
Just to be sure that we are talking about the same thing: this is a
value which is set by the user to the maximum allowed, not one
automatically used by the scheduler because none
Hi Håkon,
you wrote:
I just read
http://www.spec.org/workshops/2007/austin/slides/SPEC_MPI2007.pdf
I am lacking applications using MPI_Alltoall and MPI_Alltoallv - these
are important dimensions to evaluate. Anyone who knows about any
suitable benchmark candidates?
Thanks,
I am sorry for not making things more clear. scp was faster then NFS
only when NFS server was being hammered by the client nodes. This
happens only when number of client nodes increase above a certain
number. In my test I was reading files (1-2 MB) from an NFS server from
180 nodes. All the nod
On 25 Apr 2007, at 4:12 pm, Bogdan Costescu wrote:
... or would supply some meaningless values...
For example, if the queue is limited to 24h maximum runtime and
they would set 24h as their requirement, thinking that it would
certainly cover what they want and the job would not run anyway
Hi,
we're a redhat/fedora based install, thus use anaconda, and as such...
On Wed, 25 Apr 2007, Mark Hahn wrote:
mount -n -o nolock,rw,udp,nfsvers=3 $NFSROOT /sysroot
Are you using -o nolock when you're mounting? This caused problems for us,
a few years ago, iirc.
I tend to disable everyt
On Wed, 25 Apr 2007, Amrik Singh wrote:
I agree that Jumbo Frames would not be a great help with the root
file system but we hope to get a better performance from other NFS
servers.
I don't quite follow you here: the link that was sent earlier had
shown some kernel level autoconfig problem.
Uh oh...
Sorry, my mistake!
On Wed, 25 Apr 2007, Paul Armor wrote:
On Wed, 25 Apr 2007, Amrik Singh wrote:
DEFAULT bzImage
APPEND acpi=off debug earlyprintk=vga initcall_debug console=tty0
initrd=bzImage ramdisk=40960 root=/dev/nfs
nfsroot=192.168.1.254:/slave/root ro ip=dhcp
you should
mount -n -o nolock,rw,udp,nfsvers=3 $NFSROOT /sysroot
Are you using -o nolock when you're mounting? This caused problems for us, a
few years ago, iirc.
I tend to disable everything I don't know I need ;)
I guess I assumed that NFS locking would be necessary for things like
exclusive access
On Wed, 25 Apr 2007, Ashley Pittman wrote:
> I'm not sure I follow, surely using PIO over DMA is a lose-lose
> scenario? As you say conventional wisdom is offload should win in this
> situation...
>
> Mind you we do something completely different for larger messages which
> rules out the use of
Hi Amrik,
On Wed, 25 Apr 2007, Mark Hahn wrote:
mount -n -o nolock,rw,udp,nfsvers=3 $NFSROOT /sysroot
Are you using -o nolock when you're mounting? This caused problems for
us, a few years ago, iirc.
Cheers,
Paul
___
Beowulf mailing list, Beowul
On Wed, 2007-04-25 at 07:35 -0700, Christian Bell wrote:
> On Wed, 25 Apr 2007, Ashley Pittman wrote:
>
> > You'd have thought that to be the case but PIO bandwidth is not a patch
> > on DMA bandwidth. On alphas you used to get a performance improvement
> > by evicting the data from the cache imm
We are very sure that our current bottlenecks lie at the NFS level. The hard
well, what kind of speed are you seeing? is this only from specific
applications, or is the problem displayed with benchmarks as well?
do you have control over the kernels being used by client and server?
DEFAULT bzI
Hi,
On Wed, 25 Apr 2007, Amrik Singh wrote:
DEFAULT bzImage
APPEND acpi=off debug earlyprintk=vga initcall_debug console=tty0
initrd=bzImage ramdisk=40960 root=/dev/nfs nfsroot=192.168.1.254:/slave/root
ro ip=dhcp
you should just need to append
mtu=9000
Cheers,
Paul
__
On Wed, 25 Apr 2007, Tim Cutts wrote:
But if your users, like mine, can't or won't supply this information
... or would supply some meaningless values...
For example, if the queue is limited to 24h maximum runtime and they
would set 24h as their requirement, thinking that it would certainly
All of the very large sites that I've been at (SGE users for the most
part) who really need reservation and backfill capabilities had all
pretty much invested effort in writing local job submission wrappers
and front ends that programatically wrote the job scripts and handled
job submissi
Bogdan Costescu wrote:
On Tue, 24 Apr 2007, Mark Hahn wrote:
so the main question is whether jumbo is worth the effort.
I would rephrase it to say: whether jumbo is worth the effort for the
root FS. When I used NFSroot, most of the traffic was queries of
file/dir existence and file/dir att
On Wed, 25 Apr 2007, Ashley Pittman wrote:
> You'd have thought that to be the case but PIO bandwidth is not a patch
> on DMA bandwidth. On alphas you used to get a performance improvement
> by evicting the data from the cache immediately after you had submitted
> the DMA but this doesn't buy you
hell no. ?only a few users even have a guess about how long their
job will run, let alone what it will actually do (in mem or IO usage).
Our users are roughly split into 3 groups, those who have a reasonable idea of
how long their job will run,
we have something like these groupings as well, b
On Wed, 25 Apr 2007, Mark Hahn wrote:
> hell no. only a few users even have a guess about how long their
> job will run, let alone what it will actually do (in mem or IO usage).
Our users are roughly split into 3 groups, those who have a reasonable idea of
how long their job will run, those who
On 25 Apr 2007, at 8:42 am, Toon Knapen wrote:
Interesting. However this approach requires that the IO profile of
the application is known.
Absolutely.
Additionally it requires the users of the application (which are
generally not IT guys) to know and understand this info and pass it
on
No users typically do not know the runtime profile well, so it is up to
the administrators of the batch system to configure LSF so that it can
recognize these types of jobs. This can be done several ways (and I
expect you can do something similar in SGE as well). Some admins go the
simple route a
In your experience, do you manage to convince real-life users to provide this
info?
hell no. only a few users even have a guess about how long their
job will run, let alone what it will actually do (in mem or IO usage).
___
Beowulf mailing list, Beo
On Tue, 24 Apr 2007, Mark Hahn wrote:
so the main question is whether jumbo is worth the effort.
I would rephrase it to say: whether jumbo is worth the effort for the
root FS. When I used NFSroot, most of the traffic was queries of
file/dir existence and file/dir attributes, which are small,
On Wed, 2007-04-25 at 11:31 +0200, Håkon Bugge wrote:
> At 17:55 24.04.2007, Ashley Pittman wrote:
> >That would explain why qlogic use PIO for up to 64k messages and we
> >switch to DMA at only a few hundred. For small messages you could best
> >describe what we use as a hybrid of the above descr
On Wed, 25 Apr 2007, Toon Knapen wrote:
Joe Landman wrote:
If we can assign a priority to the jobs, so that "short" jobs get a higher
priority than longer jobs, and jobs priority decreases monotonically with
run length, and we can safely checkpoint them, and migrate them (via a
virtual conta
> On Tue, Apr 24, 2007 at 04:46:42PM -0400, Douglas Eadline wrote:
>
> > Intel has just announced the ability to place a Xilinx Virtex-5
> > FPGA's into to socket 771, 603,4 (Xeon) motherboard.
> > It sits on the FSB and requires some digital glue (10% of the
> > FPGA). Makes for some interestin
Am 24.04.2007 um 14:30 schrieb Toon Knapen:
Tim Cutts wrote:
but what if you have a bi-cpu bi-core machine to which you assign
4 slots. Now one slot is being used by a process which performs
heavy IO. Suppose another process is launched that performs heavy
IO. In that case the latter proc
"Robert G. Brown" <[EMAIL PROTECTED]> writes:
> On Fri, 13 Apr 2007, [EMAIL PROTECTED] wrote:
>
>> Perhaps I'm not thinking as broadly as Rich. But I see a web-base solution
>> as a
>> better idea than asking (or forcing) ISV's to put some new code in their
>> applications
>> to run on a cluster
On Wed, 25 Apr 2007, Toon Knapen wrote:
> Does anyone know of any projects underway that are trying to accomplish
> exactly this ?
I believe the Moab scheduler supports provisioning of nodes on demand via
various means (xCat, System Imager) and this includes Xen when used with
Torque 2.1:
http
Bill Bryce wrote:
2) use the LSF resource reservation mechanism. This is more complex but
essentially you can boil it down to the idea that you tell LSF to 'bump
up the resource usage' on a resource, making it look like more I/O is
consumed than really is consumed for a given period of time an
Joe Landman wrote:
If we can assign a priority to the jobs, so that "short" jobs get a
higher priority than longer jobs, and jobs priority decreases
monotonically with run length, and we can safely checkpoint them, and
migrate them (via a virtual container) to another node, or restart them
on
33 matches
Mail list logo
