On Fri, 31 Mar 2000, Jesse Pollard wrote:
> "Richard B. Johnson" <root@chaos.analogic.com>
> > > Hello,
> > >
> > > I am looking for synchronization tools between two LINUX computers (without
> > > adding Radio cards).
> > > I know that SNTP (Simple Network Time Protocol) and NTP exists.
> > > In a first short approach, I notice that the best granularity is only 1 ms.
> >
> > You can synchronize to or more computers by connecting them using RS-232C.
> > You have one a master, the others a slave. The master sends 'HZ'
> > characters per second. The slaves use the interrupt instead of timer
> > channel 0. The UART FIFOs are disabled so you get one interrupt/character.
> >
> > Then you can use any method you want to set the slave's time. The time
> > will now remain synchronous with the master.
> >
> > This is the 'cheapie' method.
>
> Variation in time sync > 1ms since the intrrupt latency is large enough
> to exceed this value for all but some real time kernel handling.
Hardly. Latency is in the microsecond range, not millisecond. Further,
interrupts are interrupts, you just point your RS-232 interrupt (IRQ3 or
IRQ3) to the timer-channel (IRQ0) routine. And mask-off IRQ0. Done
that, been there, and it works just fine. You could even use the printer-
port (IRQ7), but it's the lowest-priority IRQ which could delay tick-count
updates and context switching on a system with a lot of I/O.
>
> >
> > If you want something a bit more robust, you can use CPUs with identical
> > motherboards. Install a BNC connector, a cap, resistor and two diodes
> > in place of the CPU board's crystal. Connect them all together to an
> > external clock-generator. There is no master/slave so any machine can
> > go down without taking down the rest. Set all the machines to the same
> > time using whatever method you want. They will stay in sync.
>
> Limitation is distance - the RC network is not precise enough for more than
> about 5 feet. After that you get transmission loss, and weak impulses.
> Plus the potential noise recieved (eased by shielded cables).
>
Not true. The BNC connectors connect to 'tees' just like old thin-wire.
You terminate the last machine with a 50 ohm terminator, and you
drive the starting end with a 5-volt P/P signal from a dedicated
signal generator. All the machines now have the same clock. The
diodes are protection diodes, the resistor-cap are in series.
Cap is a DC blocker, i.e. .001uF, and the resistor is 1k ohms to
5 k ohms.
You can run 100 machines off the same clock, over a thousand feet
of thin-wire coax. The only problem is that they all need to get the same
clock-frequency, which means that all have to have the same-type
motherboards.
FYI. This has been done to control RFI in secure environments. The
common clock is a clock-generator that skews its frequency slightly
with a pseudo-random number. This masks the RFI from keystrokes
and other stuff which would allow a 'listener' to know what was
being typed.
What I proposed is simply to use the same technique with a stable
clock-generator. They all stay in sync.
> > If you don't synchronize the clocks of the computers, they will drift
> > apart. This would require continuous SNTP correction, which occurs in
> > steps. These steps might not be acceptable to your applications.
>
> Of course. SNTP updates are much more reliable than other methods since
> they include a predictive filter that covers both clock variation and
> transmission delay.
>
[SNIPPED...]
> The 1ms granularity is there due to context switching time, and a minimum
> time that can be controlled. Less than 1ms control is well into the noise
> range for synchronization for any but the most demanding RT systems (DSP
> processing). Whenever multiple hosts (loosly coupled) are involved, it will
> be next to impossible to synchronize better than 1ms.
>
Cheers,
Dick Johnson
Penguin : Linux version 2.3.41 on an i686 machine (800.63 BogoMips).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:30 EST