From: http://books.google.com/books?id=ifqnAAAACAAJ&dq=inauthor:%22Russ+Manning%22&lr=&as_brr=0&rview=1&so on
On 27 Wrz, 23:53, Jerry Coffin <jerryvcof...(a)yahoo.com> wrote:
> In article <h9me5t$pa...(a)aioe.org>, lukkycha...(a)gmail.com says...
>
>
>
> > Vince, thanks alot. Interestingly enough I came up with the same
> > implementation myself (without even knowing about NTP). The problem that I
> > faced with it is that the transmission time from the client to the server
> > might not be the same as transmission time from the server to the client,
> > thus putting that little formula out of whack.
>
> It's certainly not perfect, but about the only realistic improvement
> is to use something else entirely (e.g. a GPS receiver at each
> installation).
>
> --
>     Later,
>     Jerry.

From: http://books.google.com/books?id=ifqnAAAACAAJ&dq=inauthor:%22Russ+Manning%22&lr=&as_brr=0&rview=1&so on
On 28 Wrz, 02:41, Vincent Fatica <vi...(a)blackholespam.net> wrote:
> On Sat, 26 Sep 2009 18:12:42 -0700, "nki00" <lukkycha...(a)gmail.com> wrote:
>
> |Vince, thanks alot. Interestingly enough I came up with the same
> |implementation myself (without even knowing about NTP). The problem that I
> |faced with it is that the transmission time from the client to the server
> |might not be the same as transmission time from the server to the client,
> |thus putting that little formula out of whack. I guess, there's absolutely
> |no way to control that, or at least know the transmission time one way, is
> |there?
> |
> |Also, say, if I establish this connection via Internet (both ends high-speed
> |DSL modems) between two machines in the U.S., how big will that variation
> |be?
>
> I implemented it myself in a replacement for Windows' W32Time.DLL (Windows Time
> Service).  Here a brief log excerpt.
>
> Sep 14 03:06:59 2009  time-b.nist.gov  Correction: -0.067 s  RTT:  35 ms
> Sep 15 03:06:59 2009  time-b.nist.gov  Correction: -0.012 s  RTT:  33 ms
> Sep 16 03:06:59 2009  time-b.nist.gov  Correction: +0.036 s  RTT:  31 ms
> Sep 17 03:06:59 2009  time-b.nist.gov  Correction: -0.078 s  RTT:  35 ms
>
> If a round-trip time of, say, 34 ms were completely lopsided (0 ms in one
> direction, 34 ms in the other) the error in setting the clock would be 17 ms.  I
> can live with that.  Besides, there's nothing that can be done about it..
>
> Note: My system clock is not as accurate as those entries suggest.  My DLL also
> uses SetSystemTimeAdjustment() to cycle the system clock between two rates (one
> cycle per hour) throughout the day.  The time spent at each rate is adaptive;
> i.e., if the adjustment needed is beyond a certain threshold, the rates are
> adjusted so the next sync will be better.  Left alone, my clock would be off by
> 4-5 seconds a day.
>
> My ISP is RoadRunner so I usually get good times.  I recommend that if you're
> using a busy public server, sync the time at an oddball time when it's less
> likely to be busy.
> --
>  - Vince

From: http://books.google.com/books?id=ifqnAAAACAAJ&dq=inauthor:%22Russ+Manning%22&lr=&as_brr=0&rview=1&so on
On 24 Wrz, 21:15, "nki00" <lukkycha...(a)gmail.com> wrote:
> I'm working on a project where I need to synchronize time on several PC's
> connected to a network. I want to point out that this synch should be as
> precise as possible - down to milliseconds. What seems like a trivial task
> has become quite a challenge, so I need your take on it. Here's what I do:
>
> 1. The source machine reads time in an 8-byte time stamp and transmits it
> via TCP/IP.
>
> 2. The target machine reads the stamp from a TCP/IP transmission and sets
> its time according to it.
>
> The issue is how to know the transmission time over the network? I can learn
> how long it takes for a packet to be sent and then received back, and divide
> that value by 2, but that is still an imprecise method.
>
> Now I'm wondering, is there a method to send precise time over a network
> besides the one I'm using?

From: http://books.google.com/books?id=ifqnAAAACAAJ&dq=inauthor:%22Russ+Manning%22&lr=&as_brr=0&rview=1&so on
On 24 Wrz, 22:57, "nki00" <lukkycha...(a)gmail.com> wrote:
> Thanks. Sounds what I need. I just can't seem to find a good C++ sample on
> the subject.
>
>
>
> > Have you looked at the NTP specification? They put in quite a bit of
> > work dealing with this exact issue.
>
> > --
> >    Later,
> >    Jerry.

From: Dee Earley on
On 27/09/2009 02:12, nki00 wrote:
> Vince, thanks alot. Interestingly enough I came up with the same
> implementation myself (without even knowing about NTP). The problem that I
> faced with it is that the transmission time from the client to the server
> might not be the same as transmission time from the server to the client,
> thus putting that little formula out of whack. I guess, there's absolutely
> no way to control that, or at least know the transmission time one way, is
> there?

I beleive there is "jitter" which allows the client to see what the
offsets are on subsequent requests and take that into account.

> Also, say, if I establish this connection via Internet (both ends high-speed
> DSL modems) between two machines in the U.S., how big will that variation
> be?

It could be anywhere from 10ms to 30s.

--
Dee Earley (dee.earley(a)icode.co.uk)
i-Catcher Development Team

iCode Systems