Re: [ntp:questions] NMEA driver using common PPSAPI code

[Venu Gopal]

Hello Dave,

Following are few observations with NMEA driver using common PPSAPI:

1. flag1 0, flag2 0, flag3 0, time1 0 and time2 0 : Normal behavior
2. flag1 1, flag2 0, flag3 0, time1 0 and time2 0: Clock is stepped on
startup and on clock_sync event
3. flag1 1, flag2 0, flag3 1, time1 0 and time2 0: Clock is stepped on
startup and on clock_sync event
4. flag1 1, flag2 0, flag3 0, time1 0 and time2 x: Clock doesn't step
(Normal behavior)
5. flag1 1, flag2 0, flag3 1, time1 0 and time2 x: Clock doesn't step
(Normal behavior)

I've tested with uBlox GPS receiver (which of course doesn't spit ZDG
sentences).
The moment I use Accord's GPS Clock, which generates ZDG, the clock steps
randomly
sometimes from few milli-seconds to 14.5 seconds. The biggest problem here
is that the step
size if not constant :-).

Any clues of why this is happening?
If someone can hint me how to debug, I can check with the existing setup.
Somehow
this never happened with the older version.

Regards,
Venu
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NMEA driver using common PPSAPI code

[Venu Gopal]

Hello Dave,

I never used the time1 and time2 flags in the older NMEA driver.
And neither I did with the newer code. As per your suggestion I tried
to use time1 and time2 in the newer code to see if it helps. But it didn't
and instead it made it worse.

My point is simple. If it works with older NMEA driver then it should work
with the newer one too (without the need of using time1 and time2 flags).

I am literally tired of these experiments :-). And I hope to hear if someone
is using
the new driver successfully. This would be my last attempt of using time2
flag
and see if it works. All wanted to check is the significant changes
submitted by
Juergen Perlinger for https://bugs.ntp.org/show_bug.cgi?id=1571.

Thanks & kind regards,
_Venu


On Thu, Oct 7, 2010 at 5:19 AM, Dave Hart  wrote:

