Linux PARISC architecture development
 help / color / mirror / Atom feed
* [parisc-linux] different PA2.0 CPUs in the same box?
@ 1999-10-18 23:03 Alex deVries
  1999-10-18 23:10 ` Jim Hull
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Alex deVries @ 1999-10-18 23:03 UTC (permalink / raw)
  To: parisc-linux


Can you mix and match different PA2.0 CPUs in a multiprocessor box?  An
8000 and an 8200?  

- Alex

-- 
Alex deVries <adevries@thepuffingroup.com>
Vice President Engineering
The Puffin Group

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: [parisc-linux] different PA2.0 CPUs in the same box?
  1999-10-18 23:03 [parisc-linux] different PA2.0 CPUs in the same box? Alex deVries
@ 1999-10-18 23:10 ` Jim Hull
  1999-10-19  5:31 ` Grant Grundler
  1999-10-19 15:40 ` R Scott Holbrook
  2 siblings, 0 replies; 7+ messages in thread
From: Jim Hull @ 1999-10-18 23:10 UTC (permalink / raw)
  To: Alex deVries, parisc-linux

> Can you mix and match different PA2.0 CPUs in a multiprocessor box?  An
> 8000 and an 8200?  

No.

 -- Jim

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [parisc-linux] different PA2.0 CPUs in the same box?
  1999-10-18 23:03 [parisc-linux] different PA2.0 CPUs in the same box? Alex deVries
  1999-10-18 23:10 ` Jim Hull
@ 1999-10-19  5:31 ` Grant Grundler
  1999-10-19 16:04   ` Grant Grundler
  1999-10-19 15:40 ` R Scott Holbrook
  2 siblings, 1 reply; 7+ messages in thread
From: Grant Grundler @ 1999-10-19  5:31 UTC (permalink / raw)
  To: Alex deVries; +Cc: parisc-linux

Alex deVries wrote:
> 
> Can you mix and match different PA2.0 CPUs in a multiprocessor box?
> An 8000 and an 8200?  

And HP hasn't mix/matched processor clock frequency's in one box either.
870 (4-way/PA1.0/CIO) I think had something funny about the clocks which
I think was repeated in the T-class and possible planned in newer
architectures. Can anyone shed more light on this?

Minimizing clock drift of the various processors in an SMP box is
a difficult problem. Keeping accurate time is important but
synchronization of processors too often can really hurt performance.

grant

Grant Grundler
Communications Infrastructure Computer Operations
+1.408.447.7253

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [parisc-linux] different PA2.0 CPUs in the same box?
  1999-10-18 23:03 [parisc-linux] different PA2.0 CPUs in the same box? Alex deVries
  1999-10-18 23:10 ` Jim Hull
  1999-10-19  5:31 ` Grant Grundler
@ 1999-10-19 15:40 ` R Scott Holbrook
  2 siblings, 0 replies; 7+ messages in thread
From: R Scott Holbrook @ 1999-10-19 15:40 UTC (permalink / raw)
  To: Alex deVries; +Cc: parisc-linux

Alex,

> Can you mix and match different PA2.0 CPUs in a multiprocessor box?
> An 8000 and an 8200?  

No.  All the CPUs will be the same type and run at the same frequency
(and have the same cache size, etc).

Scott

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [parisc-linux] different PA2.0 CPUs in the same box?
  1999-10-19  5:31 ` Grant Grundler
@ 1999-10-19 16:04   ` Grant Grundler
  1999-10-19 16:55     ` Kirk Bresniker
  0 siblings, 1 reply; 7+ messages in thread
From: Grant Grundler @ 1999-10-19 16:04 UTC (permalink / raw)
  To: parisc-linux

Grant Grundler wrote:
> Alex deVries wrote:
> > 
> > Can you mix and match different PA2.0 CPUs in a multiprocessor box?
> > An 8000 and an 8200?  
> 
> And HP hasn't mix/matched processor clock frequency's in one box either.
> 870 (4-way/PA1.0/CIO) I think had something funny about the clocks which
> I think was repeated in the T-class and possible planned in newer
> architectures. Can anyone shed more light on this?

