mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stan Hoeppner <stan@hardwarefreak.com>
To: "'Paul Jackson'" <pj@sgi.com>, ebiederm@xmission.com
Cc: mbligh@aracnet.com, Simon.Derr@bull.net, colpatch@us.ibm.com,
	pwil3058@bigpond.net.au, frankeh@watson.ibm.com,
	dipankar@in.ibm.com, akpm@osdl.org,
	ckrm-tech@lists.sourceforge.net, efocht@hpce.nec.com,
	lse-tech@lists.sourceforge.net, hch@infradead.org,
	steiner@sgi.com, jbarnes@sgi.com, sylvain.jeaugey@bull.net,
	djh@sgi.com, linux-kernel@vger.kernel.org, ak@suse.de,
	sivanich@sgi.com
Subject: RE: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placemen t
Date: Sat, 16 Oct 2004 03:01:32 -0500	[thread overview]
Message-ID: <65717CC11CAED4118C1100A02401ECAA072C7F@RAMIUS> (raw)

 
> Kevin McMahon <n6965@sgi.com> pointed out to me a link to an 
> interesting
> article on gang scheduling:
> 
>   http://www.linuxjournal.com/article.php?sid=7690
>   Issue 127: Improving Application Performance on HPC Systems 
> with Process Synchronization
>   Posted on Monday, November 01, 2004 by Paul Terry Amar Shan 
> Pentti Huttunen
> 
> It's amazingly current - won't even be posted for another 
> couple of weeks ;).


It appears they are using their Rapid Array ASICs/network for the time
synchronization.  I wonder if it would be possible to implement this
solution on standard cluster hardware that doesn't have this custom network
with its inherent fine grained clock.  NTP wouldn't be able to give
microsecond level time synchronization would it, considering its daemon
status...

This would definitely be a feather in the cap for someone who could code
this to work with SHV (standard high volume) hardware.

Stan Hoeppner
TheHardwareFreak
stan@hardwarefreak.com

                 reply	other threads:[~2004-10-16  8:01 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=65717CC11CAED4118C1100A02401ECAA072C7F@RAMIUS \
    --to=stan@hardwarefreak.com \
    --cc=Simon.Derr@bull.net \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=ckrm-tech@lists.sourceforge.net \
    --cc=colpatch@us.ibm.com \
    --cc=dipankar@in.ibm.com \
    --cc=djh@sgi.com \
    --cc=ebiederm@xmission.com \
    --cc=efocht@hpce.nec.com \
    --cc=frankeh@watson.ibm.com \
    --cc=hch@infradead.org \
    --cc=jbarnes@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lse-tech@lists.sourceforge.net \
    --cc=mbligh@aracnet.com \
    --cc=pj@sgi.com \
    --cc=pwil3058@bigpond.net.au \
    --cc=sivanich@sgi.com \
    --cc=steiner@sgi.com \
    --cc=sylvain.jeaugey@bull.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®