[email protected] writes:
>On Jan 20, 2:00=A0am, 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 =3D series of ("HW timestamp" + event)
>> >GPS input =3D 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)
So? Feed it with fake times. Since network delays in a local network are
in the microsecond range ( say 50usec) if your clocks are not accurate to
much better than that, your algorithm will get the order wrong on packets
sent out and received. Your option is eitehr to put a gps on each system or
forget about getting the correct ordering of the events.
>> >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?
No I mean make up the timestamps. You are testing. Feed the test with your
own timestamps and see how it performs.
IF you want your systems to be free running, the times on the various
systems will differ by seconds and minutes.
>(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=3DF(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.
IF adjtimex exists. Otherwise it does it in user space.
>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.
NO it is very simple. It changes the rate at which the internal clock runs
( ie changes the trasnlation from internal frequency events-- eg cpy cycles
or HPET frequency counts) to clock time. That is all it does.
>3)The parameters send by NTP to the kernel are values measured between
>the last kernel update and now.
No. They are based on values of the offset between the internal time and
some suitable selection of ntp measurements of external time made in the
recent past.
>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.
>> >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.
>>
>> =A0So 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)
It may be initialised with the RTC, but the rtc is a totally different
clock with its own drift and weirdnesses. And on Linux HPET system, it is
totally broken for timekeeping purposes.
>I want the clock the computer uses when it runs whitout GPS (ie the SW
>clock w/o GPS)
It is the same clock that runs with GPS. All ntp does with a GPS PPS input
is to try to make the translation between that clock's ticks and real time
be accurate as possible.
Note that without ntp, the internal clock will in general be out by many
seconds and will run at the wrong rate by up to 100PPM (well with the
current Linux kernel and the tsc bug, it will be out by many 100s of PPM.
)
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.org/mailman/listinfo/questions