> On Wed, Oct 6, 2010 at 09:42 AM, Venu Gopal  wrote:
> > Hello Folks,
> >
> > I tried using time1 and time2 flags but things became worse :-(.
> > Everything works fine with NMEA driver when using local PPSAPI.
> > And I don't need use time1 or time2 flags (set to 0 by default).
>
> I believe you are conflating two separate issues.  At the time the
> NMEA driver had its own PPSAPI code, it used a single fudge for both
> PPSAPI and serial end-of-line timestamp offsets.  Since then, the two
> fudge factors were separated, to allow improved startup behavior by
> bringing the serial timestamp closer to the PPS that is eventually
> used.
>
> If you are switching back and forth between older and newer ntpd to
> test using NMEA-local PPSAPI code, you are also switching between the
> prior and current fudge behaviors.
>
> The short-term goal you should have is to experiment with "fudge
> 127.127.20.x time2 y" varying y to attempt to reduce the size of the
> step when switching from serial timestamps to PPS.  Do this without
> hardpps, at least initially.  You should within a few tries be able to
> get the difference between the two times in the tens of milliseconds
> or better.
>
> I'm pretty confident others are using the newer NMEA code, sine it has
> been that way for well over a year.
>
> Good luck,
> Dave Hart
>
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NMEA driver using common PPSAPI code

[Venu Gopal]

Hello Folks,

I tried using time1 and time2 flags but things became worse :-(.
Everything works fine with NMEA driver when using local PPSAPI.
And I don't need use time1 or time2 flags (set to 0 by default).

If thats the case why its not working with the current NMEA driver
where common PPSAPI code is used.

I am not sure if some one is using the latest NMEA driver or the
versions since common PPSAPI code is introduced into it.

Thanks & kind regards,
_Venu
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NMEA driver using common PPSAPI code

[Venu Gopal]

Hello Dave,

1. NTP configuration:

server 127.127.20.0 mode 24 minpoll 4 maxpoll 4
fudge 127.127.20.0 flag1 1
fudge 127.127.20.0 flag2 0
fudge 127.127.20.0 flag3 1

driftfile /etc/ntp.drift
statsdir /var/log/ntp/

logfile /var/log/ntp/ntp.log
logconfig +all

statistics loopstats peerstats clockstats
filegen peerstats file peers type day link enable
filegen loopstats file loops type day link enable
filegen clockstats file clocks type day link enable

-

2. NTP was restarted intentionally to reflect the problem.
Assuming that once the time is set properly I wonder why
NTP resets the system clock by 0.3 seconds when restarted.

3. To verify if the problem is due to the handling of different times (UTC &
GPS),
NMEA driver was modified to ignore ZDG messages. As per the configuration
shown above only ZDA messages are being used.

4. I feel that this problem might be related to the usage PPSAPI common
code,
since it never occurs in the earlier versions of NTP using local PPSAPI.

5. I'll try with kernel PPS disabled and setting the appropriate fudge flags
and
let you know the behavior.

Thanks & Kind Regards,
_Venu
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NMEA driver using common PPSAPI code

[Venu Gopal]

Hello Dave,

After spending some time I could see that there is an issue with using
common PPSAPI code.
I disabled ZDG messages (containing GPS time) and the driver is supposed to
use the UTC time
in ZDA messages. Here is the output of NTP log:


29 Sep 05:44:20 ntpd[4156]: GPS_NMEA(0) serial /dev/gps0 open at 9600 bps
29 Sep 05:44:20 ntpd[4156]: GPS_NMEA(0) 8011 81 mobilize assoc 26949
29 Sep 05:44:20 ntpd[4156]: 0.0.0.0 c016 06 restart
29 Sep 05:44:20 ntpd[4156]: 0.0.0.0 c012 02 freq_set kernel 6.352 PPM
29 Sep 05:44:21 ntpd[4156]: Ignoring $GPZDG
29 Sep 05:44:21 ntpd[4156]: GPS_NMEA(0) 8024 84 reachable
29 Sep 05:44:21 ntpd[4156]: GPS_NMEA(0) 963a 8a sys_peer
29 Sep 05:44:21 ntpd[4156]: 0.0.0.0 c415 05 clock_sync
29 Sep 05:44:37 ntpd[4156]: 0.0.0.0 0413 03 spike_detect +0.343159 s
29 Sep 05:45:59 ntpd[4156]: ntpd exiting on signal 15
29 Sep 05:46:05 ntpd[4349]: GPS_NMEA(0) serial /dev/gps0 open at 9600 bps
29 Sep 05:46:05 ntpd[4349]: GPS_NMEA(0) 8011 81 mobilize assoc 44843
29 Sep 05:46:05 ntpd[4349]: 0.0.0.0 c016 06 restart
29 Sep 05:46:05 ntpd[4349]: 0.0.0.0 c012 02 freq_set kernel 6.362 PPM
29 Sep 05:46:06 ntpd[4349]: Ignoring $GPZDG
29 Sep 05:46:06 ntpd[4349]: GPS_NMEA(0) 8024 84 reachable
29 Sep 05:46:06 ntpd[4349]: GPS_NMEA(0) 963a 8a sys_peer
29 Sep 05:46:06 ntpd[4349]: 0.0.0.0 c415 05 clock_sync
29 Sep 05:46:22 ntpd[4349]: 0.0.0.0 0413 03 spike_detect +0.342736 s
29 Sep 06:01:18 ntpd[4349]: 0.0.0.0 041c 0c clock_step +0.343077 s
29 Sep 06:01:19 ntpd[4349]: 0.0.0.0 0414 04 freq_mode
29 Sep 06:01:35 ntpd[4349]: GPS_NMEA(0) 8044 84 reachable
29 Sep 06:16:31 ntpd[4349]: 0.0.0.0 c412 02 freq_set kernel 7.652 PPM
29 Sep 06:16:31 ntpd[4349]: 0.0.0.0 c415 05 clock_sync
29 Sep 06:16:31 ntpd[4349]: 0.0.0.0 c41d 0d kern PPS enabled
29 Sep 06:23:30 ntpd[4349]: ntpd exiting on signal 15
29 Sep 06:23:38 ntpd[1207]: GPS_NMEA(0) serial /dev/gps0 open at 9600 bps
29 Sep 06:23:38 ntpd[1207]: GPS_NMEA(0) 8011 81 mobilize assoc 43477
29 Sep 06:23:38 ntpd[1207]: 0.0.0.0 c016 06 restart
29 Sep 06:23:38 ntpd[1207]: 0.0.0.0 c012 02 freq_set kernel 6.374 PPM
29 Sep 06:23:38 ntpd[1207]: Ignoring $GPZDG
29 Sep 06:23:39 ntpd[1207]: GPS_NMEA(0) 8024 84 reachable
29 Sep 06:23:39 ntpd[1207]: GPS_NMEA(0) 963a 8a sys_peer
29 Sep 06:23:39 ntpd[1207]: 0.0.0.0 c41c 0c clock_step -0.331462 s
29 Sep 06:23:38 ntpd[1207]: 0.0.0.0 c414 04 freq_mode
29 Sep 06:23:54 ntpd[1207]: GPS_NMEA(0) 8044 84 reachable
29 Sep 06:38:50 ntpd[1207]: 0.0.0.0 c412 02 freq_set kernel 11.024 PPM
29 Sep 06:38:50 ntpd[1207]: 0.0.0.0 c415 05 clock_sync
29 Sep 06:39:06 ntpd[1207]: 0.0.0.0 0413 03 spike_detect +0.332441 s
29 Sep 06:54:02 ntpd[1207]: 0.0.0.0 041c 0c clock_step +0.329233 s
29 Sep 06:54:03 ntpd[1207]: 0.0.0.0 0415 05 clock_sync
29 Sep 06:54:03 ntpd[1207]: 0.0.0.0 041d 0d kern PPS enabled
29 Sep 06:54:19 ntpd[1207]: GPS_NMEA(0) 8014 84 reachable
29 Sep 08:36:22 ntpd[1207]: ntpd exiting on signal 15
29 Sep 08:36:48 ntpd[15231]: GPS_NMEA(0) serial /dev/gps0 open at 9600 bps
29 Sep 08:36:48 ntpd[15231]: GPS_NMEA(0) 8011 81 mobilize assoc 5145
29 Sep 08:36:48 ntpd[15231]: 0.0.0.0 c016 06 restart
29 Sep 08:36:48 ntpd[15231]: 0.0.0.0 c012 02 freq_set kernel 6.106 PPM
29 Sep 08:36:49 ntpd[15231]: Ignoring $GPZDG
29 Sep 08:36:49 ntpd[15231]: GPS_NMEA(0) 8024 84 reachable
29 Sep 08:36:49 ntpd[15231]: GPS_NMEA(0) 963a 8a sys_peer
29 Sep 08:36:49 ntpd[15231]: 0.0.0.0 c41c 0c clock_step -0.396902 s
29 Sep 08:36:49 ntpd[15231]: 0.0.0.0 c414 04 freq_mode
29 Sep 08:37:05 ntpd[15231]: GPS_NMEA(0) 8044 84 reachable
29 Sep 08:52:01 ntpd[15231]: 0.0.0.0 c412 02 freq_set kernel 9.732 PPM
29 Sep 08:52:01 ntpd[15231]: 0.0.0.0 c415 05 clock_sync
29 Sep 08:52:17 ntpd[15231]: 0.0.0.0 0413 03 spike_detect +0.398091 s
29 Sep 09:07:13 ntpd[15231]: 0.0.0.0 041c 0c clock_step +0.395956 s
29 Sep 09:07:13 ntpd[15231]: 0.0.0.0 0415 05 clock_sync
29 Sep 09:07:13 ntpd[15231]: 0.0.0.0 041d 0d kern PPS enabled
29 Sep 09:07:29 ntpd[15231]: GPS_NMEA(0) 8014 84 reachable
29 Sep 11:25:32 ntpd[15231]: ntpd exiting on signal 15
29 Sep 11:52:12 ntpd[2295]: GPS_NMEA(0) serial /dev/gps0 open at 9600 bps
29 Sep 11:52:12 ntpd[2295]: GPS_NMEA(0) 8011 81 mobilize assoc 4400
29 Sep 11:52:12 ntpd[2295]: 0.0.0.0 c016 06 restart
29 Sep 11:52:12 ntpd[2295]: 0.0.0.0 c012 02 freq_set kernel 6.132 PPM
29 Sep 11:52:13 ntpd[2295]: Ignoring $GPZDG
29 Sep 11:52:13 ntpd[2295]: GPS_NMEA(0) 8024 84 reachable
29 Sep 11:52:13 ntpd[2295]: GPS_NMEA(0) 963a 8a sys_peer
29 Sep 11:52:13 ntpd[2295]: 0.0.0.0 c41c 0c clock_step -0.348255 s
29 Sep 11:52:13 ntpd[2295]: 0.0.0.0 c414 04 freq_mode
29 Sep 11:52:29 ntpd[2295]: GPS_NMEA(0) 8044 84 reachable
29 Sep 12:07:25 ntpd[2295]: 0.0.0.0 c412 02 freq_set kernel 13.034 PPM
29 Sep 12:07:25 ntpd[2295]: 0.0.0.0 c415 05 clock_sync
29 Sep 12:07:41 ntpd[2295]: 0.0.0.0 0413 03 spike_detect +0.349336 s
29 Sep 12:22:37 ntpd[2295]: 0.0.0.0 041c 0c clock_step +0.344266 s
29 Sep 12:22:37 ntpd[2295]: 0.0.0.0 0415 05 clock_sync
29 Sep 12:22:37 ntpd[2295]: 0.0.0.0 041d 0d kern PPS enabled
2

Re: [ntp:questions] NMEA driver using common PPSAPI code

[Venu Gopal]

Hello Dave,

All the timeservers in my setup are using GPS instead of UTC.
And as I can see this happens with NTP version using common PPSAPI code.
Whereas the earlier versions are working fine. I know its a typical setup
using
GPS time instead of UTC. But then if there was a problem w.r.t the
difference between GPS and UTC then it should happen in the earlier versions
too.

I'll spend some more time debugging this and let you know.

Thanks & Kind Regards,
_Venu

On Thu, Sep 23, 2010 at 11:18 PM, Dave Hart  wrote:

> On Thu, Sep 23, 2010 at 4:30 PM, Dave Hart  wrote:
> > 14 seconds is the difference between UTC and GPS time.
>
> Actually the difference is 15 seconds now, sorry for the confusion.
> Still, I expect that is the root cause of the steps you are seeing
> with refclock_nmea using GPS time.
>
> Cheers,
> Dave Hart
>
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

[ntp:questions] NMEA driver using common PPSAPI code

[Venu Gopal]

Dear Friends,

NMEA driver was modified to use common PPSAPI code since 4.2.5p185.
I see  that NTP exhibits a strange behavior stepping the clock by +/- 7 secs
and sometimes +/- 14 secs when restarted. This isn't the case with the
earlier
versions where the reference clock driver was not using common PPSAPI code.

Let me know if anyone had a similar experience.

Snippets of the ntp.log for reference:

23 Sep 06:28:26 ntpd[26548]: refclock_nmea: serial /dev/gps0 open at 9600
bps
23 Sep 06:28:26 ntpd[26548]: GPS_NMEA(0) 8011 81 mobilize assoc 45269
23 Sep 06:28:26 ntpd[26548]: 0.0.0.0 c016 06 restart
23 Sep 06:28:26 ntpd[26548]: 0.0.0.0 c012 02 freq_set kernel 42.388 PPM
23 Sep 06:28:27 ntpd[26548]: GPS_NMEA(0) using only $GPZDG
23 Sep 06:28:27 ntpd[26548]: GPS_NMEA(0) 8024 84 reachable
23 Sep 06:28:27 ntpd[26548]: GPS_NMEA(0) 963a 8a sys_peer
*23 Sep 06:28:27 ntpd[26548]: 0.0.0.0 c41c 0c clock_step -7.201275 s*
23 Sep 06:28:20 ntpd[26548]: 0.0.0.0 c415 05 clock_sync
23 Sep 06:28:36 ntpd[26548]: GPS_NMEA(0) 8044 84 reachable
*23 Sep 06:28:36 ntpd[26548]: 0.0.0.0 c413 03 spike_detect +7.119944 s*
23 Sep 06:33:07 ntpd[26548]: ntpd exiting on signal 15
23 Sep 06:33:11 ntpd[27041]: refclock_nmea: serial /dev/gps0 open at 9600
bps
23 Sep 06:33:11 ntpd[27041]: GPS_NMEA(0) 8011 81 mobilize assoc 795
23 Sep 06:33:11 ntpd[27041]: 0.0.0.0 c016 06 restart
23 Sep 06:33:11 ntpd[27041]: 0.0.0.0 c012 02 freq_set kernel 42.388 PPM
23 Sep 06:33:12 ntpd[27041]: GPS_NMEA(0) using only $GPZDG
23 Sep 06:33:12 ntpd[27041]: GPS_NMEA(0) 8024 84 reachable
23 Sep 06:33:12 ntpd[27041]: GPS_NMEA(0) 963a 8a sys_peer
23 Sep 06:33:12 ntpd[27041]: 0.0.0.0 c415 05 clock_sync
*23 Sep 06:33:28 ntpd[27041]: 0.0.0.0 0413 03 spike_detect +0.201292 s*
*23 Sep 06:48:24 ntpd[27041]: 0.0.0.0 041c 0c clock_step +0.200150 s*
23 Sep 06:48:24 ntpd[27041]: 0.0.0.0 0415 05 clock_sync
23 Sep 06:48:24 ntpd[27041]: 0.0.0.0 041d 0d kern PPS enabled
23 Sep 06:48:40 ntpd[27041]: GPS_NMEA(0) 8044 84 reachable
23 Sep 06:54:39 ntpd[27041]: ntpd exiting on signal 15
23 Sep 06:54:45 ntpd[29180]: refclock_nmea: serial /dev/gps0 open at 9600
bps
23 Sep 06:54:45 ntpd[29180]: GPS_NMEA(0) 8011 81 mobilize assoc 22732
23 Sep 06:54:45 ntpd[29180]: 0.0.0.0 c016 06 restart
23 Sep 06:54:45 ntpd[29180]: 0.0.0.0 c012 02 freq_set kernel 42.388 PPM
23 Sep 06:54:46 ntpd[29180]: GPS_NMEA(0) using only $GPZDG
23 Sep 06:54:46 ntpd[29180]: GPS_NMEA(0) 8024 84 reachable
23 Sep 06:54:46 ntpd[29180]: GPS_NMEA(0) 963a 8a sys_peer
*23 Sep 06:54:46 ntpd[29180]: 0.0.0.0 c41c 0c clock_step -0.194161 s*
23 Sep 06:54:46 ntpd[29180]: 0.0.0.0 c415 05 clock_sync
23 Sep 06:55:02 ntpd[29180]: GPS_NMEA(0) 8044 84 reachable
*23 Sep 06:55:02 ntpd[29180]: 0.0.0.0 c413 03 spike_detect +7.119955 s*
23 Sep 07:01:55 ntpd[29180]: ntpd exiting on signal 15
23 Sep 07:02:01 ntpd[29924]: refclock_nmea: serial /dev/gps0 open at 9600
bps
23 Sep 07:02:01 ntpd[29924]: GPS_NMEA(0) 8011 81 mobilize assoc 48993
23 Sep 07:02:01 ntpd[29924]: 0.0.0.0 c016 06 restart
23 Sep 07:02:01 ntpd[29924]: 0.0.0.0 c012 02 freq_set kernel 42.388 PPM
23 Sep 07:02:02 ntpd[29924]: GPS_NMEA(0) using only $GPZDG
23 Sep 07:02:02 ntpd[29924]: GPS_NMEA(0) 8024 84 reachable
23 Sep 07:02:02 ntpd[29924]: GPS_NMEA(0) 963a 8a sys_peer
*23 Sep 07:02:02 ntpd[29924]: 0.0.0.0 c41c 0c clock_step +7.120941 s*
23 Sep 07:02:09 ntpd[29924]: 0.0.0.0 c415 05 clock_sync
23 Sep 07:02:25 ntpd[29924]: GPS_NMEA(0) 8044 84 reachable
23 Sep 07:02:41 ntpd[29924]: 0.0.0.0 041d 0d kern PPS enabled
*23 Sep 09:36:50 ntpd[29924]: 0.0.0.0 0413 03 spike_detect -0.134541 s*
23 Sep 09:37:06 ntpd[29924]: 0.0.0.0 0415 05 clock_sync
23 Sep 11:15:56 ntpd[29924]: ntpd exiting on signal 15
23 Sep 11:32:32 ntpd[24273]: refclock_nmea: serial /dev/gps0 open at 9600
bps
23 Sep 11:32:32 ntpd[24273]: GPS_NMEA(0) 8011 81 mobilize assoc 30790
23 Sep 11:32:32 ntpd[24273]: 0.0.0.0 c016 06 restart
23 Sep 11:32:32 ntpd[24273]: 0.0.0.0 c012 02 freq_set kernel 42.745 PPM
23 Sep 11:32:33 ntpd[24273]: GPS_NMEA(0) using only $GPZDG
23 Sep 11:32:33 ntpd[24273]: GPS_NMEA(0) 8024 84 reachable
23 Sep 11:32:33 ntpd[24273]: GPS_NMEA(0) 963a 8a sys_peer
*23 Sep 11:32:33 ntpd[24273]: 0.0.0.0 c41c 0c clock_step -7.223907 s*
23 Sep 11:32:26 ntpd[24273]: 0.0.0.0 c415 05 clock_sync
23 Sep 11:32:36 ntpd[24273]: ntpd exiting on signal 15
23 Sep 11:32:37 ntpd[24297]: refclock_nmea: serial /dev/gps0 open at 9600
bps
23 Sep 11:32:37 ntpd[24297]: GPS_NMEA(0) 8011 81 mobilize assoc 51204
23 Sep 11:32:37 ntpd[24297]: 0.0.0.0 c016 06 restart
23 Sep 11:32:37 ntpd[24297]: 0.0.0.0 c012 02 freq_set kernel 42.745 PPM
23 Sep 11:32:37 ntpd[24297]: GPS_NMEA(0) using only $GPZDG
23 Sep 11:32:38 ntpd[24297]: GPS_NMEA(0) 8024 84 reachable
23 Sep 11:32:38 ntpd[24297]: GPS_NMEA(0) 963a 8a sys_peer
*23 Sep 11:32:38 ntpd[24297]: 0.0.0.0 c41c 0c clock_step +7.119892 s*
23 Sep 11:32:45 ntpd[24297]: 0.0.0.0 c415 05 clock_sync
23 Sep 11:33:01 ntpd[24297]: GPS_NMEA(0) 8044 84 reachable
23 Sep 11:33:03 ntpd[24297]: ntpd exiting on signal 

[ntp:questions] Performance with latest LinuxPPS patches

[Venu Gopal]

Dear Folks,

I've been testing NTP (4.2.6p2) with latest Linux kernel having LinuxPPS
patches.
Recent updates from LinuxPPS group implemented support for kernel PPS
consumer.
Ref: http://ml.enneenne.com/pipermail/linuxpps/2010-August/003930.html

I see the ntp log saying "ntpd[PID] : 0.0.0.0 04fd 0d kern PPS no signal".
Same message appears in both the kernel versions i.e. 2.6.35 and
2.6.33.7-rt29

What could be the reason(s) for this and how to fix it up ?

Thanks & Kind Regards,
Venu
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

[ntp:questions] Issues with Linux 2.6.x and LinuxPPS

[Venu Gopal]

Dear Friends,

I would like to know about any specific configuration settings needed for
latest Linux kernels.

I am using Linux-2.6.35-2 with ntp-4.2.6p2. Following are the observations:

1. It takes a couple of hours for time to settle down to few usec.
2. Once the offset settles to few usec I restarted NTPD out of curiosity and
hoping it'll
take less time to settle now. But it doesn't happen and takes another couple
of hours.

I've never seen such behavior with Linux-2.4.x and PPSKit setup.

Am I missing something here? I've seen a similar query in the mailing list.
I've disabled ACPI for processor, selected 100Hz (CONFIG_HZ_100=y)
I expect similar problems might have been experience by many people here
so do share the specific configuration settings.

Regards,
Venu
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

[ntp:questions] NTP precision

[Venu Gopal]

Hi,

At startup NTP syslogs saying precision=1us.
What factors effect this precision and how its computed?

Cheers,
Venu
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] What's the current status of PPS support for Linux 2.6 Kernels?

[Venu Gopal]

Hal Murray wrote:
> and where do I get it?
> 
The current status:
1. LinuxPPS implementation yet to be part of mainstream kernel

2. You can get it from http://ftp.enneenne.com/pub/misc/linuxpps/patches/

3. For more information have a look at 
http://wiki.enneenne.com/index.php/LinuxPPS_support

I have tested it with 2.6.23 and 2.6.26

Cheers,
Venu

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] UTC Time from NMEA receiver one second behind DCF?

