Ed Pugh wrote: > I would like to find some > way to ACCURATELY synchronize > the TOD (i.e. the time-and-date) > clocks between two palm PDAs using > the IR port. (I.e. so that they > turn over seconds as close together > as possible.) : : > TimeShare utility, but it just sends > the current time from one palm to the > other, and the receiving palm sets > its clock to that time WELL AFTER > that time occurred on the sending palm.
You mentioned the NTP system, and NTP has at least three important algorithms in it: one to discipline the local clock (i.e. correct for natural drift), one to determine which remote clocks are "good" and "bad", and one to synchronize over the network. Here's my understanding of how the synchronize-over-the-network part works: Imagine you live about half an hour away from the next town down the road. You take a trip to that town, and you drive at your normal speed. When you get there, you immediately turn around and come back. You left your town at 2:03pm and arrived back at the starting point at 3:09pm. What is the best estimate for the time you reached the neighboring town and turned back? It should have occurred right in the middle, so it should be at 2:36pm that you were in the other town. For a more accurate estimate, you might think to make the trip 5 times, record everything, discard the outliers, and take the mean. Sounds like a good idea, except that taking the mean of several clock readings is not meaningful. However, if the neighboring town had a clock in the town square that was known to keep good time but was also known to be set to the wrong time, you could take the differences between your individual computed times and the readings on the clock in the neighboring town. Then, you could take the mean of the differences. For example, you might conclude on your first trip that the neighboring town's clock seems to be 75 minutes behind, and on the second trip it seems to be 72 behind, then 74, then 74, then 73. So you discard 72 and 75, and the mean of 74, 74, and 73 is 73.66. So there's an algorithm for determining the time difference between clocks of two machines on the network. Machine A sends out a packet to B with a timestamp in it, Machine B receives it, immediately adds its own timestamp and returns it to A, and then Machine A records a third timestamp. Then you have measured that Machine A's clock is ahead of Machine B's clock by ((stamp3-stamp1)/2 - stamp2) time units. Now, there is a big source of possible error here: who says the round trip is symmetrical? In the trip to the other town, perhaps there is one-way street that saves you lots of time in one direction but you have to go the long way in the other direction. Likewise, in the network, there may be some kind of systemic delay (like queueing or scheduling or asymmetrical transmission speeds or asymmetrical traffic) that affects trips in one direction more than the other. If you want to get around this, you can make the measurements in BOTH directions. Have Host A send a packet that makes a round trip to Host B. Then have Host B send a packet that makes a round trip. Then average the two. Finally, once you've computed the number of milliseconds that one clock is ahead of the other, there is still one other hurdle left: how can you make precise adjustments to the clock on the local machine? This may actually be fairly tough on the Palm! You can call TimSetSeconds(), but the argument is only in seconds, not in ms. You can also call TimAdjust(), but the argument is still only in seconds. There is a TimGetTicks(), but there is no corresponding TimSetTicks()! About the best you can hope for is that TimSetSeconds() or TimAdjust() will reset the clock EXACTLY to the second. In other words, that it will set the seconds to whatever its arguments are, and set the fractional parts of a second to zero. That is, if you call it at time 900000003.200 seconds with an argument of 90000004 seconds, that it will advance the clock by 0.800 seconds rather than 1.000 seconds or something. *IF* this is the case, then you can use a delay loop and constantly call TimGetTicks() in order to wait until exactly the right time to call TimSetSeconds(). It may even be trickier than that. How do you know what value of TimGetTicks() will correspond with the second-based clock advancing to the next second? It may not just be when TimGetTicks() % SysTicksPerSecond() == 0. It may be when TimGetTIcks() % SysTicksPerSecond() == N, where N is some number that changes every time the system goes to sleep! (Or it may be some other thing more complicated than that, but hopefully not.) Luckily, you should be able to solve this problem too: just call TimGetSeconds() over and over in a loop and wait for its return value to change, and also call TimGetTicks() every time you call TimGetSeconds(). The first time TimGetSeconds() returns something different, make a note of the value of TimGetTicks(). That should tell you something about what time is the proper time to call TimSetSeconds(). ;-) Lastly, you may find there is some systemic delay involved in setting the clock. You might find that even if you call TimSetSeconds() at the supposedly-right time, things are always off by 0.1 seconds or something. You could determine this by making another measurement of the time from the remote system over the network. If it's consistently off by some amount, then you can correct for this and do the whole process of setting the time again, but this time taking into account a factor that corrects for how much your time-setting process skews things. But that's just an enhancement to increase accuracy. OK, well, I can see that this has gotten to be a hugely long e-mail. (Can you tell I find this timing stuff fascinating?) Before I go, I'll repeat that all of this is theoretical. ESPECIALLY the parts about how TimGetTicks() and TimSetSeconds() relate; my mental model may be nothing like what really happens inside Palm OS! Or maybe it's different with different release of Palm OS. (The OS sample source I have isn't very enlightening on this particular subject. It just calls some mysterious stub function to do all the real work.) - Logan - Logan -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
