Prev: Virtual Mouse + Keyboard
Next: CreateWindow fail when used at WM_CREATE ?
From: Jerry Coffin on 27 Sep 2009 17:53
In article <h9me5t$pac$2(a)aioe.org>, lukkycharm1(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: Vincent Fatica on 27 Sep 2009 20:41
On Sat, 26 Sep 2009 18:12:42 -0700, "nki00" <lukkycharm1(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 28 Sep 2009 08:40
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 28 Sep 2009 08:40
On 24 Wrz, 22:11, Jerry Coffin <jerryvcof...(a)yahoo.com> wrote:
> In article <h9ggh7$bn...(a)aioe.org>, lukkycha...(a)gmail.com says...
>
>
>
>
>
>
>
> > 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?
>
> Have you looked at the NTP specification? They put in quite a bit of
> work dealing with this exact issue.
>
> --
>     Later,
>     Jerry.

From: http://books.google.com/books?id=ifqnAAAACAAJ&dq=inauthor:%22Russ+Manning%22&lr=&as_brr=0&rview=1&so on 28 Sep 2009 08:40
On 24 Wrz, 23:44, Vincent Fatica <vi...(a)blackholespam.net> wrote:
> On Thu, 24 Sep 2009 14:11:19 -0600, Jerry Coffin <jerryvcof...(a)yahoo.com> wrote:
>
> |In article <h9ggh7$bn...(a)aioe.org>, lukkycha...(a)gmail.com says...
> |>
> |> 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?
> |
> |Have you looked at the NTP specification? They put in quite a bit of
> |work dealing with this exact issue.
>
> Jerry is correct, considerable work has been put into this.
>
> Here, briefly, is how NTP works (without the protocol details).  It's clever,
> and somewhat elegant.
>
> At time T1, the client sends a request to a NTP server.  The request includes a
> T1-stamp (although the server does not need it).  The server replies by sending
> two time stamps, T2 = when the server received the request, and T3 = when the
> server sent the reply.  The client notes T4 = when it received the reply.
>
> The client has all four times.  From the client's point of view, the "middle" of
> the transaction happened at (T1 + T4)/2.  From the server's point of view, the
> "middle" of the transaction happened at (T2 + T3)/2.  The server is assumed to
> be correct, and the difference between these two estimates of "middle" is taken
> to be the offset of the client's clock; the client corrects his clock by that
> much.
>
> If the network delay is the same in both directions, the estimate of the offset
> is accurate.  In practice, it's pretty good, with typical errors from 0 to (say)
> 10-20 ms.  Of course, badly lop-sided network times will make it worse.
>
> All the timestamps are 64 bits and UTC.  The high 32 bits represent the integer
> number of seconds since 00:00:00 01-01-1900.  The low 32 bits are treated as the
> integer numerator of a fraction with denominator = 2^32, and thus represent the
> fraction of a second (with precision, at least theoretically, 1/2^32 sec)..
>
> --
>  - Vince

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Virtual Mouse + Keyboard
Next: CreateWindow fail when used at WM_CREATE ?