"Syncing cpus" on a multi-cpu, dual core system

Simon Roberts thorpflyer at yahoo.com
Fri Dec 15 08:47:37 PST 2006

----- Original Message ----
> On a computational chemistry list I subscribe to there is a
> current thread about multi-cpu systems needing to have the cpu
> frequencies synced (this is in a Linux context).  This is
> evidently not just having the cpus running at nominally the same
> frequency but something else in addition.  A posting in the thread
> said variations less than 0.1% were not problematic.  However, the
> poster said it was an issue in a dual cpu, dual core system he had
> set up.
> My questions are:
> 1. Is this real or an urban legend?

If CPUs use the same FSB (as is the case with dual-core chip), they are
already in sync. Right? For system that use multiple FSB clocks [like
dual-(dualcore-CPU) systems], it might be possible to vary the clocks
(as much as the manufacturer allows without hw modifications: e.g.,
SpeedStep, or something similar).

Why someone would want to have CPUs running at precisely the same
frequency is beyond my imagination.


My dual core system does speedstep the two CPUs independently, it's clearly visible when running the speed monitor applets. I guess if only one thread is busy, only one CPU needs to work hard.

As to why it would matter that they be in sync? My imagination runs to these two possibilities: 1) someone is writing multi-threaded software but doesn't really know how to do this correctly. 2) someone is writing ultra-high performance multi-threaded software that requires two threads on the two CPUs to be able to run in a way that doesn't risk data corruption, but needs to be able to do it without slowing down to check monitors/semaphores/other-threadsafety-devices. To address this, they've counted CPU cycles and are running a producer and consumer type scenario in such a way that the threads are perfectly out of phase with one another, so as to ensure that reads by one are not mixed in with writes by the other. I guess option 2 would be kinda legitimate, but I suspect actually a special case of 1 anyway--mainly because I find it hard to believe it has a snowball's chance in hell of working on systems that have pipelines, instruction look-ahead, etc. Might have worked on a dual 6502 based system when you knew exactly how long an instruction would take, and it always took that long :)

Bottom line; I'm inclined to the urban-legend classification.


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

More information about the freebsd-hackers mailing list