Prev: Virtual Mouse + Keyboard
Next: CreateWindow fail when used at WM_CREATE ?
From: nki00 on 24 Sep 2009 15:15
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: Jerry Coffin on 24 Sep 2009 16:11
In article <h9ggh7$bn1$1(a)aioe.org>, lukkycharm1(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: nki00 on 24 Sep 2009 16:57
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: Vincent Fatica on 24 Sep 2009 17:44
On Thu, 24 Sep 2009 14:11:19 -0600, Jerry Coffin <jerryvcoffin(a)yahoo.com> wrote:

|In article <h9ggh7$bn1$1(a)aioe.org>, lukkycharm1(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
From: nki00 on 26 Sep 2009 21:12
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?




"Vincent Fatica" <vince(a)blackholespam.net> wrote in message
news:4abbe835$1(a)news.vefatica.net...
> On Thu, 24 Sep 2009 14:11:19 -0600, Jerry Coffin <jerryvcoffin(a)yahoo.com>
> wrote:
>
> |In article <h9ggh7$bn1$1(a)aioe.org>, lukkycharm1(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


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