[LinuxPPS] Something Funny going on with linuxPPS (again).
Rodolfo Giometti
giometti at enneenne.com
Fri Oct 19 08:41:57 CEST 2007
On Thu, Oct 18, 2007 at 02:02:28PM -0600, clemens at dwf.com wrote:
>
> Rodolfo:-
>
> I guess I dont understand why my statement that there is something wrong is
> so hard to understand. But perhaps we are working from different directions.
>
> My assumption about the kernel code is that the pps driver has one location
> each
> to save the most recent ASSERT and CLEAR time stamps. When either of these
> events takes place the timestamp is updated.
Ok.
> My assumption is that when the user code calls time_pps_fetch, he is presented
> with the contents of these two locations.
Yes.
> Thus, if either timestamp CHANGES it has to be at a LATER time than any
> previous
> timestamp.
Ok.
> Here is the code that is producing the output that I showed in my previous
> two e-mails. Its a slight modification of something I have been using for
> years.
> [snip]
> while (1) {
> timeout.tv_sec = 0;
> timeout.tv_nsec = 0;
>
> i = time_pps_fetch(ph, PPS_TSFMT_TSPEC, &pi, &timeout);
> if (i < 0) {
> err(1, "time_pps_fetch");
> perror("fetch:");
> }
>
> if (olda != pi.assert_sequence) {
> printf("A: %lu.%09lu #%lu\n",
> pi.assert_timestamp.tv_sec,
> pi.assert_timestamp.tv_nsec,
> olda = pi.assert_sequence;
> }
> if (oldc != pi.clear_sequence) {
> printf(" C: %lu.%09lu
> #%lu\n",
> pi.clear_timestamp.tv_sec,
> pi.clear_timestamp.tv_nsec,
> pi.clear_sequence);
> oldc = pi.clear_sequence;
> }
> usleep(25000);
You don't need it since the time_pps_fetch() is blocking.
> }
>
> exit(0);
> }
>
> ---
>
> The only significant thing is the print loop at the very end.
> You will note that I loop forever, with a usleep of 25ms in the loop.
> In the printouts, the Assert and Clear timestamps are separated by 100ms, so
> I am picking up these timestamps INDIVIDUALLY, with 3 wasted passes thru the
> loop between the closest pair.
>
> My code only prints a timestamp if its sequence number has changed, and then
> goes on to test the other timestamp.
Ok.
> BUT, LET ME SIMPLIFY THE PRINT LOOP ABOVE TO READ:
>
> ---
>
> while (1) {
> timeout.tv_sec = 0;
> timeout.tv_nsec = 0;
>
> i = time_pps_fetch(ph, PPS_TSFMT_TSPEC, &pi, &timeout);
> if (i < 0) {
> err(1, "time_pps_fetch");
> perror("fetch:");
> }
>
> [1] if (olda != pi.assert_sequence || oldc != pi.clear_sequence) {
> printf("A: %lu.%09lu #%lu C: %lu.%09lu #%lu\n",
> pi.assert_timestamp.tv_sec,
> pi.assert_timestamp.tv_nsec,
> pi.assert_sequence,
>
> pi.clear_timestamp.tv_sec,
> pi.clear_timestamp.tv_nsec,
> pi.clear_sequence);
>
> olda = pi.assert_sequence;
> oldc = pi.clear_sequence;
> }
> usleep(25000);
> }
>
> ---
>
> Now there can be no question about what is being printed.
> If EITHER sequence number changes, BOTH the timestamps are printed.
Ok.
> >From my model of what is going on back in paragraph #2 and #3, then
> if the timestamps for assert or clear changes that has to be at a LATER
> time than any previous timestamp. I assume we could miss a timestamp
> but TIME CANT GO BACKWARD.
> [snip]
Can you please remove the if clause above (marked with [1]) and report
the results? Or, can you please do the test with ppstest?
> And this comes after seeing some VERY strange results in NTP.
> I would find the NTP on Linux running choosing the LOCAL clock
> and a remote machine running FreeBSD as its standard rather than
> the LinuxPPS interfaced GPS unit. It would be showing an offset of
> -2sec from the GPS unit. At the same time everything was running fine with
> the ntp on FreeBSD.
Did you check the offsets compensation settings in pps_getparams?
> I finally backed it up to these problems with the times of changes not
> being in increasing order.
>
> I really gota' look at that kernel code.
Yes, you should enable debugging messages and look at which timestamps
you get the PPS signal.
> Sorry for the long explanation, but I just couldnt figure out how to
> say it any more compactly.
Don't worry about that! I'd like good and long explanations! :P
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail: giometti at enneenne.com
Linux Device Driver giometti at gnudd.com
Embedded Systems giometti at linux.it
UNIX programming phone: +39 349 2432127
More information about the LinuxPPS
mailing list