[Venu Gopal]

Venu Gopal wrote:
> David J Taylor wrote:
>> Venu Gopal wrote:
>>> David J Taylor wrote:
>>>> Venu Gopal wrote:
>>>>> I have a couple of similar experiences !
>>>>> I observed that the NMEA sentences are not generated in sync with
>>>>> PPS. Theres lot of jitter in these sentences resulting in 1 second
>>>>> offsets. Its fine if the jitter is within few milliseconds. But
>>>>> sometimes it exceeds a second and thats really painful.
>>>>>
>>>>> This observation was discussed earlier and the solution is to go for
>>>>> a better GPS receiver!
>>>> Use the shortest GPS sentences, and the highest baud rate, to keep
>>>> the total message time as short as possible.
>>>>
>>> The issue is not with the length of the messages and the baud rate.
>>>
>>> Venu
>>
>> Well, I found that if you had a bad configuration (sentences too long 
>> or baud rate too low), the sentences could exceed one second, and 
>> therefore be useless for NTP.
>>
>> However, I have not made any measurements showing jitter versus 
>> sentence length, so I would appreciate any pointers to measurements 
>> you have made or know about.
>>
>> Cheers,
>> David
>>
> I almost scratched my head for a week on this issue.
> I tested with multiple sentences, single sentences with baud rate of 
> 4800 and 9600. Ultimately I understood that the problem is not with the 
> sentence length and baud rate. The problem is with the scheduling 
> process/techniques used within the receiver that generate the sentences.
> 
> For example, we use Accord GPS clock which generates GPGGA, GPGLL, 
> GPZDA, GPZGD(custom sentence). Only GPZDA and GPZDG are generated in 
> sync with PPS and the rest are unusable as they result in 1 second offset.
> 
> I also had a chance to experiment with u-blox GPS receiver. Tried all
> possible combinations but the problem occurred frequently. It was worse 
> than Accord.
> 
> I modified the NMEA driver to log the sentences(all of them) with 
> timestamps. Then wrote scripts/programs to parse these huge logs to 
> check for time offsets. It was decided not to use it with NTP.
'it' here means "u-blox" receiver!
> 
> In fact I had few ideas to solve this problem. But at the end of the day 
>the problem seemed difficult to solve.
> 
> Venu

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] UTC Time from NMEA receiver one second behind DCF?