I think I remember the problem now.

The processors can run from a "system clock" and they all run synchronous.
No chance of "clock drift" since they run at exactly the same pace.
But on systems like 870, T-class and N-class, the processors are fed clock
signals from (similar but) different sources.  Each frequency domain will
slowly drift from the "average" and thus the processor clocks need to be
resyncronized regularly.

> Minimizing clock drift of the various processors in an SMP box is
> a difficult problem. Keeping accurate time is important but
> synchronization of processors too often can really hurt performance.

grant

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [parisc-linux] different PA2.0 CPUs in the same box?
  1999-10-19 16:04   ` Grant Grundler
@ 1999-10-19 16:55     ` Kirk Bresniker
  1999-10-20 18:57       ` Grant Grundler
  0 siblings, 1 reply; 7+ messages in thread
From: Kirk Bresniker @ 1999-10-19 16:55 UTC (permalink / raw)
  To: grundler; +Cc: parisc-linux

| 
| The processors can run from a "system clock" and they all run synchronous.
| No chance of "clock drift" since they run at exactly the same pace.
| But on systems like 870, T-class and N-class, the processors are fed clock
| signals from (similar but) different sources.  Each frequency domain will
| slowly drift from the "average" and thus the processor clocks need to be
| resyncronized regularly.
| 

Eh? I can't speak to the T-Class, but N-Class processors (as well as
A,B,C,D,E,F,G,H,I,J,K, and L) all run from a single clock source.  All
of the fundamental problems of clock drift happen between systems, not
interior to a system.  The crystals used are usally 25~50ppm, which
would amount to a second or two per day between systems, which is
significant, but is easily sovled using NTP.

There is no time clock in the processor itself, but rather a register
which is incremented every clock tick. That is why you need to know the
frequency of the processor to convert clock ticks to wall time.  
I believe that there are some wrinkles that can happen in sensing the 
rollover of the interval timer register under all interrupt conditions,
and it may be that this is the 'synchronization' problem that you
are thinking about. But, I don't think that it is due to drift on the
hardware clock circuits.

KMB
--
+============================================================+
|       Kirk Bresniker    	(916) 748-2393		     |
|       8000 Foothills Blvd                                  |
|       Roseville, CA 95747-5649                             |
|       kirkb@rose.hp.com                                    |

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [parisc-linux] different PA2.0 CPUs in the same box?
  1999-10-19 16:55     ` Kirk Bresniker
@ 1999-10-20 18:57       ` Grant Grundler
  0 siblings, 0 replies; 7+ messages in thread
From: Grant Grundler @ 1999-10-20 18:57 UTC (permalink / raw)
  To: Kirk Bresniker; +Cc: parisc-linux

Kirk Bresniker wrote:
> Grant Grundler wrote:
> | The processors can run from a "system clock" and they all run synchronous.
> | No chance of "clock drift" since they run at exactly the same pace.
> | But on systems like 870, T-class and N-class, the processors are fed clock
> | signals from (similar but) different sources.  Each frequency domain will
> | slowly drift from the "average" and thus the processor clocks need to be
> | resyncronized regularly.
> | 
> 
> Eh? I can't speak to the T-Class, but N-Class processors (as well as
> A,B,C,D,E,F,G,H,I,J,K, and L) all run from a single clock source.

Kirk is right. T and V also run from a single clock source.
So no problem. I was confusing the discussions with what actually
got implemented.

my apologies,
grant

Grant Grundler
Communications Infrastructure Computer Operations
+1.408.447.7253

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~1999-10-20 18:59 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
1999-10-18 23:03 [parisc-linux] different PA2.0 CPUs in the same box? Alex deVries
1999-10-18 23:10 ` Jim Hull
1999-10-19  5:31 ` Grant Grundler
1999-10-19 16:04   ` Grant Grundler
1999-10-19 16:55     ` Kirk Bresniker
1999-10-20 18:57       ` Grant Grundler
1999-10-19 15:40 ` R Scott Holbrook

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox