[email protected] writes: >> >As a conclusion I can use them to estimate the skew (as you suggest >> >"by integrating ....and so on") over the last period (the period >> >between the last kernel update and now) >> >> I still have absolutely no idea what you are trying to do. >>
>Here is what I want to do (I have reformulated my initial mail with >the corrections you brought): >I'm trying to track the drift of my GPS clock RELATIVE to >the clock that I would have obtained without GPS (and vice versa). Again GPS is exactly right time. The computer time is "bad". >My final goal is to convert a series of gps timestamps to the >equivalent unsychronized timestamps. I would think you goal would be to have everything in terms of the gps time. Each computer has its own time, which could be seconds, minutes, hours off the "real" time ( depending on how long you wait). >As a result I would be able to test a new merging algorithm for >tcpdump traces. >This algorithm is robust because it is based on >special techniques (it uses common packets in the traces to provide >synchronisation). Why not include ntp packets in the trace and then you know exactly what the time is. >So my algo works even if the PCs of the network are not synchronized. >Because this is a research work, I need to compare the solution of my >algo for an unsychronized network (no GPS installed) >with the results that I would have been obtained with a synchronized >network (in this case the PCs use GPS). >I want to do the timestamp conversion offline (ie, at the end of the >experience) and I want microsec precision >because the packet timestamps in the tcpdump trace are written in >microsecond. >I m sure a solution exists (as the one suggested by >"Terje Mathisen" & Unruh) : >1) Terje proposes two solutions a) and b): >a)Just enable logging of the loop frequency (i.e. the freq offset), >and >integrate that value over time. This gives you the offset at any given >time. >b)Alternatively it is in fact possible to run NTP with the corrections >disabled (or using the local clock as the reference) and then fundge >the >GPS to something like stratum 14 or 15. In this case the clockstats >file will probably log every single GPS >sample with the current offset between GPS and system clock. >2) In any cases, I can mathematically model the drift as a constant >value (the concocted solution of Unruh?). No it is not a constant value. It fluctuates. >In this case, I won't use the real timestamps generated on my PCs but >it could be a possible solution if 1a) and 1b) don't work _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
