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 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 28 Sep 2009 08:40 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 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: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 28 Sep 2009 10:31 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
First
|
Prev
|
Pages: 1 2 3 Prev: Virtual Mouse + Keyboard Next: CreateWindow fail when used at WM_CREATE ? |