[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