On Jan 20, 2:00 am, Unruh <[email protected]> wrote: > >I want to compare the outputs of an application when this app is fed > >with GPS input & when it is fed with HW input > >HW input = series of ("HW timestamp" + event) > >GPS input = series of ("GPS timestamps" + event) > > So feed it with time stamp inputs and see what it does. Why does it care if > they came from HW or GPS or were some random numbers you concocted?
It's a distributed application (it merges tcpdump trace) and I want to compare my merging algorithm when it uses perfect inputs (In this case I run a GPS on all nodes) & when it uses non perfect timestamps (no GPS embedded) > >I want the same list of event. Only the timestamp can differ in the > >inputs. > >So I have to run the exeperience only once (i don't want to run an > >experience with GPS and an experience whithout GPS) > >The only way to do that is to invent a way to convert GPS timestamps > >to HW timestamps > >(i.e. the timestamps that would have been generated if the GPS was > >disabled) > > ???? Make them up. Make them up (the english word "make up" is quite confusing for me): you mean correct the drift as Terje Mathiesen previously explained me? (cf "Well, you could take the readings of the frequency drift rate correction and integrated them up"). If yes, I agree and that what I'm trying to do now. > >> >1)My first idea was to recreate (off line) the hw timestamps by > >> >-inverting the NTP kernel clock discipline algorithm > >> >-feeding it with the loopstats statistics and my gps time series > > >> ??? It is a dissipative system. going backwards is highly unstable. > >It's just a conversion function F that I was thininking about: F: GPS > >timestamp -> HW timestamp. > >After conversion, the HW timestamps=F(GPS timestamps) should grows > >monotonically as the GPS ones. > > It is monotonic. It is in general a very complicated function in detail. Unruh, do you agree with that: 1)In user space)NTP send parameters (cf adjtimex) to the kernel disipline. These parameters are logged in the loop file. 2)In kernel space)The kernel disipline feeds the PLL loop with the parameters it receives from userspace. and try to achieve them. The PLL algorithm is very complicated and it takes time to adjust the clock. 3)The parameters send by NTP to the kernel are values measured between the last kernel update and now. 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) > >However, it is not as simple as one can think, > >because it seems that ntp sync the hardware clock each 11 minutes:( > >This sync must be disabled. > >Is there a way to do that? > > Sorry, you are confused. The computer when it is running does not use the > battery controlled real time clock at all. It uses a clock based on the > timer interrupts and the frequency of the CPU ( or the on board HPET > frequency standard) The RTC is completely and utterly ignored. It is that > which is "reset" every 11 min. That is different from the clock which the > computer actually uses while it runs. > > So which one do you want. > Yes I was! You're absolutely right! (I knew there are two clocks but I thought the drift relative to the true time was the same because I though the SW clock was initialized with the HW clock parameters) I want the clock the computer uses when it runs whitout GPS (ie the SW clock w/o GPS) _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
