On Wed, 19 May 1999, Eric Roman wrote:
> The wiring for the room was done properly. Once we found out that we
...
> computer lab). So he ran one neutral for the entire room from the panel,
> as opposed to one neutral per circuit, the way computer rooms are done.
That's a split neutral -- and very dangerous. I can't believe that's to
code in any locale. Each single-ended circuit should have its own neutral
return or you get a giant loop. I believe the electrician simply made a
mistake.
> Of course for multiphase! The building mains are three phase four
> wire deals. You run that into a panel. Neutral shouldn't carry any
> power at all.
Neutral will carry substantial power unless the circuits are balanced, which
only occurs with resistive and rotating loads.
> neutral conductor. These odd harmonics don't cancel each other out (the
> even and first harmonics cancel in the neutral) but they can add linearly.
> So you start seeing massive current flow in a neutral that's supposed
> to carry no current.
Not massive, it's limited to about 1.4x that of a single power conductor,
rather than 3x.
> > With common bi-phase power wiring the neutral will never carry more than a
> > single supply conductor.
>
> That's on the supply side away from the panel. The neutral still shouldn't
> carry any power right?
Neutral will almost always be carrying some power. The advantage of
a multiphase-with-neutral supply is that it will usually be less than full
power thus losses will be lower.
> While I've got your attention though, would you mind talking about
> clustering? We're building a cluster of 128 dual Pentium II systems with
..
> Speedup of 2 for 64 processors? Does this make any sense whatsoever?
No, it should be much better. But I haven't run the tests myself.
> Granted, CG sends a lot of small messages, and this is a relatively
> small problem size. But I'd hope to at least get something better than
> a speedup of 2!
What are the typical message sizes?
> It also looks like there's a ton of overhead associated with sending
> small messages. So far we haven't learned a damn thing. (Where are the
> 128 processor results? Nowhere to be found. MPICH doesn't seem to want
> to use more than 122 processors... It stops understanding how to query
> DNS (?) at some point and then runs out of filehandles...)
That's strange. How many file descriptors are in use when this happens?
> This is where you tell me to run a 2.2 kernel because the spinlocks are
> a bit more isolated, you can have more open filehandles, etc.
I was just about to suggest that, but only for the filehandles, not the SMP
changes.
> No one here understands why, but kernel 2.2 seriously breaks MPICH. Jobs
...
> 1/ Every node load drops to zero and one node stays at 1.
> 2/ p4 timeouts w/ closed control connections.
> This happens mainly on large jobs when communication gets very heavy.
> Josip Locarnic reported something similar a few months back and he's had
> luck by disabling packet Nagl'ing on TCP_NODELAY packets. He's been
> eable to get better reliability, but no real fix. I think that what
> happens is that data packets are delayed for so long on a congested
> system that p4's control connection times out and shuts down the job.
> Some of the p4 processes realise this, many don't and the jobs have to
> be terminated manually.
I'm guessing that this doesn't occur when the none are run in uniprocessor
mode, right?
Donald Becker [EMAIL PROTECTED]
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