[Venu Gopal]

David J Taylor wrote:
> Venu Gopal wrote:
>> David J Taylor wrote:
>>> Venu Gopal wrote:
>>>> I have a couple of similar experiences !
>>>> I observed that the NMEA sentences are not generated in sync with
>>>> PPS. Theres lot of jitter in these sentences resulting in 1 second
>>>> offsets. Its fine if the jitter is within few milliseconds. But
>>>> sometimes it exceeds a second and thats really painful.
>>>>
>>>> This observation was discussed earlier and the solution is to go for
>>>> a better GPS receiver!
>>> Use the shortest GPS sentences, and the highest baud rate, to keep
>>> the total message time as short as possible.
>>>
>> The issue is not with the length of the messages and the baud rate.
>>
>> Venu
> 
> Well, I found that if you had a bad configuration (sentences too long or 
> baud rate too low), the sentences could exceed one second, and therefore 
> be useless for NTP.
> 
> However, I have not made any measurements showing jitter versus sentence 
> length, so I would appreciate any pointers to measurements you have made 
> or know about.
> 
> Cheers,
> David 
> 
> 
I almost scratched my head for a week on this issue.
I tested with multiple sentences, single sentences with baud rate of 
4800 and 9600. Ultimately I understood that the problem is not with the 
sentence length and baud rate. The problem is with the scheduling 
process/techniques used within the receiver that generate the sentences.

For example, we use Accord GPS clock which generates GPGGA, GPGLL, 
GPZDA, GPZGD(custom sentence). Only GPZDA and GPZDG are generated in 
sync with PPS and the rest are unusable as they result in 1 second offset.

I also had a chance to experiment with u-blox GPS receiver. Tried all
possible combinations but the problem occurred frequently. It was worse 
than Accord.

I modified the NMEA driver to log the sentences(all of them) with 
timestamps. Then wrote scripts/programs to parse these huge logs to 
check for time offsets. It was decided not to use it with NTP.

In fact I had few ideas to solve this problem. But at the end of the day 
the problem seemed difficult to solve.

Venu

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] UTC Time from NMEA receiver one second behind DCF?

[Venu Gopal]

David J Taylor wrote:
> Venu Gopal wrote:
>> I have a couple of similar experiences !
>> I observed that the NMEA sentences are not generated in sync with PPS.
>> Theres lot of jitter in these sentences resulting in 1 second offsets.
>> Its fine if the jitter is within few milliseconds. But sometimes it
>> exceeds a second and thats really painful.
>>
>> This observation was discussed earlier and the solution is to go for
>> a better GPS receiver!
> 
> Use the shortest GPS sentences, and the highest baud rate, to keep the 
> total message time as short as possible.
> 
The issue is not with the length of the messages and the baud rate.

Venu

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] UTC Time from NMEA receiver one second behind DCF?

[Venu Gopal]

I have a couple of similar experiences !
I observed that the NMEA sentences are not generated in sync with PPS.
Theres lot of jitter in these sentences resulting in 1 second offsets.
Its fine if the jitter is within few milliseconds. But sometimes it 
exceeds a second and thats really painful.

This observation was discussed earlier and the solution is to go for
a better GPS receiver!

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Significant clock skew in cluster environment

[Venu Gopal]

Hi friend,

Have a look at these :

http://support.ntp.org/bin/view/Support/KnownHardwareIssues
http://support.ntp.org/bin/view/Support/KnownOsIssues


Venu

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

[ntp:questions] NMEA Jitter

[Venu Gopal]

Hi all,

Its time that I stop scratching my head with this issue :-D  

I have been working with ublox-Antaris Evalkit (borrowed from a friend).
This GPS receiver spits NMEA sentences, UBX (ublox binary messages)
and gives PPS. Very good...so configured NTP with NMEA driver. At times
it is observed that a shift of -1 second appears and continues for a day 
or more
before it comes back to proper time.

It is important that these GPS receivers generate NMEA sentences (at 
least one)
in sync with the PPS which makes them usable.

Comments and similar experiences ?

Venu

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

[ntp:questions] ublox ANTARIS EvalKit

[Venu Gopal]

Hi,

