Syncronizing two computers

lpoht has asked for the wisdom of the Perl Monks concerning the following question:

Hi, I have written a small utility for two Win32 boxes that will each be running a slideshow application (an exe file). The issue at hand is that the slideshows must both be started at the exact same time. The software I have written follows a client/server model. Once started, the server loads the slideshow, which waits for a mouse click to start, then listens for commands from the client. The client also loads the slideshow, but then waits a few seconds, then uses Win32::GuiTest to send a mouse click to the local machine. It also sends a command to the server to simulate a mouse click. The commands are ordered to send the current command to the server and then execute it locally, in hopes to syncronize the two machines better. However, it seems that there is up to a 1ms delay between the machines, with the client usually leading. I tried inserting a short sleep on the client, but it actually didn't happen.

The machines are each running Windows XP and are being connected with a Cat5 crossover cable. The network latency should be pretty small with this method. Does anyone have suggestions of ways to better syncronize the two machines? Thanks.

Comment on Syncronizing two computers

Replies are listed 'Best First'.
Re: Syncronizing two computers by BrowserUk (Patriarch) on Jun 26, 2004 at 21:24 UTC
This is almost an impossibility using a multi-tasking OS on two separate machines. Multi-tasking is non-determanistic, which is to say, that there is no trivial way to predict exactly when any given application on a multi-tasking machine will receive a timeslice. There are simply too many system processes competing for those timeslices, and no way to predict when any of those system processes will become ready for scheduling, nor how much of their timeslice they will require to complete their task. Even simple variations, like one machine being configured as a server and the other as a workstation will mean that both machines are probably running different suites of system applications--and probably, different thread quantums (timeslices). You might be able to get this level of synchronicity using a single tasking (DOS-like) OS if the hardware was identical on both machines, but even that is unlikely. The only realistic hope would be to use a real-time OS (like RTOS or QNX). Examine what is said, not who speaks. "Efficiency is intelligent laziness." -David Dunham "Think for yourself!" - Abigail "Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon	[reply]
Re: Syncronizing two computers by matija (Priest) on Jun 26, 2004 at 18:50 UTC
Do you have a high resolution clock under windows (for instance, does Time::HiRes run there?) If you can get hires timer from that or from any other module, select a time not far into the future, and have both machines start then. Of course, you will have to ensure that both machines have synchronized clocks (and I don't know if even NTP can guarantee 1ms resolution in sync).	[reply]
Re: Syncronizing two computers by kschwab (Vicar) on Jun 26, 2004 at 21:37 UTC
Is there a reason that they have to both be running the slideshow ? Could you have PC A run the slideshow while PC B shows PC A's desktop remotely ? TightVNC is pretty popular for remote desktop viewing.	[reply]
Re: Syncronizing two computers by eric256 (Parson) on Jun 26, 2004 at 22:07 UTC
I just wanna know who can visualy detect 1ms enough that it matters. That of course might have something to do with your setup, i just think any remote control is going to be instantaneous, and as others mentioned, the program is NOT going to run withen 1ms of the same speed on two computers. ___________ Eric Hodges	[reply]
Re: Syncronizing two computers by lpoht (Sexton) on Jun 30, 2004 at 01:46 UTC
Thanks for the replies. I guess I'll just have to hope for the best. Certainly 1ms is tolerable, but because of the setup, they must be very close to each other timewise. Thanks again.	[reply]