[EMAIL PROTECTED] (maxime louvel) writes: >On Tue, Apr 29, 2008 at 6:27 PM, Unruh <[EMAIL PROTECTED]> wrote:
>You're right on this point, what I actually get with PTP is delay of 100 >usec, with a variation of 10 usec. >But I'm only interested in the variation as the 100usec can be removed >easily because it's constant The delay is probably what ntp also calls the delay-- the time between when the packet is sent and when it is received back (minus the time spent in the server) (t4-t1)-(t3-t2) in ntp jargon. This is assumed to be symmetric and is already cancelled. The ONLY way to really measure if there assymetry is to put a real clock on each of the machines (Ie, a clock synchronized to usec accuracy to UTC-- eg a GPS PPS ) and measure the offset of each of the machines from GPS time. >> >> >> >I might try the other solutions, if yeI do I'll send an email to complete >> >the results. >> >> As I said, I am completely at a loss to know why you would only be getting >> 1ms using ntp to synchronize. That is much worse than my experience. (Look >> at flory on www.theory.physics.ubc.ca/chrony/chrony.html which uses ntp vs >> the other machine which all use chrony. flory's fluctutations are >> certainly not 1ms.) >> >I have to say that I 'm also surprise of the bad performance of NTP, I will >try chrony if it is suitable to my nodes (embedded cards, with the latest >linux kernel). If it is a 64 bit machine, there is a little bug being tracked down right now. The latest version of chrony is 1.23 As I said I get nothing like your inaccuracy with ntp. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