The ublox Antaris Evalkit provides RS-232 and USB interface
with NMEA and ublox messages.

Did any one used the USB interface with NTP ?

Venu

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

[ntp:questions] NMEA refclock users

[Venu Gopal]

Hi all,

1.We need guys using NMEA refclock driver to register at :
http://support.ntp.org/bin/view/Support/NMEARefclockUsers

and related links :
http://support.ntp.org/bin/view/Support/ConfiguringNMEARefclocks

2.Recently certain patches have been submitted for this driver.
And we need guys who can test them and provide valuable feedback.

Venu.

Venu Gopal wrote:
> Hi all,
> 
> I have been working on BUG#399 since few days.
> (https://support.ntp.org/bugs/show_bug.cgi?id=399)
> 
> I have submitted the patch and need someone to test it.
> 
> 
> Venu

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] ntpd oddness

[Venu Gopal]

Hi all,

'tzselect' is available in Debian, Slackware and in RedHat.
We can use this to set the timezone.

Venu

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] ntpd oddness

[Venu Gopal]

Hi all,

My reply was specific to RedHat Linux.
Its there in RedHat releases since 8.0, so I presumed that
it would be there in RedHat Enterprise-4.0.

It is used to change the system timezone (if you want to do so).
If some one can post a method thats common to Linux distributions,
it would be grateful !

Venu


John Oliver wrote:
> On Wed, 02 Apr 2008 19:21:13 +0530, Venu Gopal wrote:
>> Hi John,
>>
>> To alter the localtime zone in Linux, use tzconfig.
> 
> There is no "tzconfig" in Red Hat 4.
> 

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] ntpd oddness

[Venu Gopal]

Hi John,

To alter the localtime zone in Linux, use tzconfig.
Till RedHat-7.3 the timezone was modified using 'setup' or
'timeconfig' utility. But since RedHat-8.0 and subsequent versions
'tzconfig' is used. I remember I've done this once.

Venu

John Oliver wrote:
> I'm having a small issue with ntp-4.2.0.a.20040617-6.el4 running under
> Red Hat Enterprise Linux 4 update 5.
> 
> In the Kickstart script to configure the server, I specify:
> 
> timezone --utc GMT/London
> 
> After the installation is done:
> 
> [EMAIL PROTECTED] ~]$ date
> Tue Apr  1 17:03:23 EDT 2008
> 
> /etc/localtime is a real file:
> 
> [EMAIL PROTECTED] ~]$ ls -l /etc/localtime
> -rw-r--r--  1 root root 1267 Jan 31  2007 /etc/localtime
> 
> If I remove that file and replace it with a symlink:
> 
> [EMAIL PROTECTED] ~]$ ls -l /etc/localtime
> lrwxrwxrwx  1 root root 23 Apr  1 21:04 /etc/localtime ->
> /usr/share/zoneinfo/GMT
> 
> The system clock displays correctly:
> 
> [EMAIL PROTECTED] ~]$ date
> Tue Apr  1 21:05:09 GMT 2008
> 
> But, now, the hwclock is always 12 hours off:
> 
> [EMAIL PROTECTED] ~]$ /sbin/hwclock
> Tue 01 Apr 2008 09:05:39 PM GMT  -0.323329 seconds
> [EMAIL PROTECTED] ~]$ sudo /sbin/hwclock --systohc
> [EMAIL PROTECTED] ~]$ /sbin/hwclock
> Tue 01 Apr 2008 09:05:52 PM GMT  -0.776568 seconds
> 
> 
> 1) Why is /etc/localtime a file by default instead of a symlink?  Is
> this just some silly Red Hat-ism that has to be avoided?
> 
> 2) Why is my hardware clock 12 hours off from the system clock?
> 

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

[ntp:questions] Patch for BUG#399

[Venu Gopal]

Hi all,

I have been working on BUG#399 (
https://support.ntp.org/bugs/show_bug.cgi?id=399)
A working level patch is submitted at NTP bugzilla.

I have been testing the patch with Accord GPS Clock and a consistent
observation
has been made as shown below (a slice of ntp.log)


28 Mar 23:48:45 ntpd[12199]: kernel time sync status change 2107
28 Mar 23:57:29 ntpd[12199]: kernel time sync error 2307
28 Mar 23:57:46 ntpd[12199]: kernel time sync status change 2107
29 Mar 00:00:00 ntpd[12199]: Arguments to clocktime() : 89, 23, 59, 59, 0,
3415737599, 3408134400, 3221223076
29 Mar 00:00:00 ntpd[12199]: clock GPS_NMEA(0) event 'clk_badtime' (0x06)
29 Mar 00:00:00 ntpd[12199]: peer GPS_NMEA(0) event 'event_peer_clock'
(0x85) status 'reach, conf, sel_sys.peer, 2 events, event_peer_clock'
(0x9625)
29 Mar 00:00:00 ntpd[12199]: refclock_nmea.c:788 : timecode length = 80,
$GPGGA,235959.9,1719.9132,N,07829.5489,E,1,07,01.0,00450.0,M,-071.6
,M,00,*7D

29 Mar 00:00:01 ntpd[12199]: kernel time sync error 2307
29 Mar 00:00:01 ntpd[12199]: clock GPS_NMEA(0) event 'clk_okay' (0x00)
29 Mar 00:00:01 ntpd[12199]: peer GPS_NMEA(0) event 'event_peer_clock'
(0x85) status 'reach, conf, sel_sys.peer, 3 events, event_peer_clock'
(0x9635)
29 Mar 00:00:16 ntpd[12199]: kernel time sync status change 2107
29 Mar 00:02:45 ntpd[12199]: kernel time sync error 2307
29 Mar 00:03:03 ntpd[12199]: kernel time sync status change 2107



At the transition to a new day, when the time rolls from 233539.9 to
00.X,
ntpd reports the event 'clk_badtime' (0x06).

Is this behavior consistent with other GPS receivers ?
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

[ntp:questions] Need someone to test patch for BUG#399

[Venu Gopal]

Hi all,

I have been working on BUG#399 since few days.
(https://support.ntp.org/bugs/show_bug.cgi?id=399)

I have submitted the patch and need someone to test it.


Venu

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] ntpq reports different polling intervall than the sniffed UDP packet

[Venu Gopal]

How did you sniff ?
Are you using tcpdump/ethereal ?

Venu

Toralf Förster wrote:
> Hello,
> 
> I'm wondering why I get from ntpq this output :
> 
> [EMAIL PROTECTED] ~/devel/linux-2.6 $ ntpq -pn
>  remote   refid  st t when poll reach   delay   offset  jit
> ter
> =
> *85.25.144.154   143.93.99.2522 u   84  128  377   29.453   10.241   1.
> 066
> +87.32.12.19 4.176.44.157 2 u   88  128  377   50.6858.234   1.
> 607
> +81.169.180.26   192.53.103.104   2 u4  128  377   31.092   -1.381   1.
> 082
> 
> whereas the field "peer polling intervall" of the sniffed network stream sh
> ows a value of 8 (=56 sec)
> for all packets except packet 3 and 4.
> 
> 

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Disk read hack

[Venu Gopal]

Thanks a lot !

Hal Murray wrote:
> I didn't find a reasonable place to insert it in the wiki so
> I parked it here for now.
> 
> This is a hack that just reads a disk as fast as it can.
> It was very "good" at tickling the lost-interrupt problem
> on an old RH system which was not using DMA on the disks.
> 
>   http://www.megapathdsl.net/~hmurray/hacks/read.c
> 

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Time reset

[Venu Gopal]

Hi Hal,

Can you post the Twiki URL after posting it.

Venu

Hal Murray wrote:
>> So its the DISK I/O thats causing loss of ticks ?
> 
> My first Red Hat system defaulted to no-DMA for IDE disks.  (Yes,
> that was a long time ago.)  With that setup, it was simple to generate
> lots of lost timer interrupts: just keep the disk busy doing reads.
> (Seeks don't count.  Read consecutive sectors.)
> 
> My problem went away when I turned on DMA.
> 
> I have a hack that I originally wrote for measuring disk
> transfer rates.  I'll dust it off and put it on the wiki
> if people think it will be helpful for discussions like this.
> 
> It compiles on Linux.  It should be easy to get it to work on
> other *nix systems.
> 

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Time reset

[Venu Gopal]

Hal Murray wrote:
>> So its the DISK I/O thats causing loss of ticks ?
> 
> My first Red Hat system defaulted to no-DMA for IDE disks.  (Yes,
> that was a long time ago.)  With that setup, it was simple to generate
> lots of lost timer interrupts: just keep the disk busy doing reads.
> (Seeks don't count.  Read consecutive sectors.)
> 
> My problem went away when I turned on DMA.
> 
> I have a hack that I originally wrote for measuring disk
> transfer rates.  I'll dust it off and put it on the wiki
> if people think it will be helpful for discussions like this.
>
Ok Hal. This will be certainly helpful.

> It compiles on Linux.  It should be easy to get it to work on
> other *nix systems.
> 

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Time reset

[Venu Gopal]

Hi Martin,

Thanks for the insight.

I was struggling to convince people here (technically!).
Never knew that its a well know issue that has been
discussed several times in the forum.

Thanks to Harlan for his references.

Venu

Martin Burnicki wrote:
> D.Venu Gopal wrote:
>> David Woolley wrote:
>>> Venu Gopal wrote:
>>>
>>>> Its clear that CPU is heavily loaded which might be leading to loss of
>>>> ticks. Yet to check the DMA status for
>>> CPU loading doesn't cause lost timer interrupts. (More  precisely
>>> overruns.)
>>>
>> So its the DISK I/O thats causing loss of ticks ?
>>
>>>> IDE DISK. I'll be out for about a week, after returning I'll
>>>> give few more stats based on combination of CPU load, Disk I/O
>>>> and Network I/O.
> 
> There have been several examples of drivers which kept interrupts disabled
> for too long, so that timer ticks couldn't get through. In most cases
> (AFAIK) this have been drivers for IDE disks, especially if they didn't use
> DMA. 
> 
> This has happened across several operating systems (I remember Linux,
> Windows, and formerly OS/2), with drivers which had not been designed
> properly. So this depends on a specific version of the OS and a specific
> version of a specific driver. You can not say in general that IDE drivers
> cause lost timer ticks, but they are good candidates.
> 
> Unfortunately the new clock routines in the Linux kernel seem to be causing
> problems sometime. This seems to be due to certain combination of a clock
> module which handles a particulare timer on the mainboard and the
> particular timer the implementation of which may vary by the chipset.
> 
> This is not exactly the same as lost timer ticks, but the results are
> similar, i.e. the clock drift can be so large or changing so much that ntpd
> fails to correct it.
> 
> Martin

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Time reset

[Venu Gopal]

[EMAIL PROTECTED] (Venu Gopal) wrote in 
news:[EMAIL PROTECTED]:

> Hi,
> 
> I need to experiment a bit to give some stats on CPU load
> and DISK I/O when crond tasks are run.
> 
> Venu

Hi all,

To measure the CPU load and DISK I/O I've used "iostat"
while running the crons weekly tasks of updatring the
"whatis" database. Below is the slice of the log :



avg-cpu:  %user   %nice%sys   %idle
  77.000.00   16.007.00

Device:tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
dev3-0  132.50  1032.0068.00   2064136

avg-cpu:  %user   %nice%sys   %idle
  91.000.004.504.50

Device:tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
dev3-0   50.50   296.00  2492.00592   4984

avg-cpu:  %user   %nice%sys   %idle
  82.000.002.00   16.00

Device:tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
dev3-0   43.50   420.00 0.00840  0

avg-cpu:  %user   %nice%sys   %idle
  99.000.001.000.00

Device:tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
dev3-01.00 4.00 4.00  8  8

avg-cpu:  %user   %nice%sys   %idle
  98.000.002.000.00

Device:tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
dev3-0   22.00 0.00  2412.00  0   4824

avg-cpu:  %user   %nice%sys   %idle
  97.500.002.500.00

Device:tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
dev3-01.00 0.00 8.00  0 16

avg-cpu:  %user   %nice%sys   %idle
  98.500.001.500.00

Device:tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
dev3-0   59.50 0.00  3340.00  0   6680

avg-cpu:  %user   %nice%sys   %idle
  98.000.002.000.00

Device:tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
dev3-01.00 0.00 8.00  0 16

avg-cpu:  %user   %nice%sys   %idle
  14.000.001.00   85.00

Device:tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
dev3-04.0036.00 8.00 72 16



Its clear that CPU is heavily loaded which might be 
leading to loss of ticks. Yet to check the DMA status for
IDE DISK. I'll be out for about a week, after returning I'll
give few more stats based on combination of CPU load, Disk I/O
and Network I/O.

Venu

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Time reset

[Venu Gopal]

Hi,

I need to experiment a bit to give some stats on CPU load
and DISK I/O when crond tasks are run.

Venu
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Time reset

[Venu Gopal]

Hi ,

"crond" has only one weekly task of updating "whatis" database.
It is scheduled to run "makewhatis" with path for man pages.

Venu
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Time reset

[Venu Gopal]

Hi Harlan,

After going through the system logs it is found that approximately
at the time when reset occurred (2-3 few minutes back) crond started
its weekly routines. To make sure I ran "run-parts /etc/cron.weekly" and
found that the system time went off by 2 secs then to 4 secs.

So its true that when CPU load is high, kernel might be loosing ticks.
When I repeated the same in other clients the drift was in the order of
few milliseconds. I suppose it has something to do with the amount
of CPU load and disk I/O when crond performs its tasks.

Venu
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Time reset

[Venu Gopal]

Hi Harlan,

Thanks a lot for the references.

Venu
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Time reset

[Venu Gopal]

Hi Harlan,

Its 'HP COMPAQ DX200 MT' running RedHat-9.0 (Linux-2.4.20-8).
The previous machine is a similar one where time reset used to happen at
least
once a day.

I referred to the http://support.ntp.org/Support for troubleshooting pages.
I tried to get the system manuals but its phased out and no documentation
is available at HP/COMPAQ sites. I am trying to find the material supplied
along with the machines.

But is there a way to debug this problem ?
This has been a long standing problem ( almost 2 years ! )

Venu
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

[ntp:questions] Time reset

[venu gopal]

Hi,

We have a time-server with about seven clients over LAN.
Only in one clients it is observed that the time is reset almost daily.
We have replaced the client with a new system. And if not daily but
the time reset has occurred once. Below is the ntp log :

2 Mar 02:33:52 ntpd[1566]: offset -0.33 sec freq 0.245 ppm error
0.20 poll 4
2 Mar 03:33:52 ntpd[1566]: offset 0.10 sec freq 0.267 ppm error
0.17poll 4
2 Mar 04:33:52 ntpd[1566]: offset -0.20 sec freq 0.232 ppm error
0.057544 poll 4
2 Mar 04:37:56 ntpd[1566]: time reset 2.220040 s
2 Mar 04:37:56 ntpd[1566]: synchronisation lost
2 Mar 04:37:56 ntpd[1566]: system event 'event_clock_reset' (0x05) status
'leap_none, sync_unspec, 15 events, event_peer/strat_chg' (0xf4)
2 Mar 04:37:56 ntpd[1566]: system event 'event_peer/strat_chg' (0x04) status
'leap_none, sync_unspec, 15 events, event_clock_reset' (0xf5)
2 Mar 04:37:57 ntpd[1566]: peer 10.10.10.10 event 'event_reach' (0x84)
status 'unreach, conf, 5 events, event_reach' (0x8054)
2 Mar 04:38:46 ntpd[1566]: peer 10.10.10.11 event 'event_reach' (0x84)
status 'unreach, conf, 5 events, event_reach' (0x8054)
2 Mar 04:38:50 ntpd[1566]: peer 10.10.10.12 event 'event_reach' (0x84)
status 'unreach, conf, 7 events, event_reach' (0x8074)
2 Mar 05:33:54 ntpd[1566]: offset -0.000327 sec freq 3.477 ppm error
0.15 poll 4
2 Mar 06:33:54 ntpd[1566]: offset -0.09 sec freq 0.246 ppm error
0.19 poll 4
2 Mar 07:33:54 ntpd[1566]: offset 0.05 sec freq 0.246 ppm error
0.14poll 4

In the third line the ppm error jumped from 0.17 to 0.057544.
Is it something to do with improper clock interrupts due to its misbehavior
?

Venu
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

[ntp:questions] NTP in RTOS

[venu gopal]

Hi,

Are there any known issues in using NTP in RTOS ?

Venu
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] NTP on local network

[venu gopal]

Hi,

As per the ntpq output given, the initial offset is too high (in bold
below).

ntpq> rv 12516
status=9014 reach, conf, 1 event, event_reach,
srcadr=MAIL, srcport=123, dstadr=192.168.4.18, dstport=123, leap=00,
stratum=2, precision=-6, rootdelay=31.250, rootdispersion=10932.175,
refid=DC1, reach=377, unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6,
flash=00 ok, keyid=0, ttl=0, *offset=3604309.724*, delay=0.240,
dispersion=20.390, jitter=11.206,
reftime=cb5bd42e.a7f3e6ed  Tue, Feb 12 2008 11:45:42.656,
org=cb5bd4bb.8004493a  Tue, Feb 12 2008 11:48:03.500,
rec=cb5bc6a7.2da250f8  Tue, Feb 12 2008 10:47:59.178,
xmt=cb5bc6a7.2d8f605a  Tue, Feb 12 2008 10:47:59.177,
filtdelay= 0.290.320.280.330.290.290.34
0.24,
filtoffset= 3604321 3604321 3604312 3604321 3604321 3604321 3604321
3604309,
filtdisp= 15.63   16.60   17.59   18.58   19.57   20.53   21.49
22.45


Before starting 'ntpd' use  'ntpdate' at the clients to nullify this initial
high
offset.

Then I hope it should work.

Venu
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Getting working SiRF Star II GPS +NTPD

[venu gopal]

Hi Askar,

You can interface Sirf star II GSP receiver using NMEA ref.clock driver.
The receiver should support NMEA with GPRMC, GPGGA or GPGLL sentences.

For PPS support you need to have Linux kernel with PPS patch (Nano
Kernel).
Or else you need to have FreeBSD compiled with PPS option.

The configuration is quite simple. You may refer to the following NTP
documents
http://www.cis.udel.edu/~mills/ntp/html/refclock.html
http://www.cis.udel.edu/~mills/ntp/html/drivers/driver20.html

Can you give details of NMEA sentences supported by Sirf GPS receiver.

Venu
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Getting working SiRF Star II GPS +NTPD

[venu gopal]

Hi Askar,

You can interface Sirf star II GSP receiver using NMEA ref.clock driver.
The receiver should support NMEA with GPRMC, GPGGA or GPGGA sentences.

For PPS support you need to have Linux kernel with PPS patch (Nano Kernel).
Or else you need to have FreeBSD compiled with PPS option.

The configuration is quite simple. You may refer to the following NTP
documents

http://www.cis.udel.edu/~mills/ntp/html/refclock.html
http://www.cis.udel.edu/~mills/ntp/html/drivers/driver20.html


Venu
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Using mode byte of NMEA ref.clock driver ?

[venu gopal]

Hi Harlan,

Thanks for the reply.
I have opened the ticket and submitted the patch.
Bug 985 : Modifications to NMEA reference clock driver.

Regards,
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Using mode byte of NMEA ref.clock driver ?

[venu gopal]

Hi Harlan,

What is the procedure for submitting the changes to NTP ?
Let me know the current maintainer of NMEA reference clock driver ?

Venu

> Venu,

> I'd say goferit.

>If somebody creates a config file with incompatible flags you can >either:

>- quietly do what they say
>- noisily do what they say
>- noisily disallow them

>There are other choices, but those seem to me to be the best >choices.
>--
>Harlan Stenn <[EMAIL PROTECTED]>
>http://ntpforum.isc.org   - be a member!
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

[ntp:questions] Using mode byte of NMEA ref.clock driver ?

[venu gopal]

Hi Folks,

I have been posting to the NTP 'questions mailing' list regarding
modification of
NMEA refclock driver. The current driver implementation supports 4800
baudrate,
GPGGA, GPGLL and GPRMC sentences.

We are using Accord's GPS Clock which generates NMEA sentences at 9600B.
It also generates 1PPS and a custom NMEA sentence with GPS time-stamp.

I've done few modifications to interface this with NTP.

1.  Support for 4800 and 9600
2.  Parsing of custom NMEA sentence

After going through the NMEA ref.clock driver, it seems that the
original author has choosen values 0(GPXXX), 1(GPRMC), 2(GPGGA) and
4(GPGLL) for mode field so that multiple sentences can be selected. As
posted earlier reg. using the mode byte /field to support Accord GPS
Clock, fourth bit cannot be used to denote the baudrate.

Fourth bit can denote GPZDG(8) (custom NMEA format) while the fifth
bit can be used for baudrate 0(4800) and 1(9600). But in this case
multiple sentences may be allowed only if the value of last four bits
is less than 8, because GPZDG gives GPS time and not UTC like rest of
them. So if GPZDG is selected, others sentences should not be
selected.

I need comments and suggestions from folks who have been maintaining
reference clock drivers regarding the suggested changes and its implications
if any.

Venu
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Using mode byte for Accord GPS Clock (venu gopal)

[venu gopal]

Hi all,

I need comments from folks who have been maintining reference clk
drivers reg. using extra bits of the mode field to accomodate support
for Accord GPS Clock. Please see the pervious posting on the same
topic.

As Dave Sir has suggested we need to have some agreement reg. this so
that I can proceed to sumbit the modified NMEA driver for approval.

Venu

On 12/5/07, venu gopal <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> After going through the NMEA ref.clock driver, it seems that the
> original author has choosen values 0(GPXXX), 1(GPRMC), 2(GPGGA) and
> 4(GPGLL) for mode field so that multiple sentences can be selected. As
> posted earlier reg. using the mode byte/field to support Accord GPS
> Clock, fourth bit cannot be used to denote the baudrate.
>
> Fourth bit can denote GPZDG(8) (custom NMEA format) while the fifth
> bit can be used for baudrate 0(4800) and 1(9600). But in this case
> multiple sentences may be allowed only if the value of last four bits
> is less than 8, because GPZDG gives GPS time and not UTC like rest of
> them. So if GPZDG is selected, others sentences should not be
> selected.
>
> Venu
>
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Using mode byte for Accord GPS Clock (venu gopal)

[venu gopal]

Hi all,

After going through the NMEA ref.clock driver, it seems that the
original author has choosen values 0(GPXXX), 1(GPRMC), 2(GPGGA) and
4(GPGLL) for mode field so that multiple sentences can be selected. As
posted earlier reg. using the mode byte/field to support Accord GPS
Clock, fourth bit cannot be used to denote the baudrate.

Fourth bit can denote GPZDG(8) (custom NMEA format) while the fifth
bit can be used for baudrate 0(4800) and 1(9600). But in this case
multiple sentences may be allowed only if the value of last four bits
is less than 8, because GPZDG gives GPS time and not UTC like rest of
them. So if GPZDG is selected, others sentences should not be
selected.

Venu
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Using mode byte for Accord GPS Clock

[venu gopal]

Hi all,
I am sorry, the mode field and corresponding configuration should be
as follows to preserve the existing NMEA sentences in the driver.

Mode value 8  => 9600, GPXXX
Mode value 9  => 9600, GPRMC
Mode value 10 => 9600, GPGGA
Mode value 11 => 9600, GPZDG (Accord custom NMEA sentence)
Mode value 12 => 9600, GPGLL
Mode value 13 => 9600, GPZDA

Venu.


On 12/4/07, venu gopal <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> The 'mode' field a.k.a 'ttl' for NMEA reference driver is used
> to select the NMEA
> sentence. I cannot use the unused fudge flags 'flag1' and 'flag4'
> as they are unavailable
> before the serial port is opened. Somehow I have to select both
> the baudrate and the
> NMEA sentence from the 'mode' field itself.
>
> Currently 'mode' field with values 0,1,2,4 are used in NMEA
> reference driver with default
> baudrate of 4800. Can I use the 'mode' field with value 8 and the
> rest of the three bits to
> select NMEA sentence.
>
> 1. Mode value 8  => 9600, GPXXX
> 2. Mode value 9  => 9600, GPRMC
> 3. Mode value 10 => 9600, GPGGA
> 4. Mode value 11  => 9600, GPGLL
> 5. Mode value 12 => 9600, GPZDG (Accord custom NMEA sentence)
> 6. Mode value 13 => 9600, GPZDA
>
> So the 4th bit of the 'mode' field is used to check if baudrate
> needs to be changed,
> while the rest of the 3 bits denote the NMEA sentence to be selected.
>
>Comments plz...
>
> Venu.
>
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Issues with ACCORD Reference Clock Driver

[venu gopal]

Hi Hal,
 The custom NMEA format has GPS time unlike standard NMEA which give
UTC. And the baudrate cannot be changed to 4800, it only works at 9600.
Things are not as simple as we think and we need to work to make things simple
I am looking for people who can help me in doing this.

The binary format is just an add on to NMEA and it need not be supported but
is would be nice if it did as an extra feature. Thats all.

Venu
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

[ntp:questions] Using mode byte for Accord GPS Clock

[venu gopal]

Hi all,

The 'mode' field a.k.a 'ttl' for NMEA reference driver is used
to select the NMEA
sentence. I cannot use the unused fudge flags 'flag1' and 'flag4'
as they are unavailable
before the serial port is opened. Somehow I have to select both
the baudrate and the
NMEA sentence from the 'mode' field itself.

Currently 'mode' field with values 0,1,2,4 are used in NMEA
reference driver with default
baudrate of 4800. Can I use the 'mode' field with value 8 and the
rest of the three bits to
select NMEA sentence.

1. Mode value 8  => 9600, GPXXX
2. Mode value 9  => 9600, GPRMC
3. Mode value 10 => 9600, GPGGA
4. Mode value 11  => 9600, GPGLL
5. Mode value 12 => 9600, GPZDG (Accord custom NMEA sentence)
6. Mode value 13 => 9600, GPZDA

So the 4th bit of the 'mode' field is used to check if baudrate
needs to be changed,
while the rest of the 3 bits denote the NMEA sentence to be selected.

   Comments plz...

Venu.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Reg comments on ACCORD Reference Clock Driver (Harlan Stenn)

[venu gopal]

Hi Harlan,
Yes. I am volunteering to be the maintainer of the code.
Infact I'll be more than happy to do this. I have been a fan of
open-source community
since about six years. I always wanted to be part of a project and
contribute back to
this community. I hope this is my chance. I have few projects in
the pipeline but not
related to NTP.

Infact we have Accord GPS Clocks in considerable number and we use
NTP extensively.
So it would be easy for me to maintain and test the code at my work place.

I am going through the various parts of the code, so i'll take
sometime to add proper
support to use Accord GPS using the 'mode' and 'flag1' or 'flag4'
since both of them are
not being used by current NMEA driver.

Venu.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

[ntp:questions] Reg comments on ACCORD Reference Clock Driver

[venu gopal]

Hi Jason and Harlan,

I'll try to accomodate the changes for supporting the Accord
GPS Clock in the NMEA
driver itself. I shall test it in the production environment and
let you know.

Let me know the procedure to submit the code changes to the NTP code base.

Venu
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Issues with ACCORD Reference Clock Driver

[venu gopal]

Hi Jason,
I agree with you to some extent(#1, #2).
I am trying to accomodate the changes in the NMEA driver itself.

Binary format was designed to send GPS time and position data to
another PCI card.
I cannot tell you the whole story but the binary format has GPS
time, sync status and
position. Unfortunately the time message doesnt contain sync
status !  Hence both the
messages need to be checked.

 Currently I'm out of station and busy. I shall post the details
of the format very soon.

Accord is the only Indian company manufacturing GPS Clocks. It may
not be as popular
as Garmin or TrueTime in the international market. But we are
using them and they work
fine too.

Venu.


On 12/2/07, Jason Rabel <[EMAIL PROTECTED]> wrote:
> > As per your suggestion I would have used the existing NMEA
> > reference clock driver
> > for Accord GPS Clock. But there are certain issues as listed below.
> >
> >  1. Accord GPS Clock spits out NMEA at 9600 baudrate
> >  2. It has custom NMEA format for GPS (and the driver is
> > intended to use this )
> >  3. It also spits out time and status messages in a proprietary
> > binary format (not yet tested...but wll do )
> >
> >  So instead of changing the clean NMEA driver to support the above,
> >  I still think its better to write and maintain a separate driver.
> >
> >  Comments plz...
>
> #1 above would require changing only 1 line of code from the base NMEA
> driver. I've often wondered why you can't pass the baud rate via the conf
> file. It makes more sense to me to have the software adjust for the GPS,
> rather than having to change the GPS (if possible) to accommodate the
> software.
>
> #2 above, depending on the format, could require as little as only 1 or 2
> lines of code to be changed / added. At the very worst you might have to
> modify the small chunk of code that searches for the time code in the
> string, still a very minor modification.
>
> #3 above - Is there any advantage to using the binary format? Is there any
> information that NTP can use that would justify the additional code?
>
> I've never heard of Accord until you started posting asking questions about
> a driver. Excluding their website, there seems to be no other information on
> the Internet about them (or people using them). I wouldn't exactly call it a
> 'high profile' product.
>
>
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

[ntp:questions] Issues with ACCORD Reference Clock Driver

[venu gopal]

 Hi Harlan Stenn,

As per your suggestion I would have used the existing NMEA
reference clock driver
   for Accord GPS Clock. But there are certain issues as listed below.

   1. Accord GPS Clock spits out NMEA at 9600 baudrate
   2. It has custom NMEA format for GPS (and the driver is
intended to use this )
   3. It also spits out time and status messages in a proprietary
binary format
   (not yet tested...but wll do )

So instead of changing the clean NMEA driver to support the above,
I still think its better
to write and maintain a separate driver.

 Comments plz...
 Venu.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

[ntp:questions] New reference clock driver

[venu gopal]

Hi all,
   The GPS receiver is from an Indian Company ACCORD. It has a custom
NMEA data with GPS time and is validity. It also sends standard NMEA
data including GPGGA, GPGLL with UTC time at 9600 baudrate. It also
generates 1 PPS pulse.

For more information visit http://www.accord-products.com/gpsclock.htm

Since I wanted to sync system to GPS time, I modified NMEA driver to
work with this custom format (for testing). Instead of modifying the
NMEA clock driver, I want to write a new one.

FYI,
Venu
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] questions Digest, Vol 37, Issue 2

[venu gopal]

Hi all,
The GPS receiver is from an Indian Company ACCORD. It has a custom
NMEA data with GPS time and is validity. It also sends standard NMEA
data including GPGGA, GPGLL with UTC time at 9600 baudrate. It also
generates 1 PPS pulse.

For more information visit http://www.accord-products.com/gpsclock.htm

Since I wanted to sync system to GPS time, I modified NMEA driver to
work with this custom format (for testing). Instead of modifying the
NMEA clock driver, I wanted to write a new one.

FYI,
Venu
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

[ntp:questions] New reference clock driver

[venu gopal]

Hi friends,
I would like to develop a new reference clock driver for NTP to support
the GPS receiver which I am using.
Let me know the procedure if any one has done such development.

Regards,
Venu.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions