f



NMEA driver using common PPSAPI code

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 15


Thanks & Kind Regards,
_Venu
0
Venu
9/23/2010 12:11:01 PM
comp.protocols.time.ntp 4895 articles. 2 followers. Post Follow

13 Replies
865 Views

Similar Articles

[PageSpeed] 49

On Thu, Sep 23, 2010 at 4:30 PM, Dave Hart <davehart@gmail.com> 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
0
Dave
9/23/2010 5:48:50 PM
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 <davehart@gmail.com> wrote:

> On Thu, Sep 23, 2010 at 4:30 PM, Dave Hart <davehart@gmail.com> 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
>
0
Venu
9/24/2010 4:44:10 AM
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
29 Sep 12:22:53 ntpd[2295]: GPS_NMEA(0) 8014 84 reachable
29 Sep 22:59:25 ntpd[2295]: 0.0.0.0 0413 03 spike_detect -0.309390 s
29 Sep 22:59:41 ntpd[2295]: 0.0.0.0 0415 05 clock_sync
 1 Oct 03:58:12 ntpd[2295]: ntpd exiting on signal 15
 1 Oct 04:06:20 ntpd[16158]: GPS_NMEA(0) serial /dev/gps0 open at 9600 bps
 1 Oct 04:06:20 ntpd[16158]: GPS_NMEA(0) 8011 81 mobilize assoc 34059
 1 Oct 04:06:20 ntpd[16158]: 0.0.0.0 c016 06 restart
 1 Oct 04:06:20 ntpd[16158]: 0.0.0.0 c012 02 freq_set kernel 6.141 PPM
 1 Oct 04:06:20 ntpd[16158]: Ignoring $GPZDG
 1 Oct 04:06:21 ntpd[16158]: GPS_NMEA(0) 8024 84 reachable
 1 Oct 04:06:21 ntpd[16158]: GPS_NMEA(0) 963a 8a sys_peer
 1 Oct 04:06:21 ntpd[16158]: 0.0.0.0 c41c 0c clock_step -0.317284 s
 1 Oct 04:06:20 ntpd[16158]: 0.0.0.0 c414 04 freq_mode
 1 Oct 04:06:36 ntpd[16158]: GPS_NMEA(0) 8044 84 reachable
 1 Oct 04:12:41 ntpd[16158]: ntpd exiting on signal 15


I am running short of time at office, but will manage to spend time to help
debug this issue.
Let me know your suggestions.

Thanks & Kind Regards,
_Venu
0
Venu
10/1/2010 5:50:32 AM
On Fri, Oct 1, 2010 at 5:50 AM, Venu Gopal <neo.venu@gmail.com> wrote:
> 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:
[...]
> I am running short of time at office, but will manage to spend time to help
> debug this issue.
> Let me know your suggestions.

I don't think you've provided enough information.  I have been
travelling all day and it's bedtime, so perhaps I'm missing something,
but I saw a lot of restarts and a number of +/- 0.3 second steps.
Please provide the ntp.conf, tell us what sentences you have the GPS
sending, and characterize what you see as misbehavior instead of
assuming it will jump out at me.

I hope others will have some insight, too.

Cheers,
Dave Hart
0
Dave
10/1/2010 6:51:01 AM
0.3 seconds (or 0.7 seconds) might be the offset between the
end-of-sentence timestamp and the PPS event.  The NMEA driver in ntpd
now allows fudging the EOL and PPS timestamps separately, so you might
be tripping over the change in interpretation of fudge time1 and fudge
time2 compared to your older configuration.

You might also try disabling kernel discipline and/or kernel PPS to
see how that changes the behavior, too.  I don't have either luxury on
Windows, where I use the NMEA driver, so I may have flubbed something.

Cheers,
Dave Hart
0
Dave
10/1/2010 6:55:11 AM
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
0
Venu
10/1/2010 10:52:55 AM
Venu Gopal wrote:
> 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
> 29 Sep 12:22:53 ntpd[2295]: GPS_NMEA(0) 8014 84 reachable
> 29 Sep 22:59:25 ntpd[2295]: 0.0.0.0 0413 03 spike_detect -0.309390 s
> 29 Sep 22:59:41 ntpd[2295]: 0.0.0.0 0415 05 clock_sync
>  1 Oct 03:58:12 ntpd[2295]: ntpd exiting on signal 15
>  1 Oct 04:06:20 ntpd[16158]: GPS_NMEA(0) serial /dev/gps0 open at 9600 bps
>  1 Oct 04:06:20 ntpd[16158]: GPS_NMEA(0) 8011 81 mobilize assoc 34059
>  1 Oct 04:06:20 ntpd[16158]: 0.0.0.0 c016 06 restart
>  1 Oct 04:06:20 ntpd[16158]: 0.0.0.0 c012 02 freq_set kernel 6.141 PPM
>  1 Oct 04:06:20 ntpd[16158]: Ignoring $GPZDG
>  1 Oct 04:06:21 ntpd[16158]: GPS_NMEA(0) 8024 84 reachable
>  1 Oct 04:06:21 ntpd[16158]: GPS_NMEA(0) 963a 8a sys_peer
>  1 Oct 04:06:21 ntpd[16158]: 0.0.0.0 c41c 0c clock_step -0.317284 s
>  1 Oct 04:06:20 ntpd[16158]: 0.0.0.0 c414 04 freq_mode
>  1 Oct 04:06:36 ntpd[16158]: GPS_NMEA(0) 8044 84 reachable
>  1 Oct 04:12:41 ntpd[16158]: ntpd exiting on signal 15

I had this skipping between NMEA and PPS when I started using 
radioclocks. My method of dealing with the problem was to
fudge around it so once PPS had initialised it didn't go
above the allowed time threshold difference.

I had following two lines in ntp.conf
tos mindist 0.4
fudge 127.127.20.0 time1 0.651 refid GPSb

Fudge value required will vary depending on hardware. Here I
see around +/- 50ms variations in offset for GPS whilst offset
for PPS is usually below 10us.

The most recent ntpd I have here ntp-4.2.6p2 has separate fudge
settings which avoids the problem and also seems to converge more quickly.


David
0
David
10/1/2010 12:21:37 PM
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
0
Venu
10/6/2010 9:42:10 AM
On Wed, Oct 6, 2010 at 09:42 AM, Venu Gopal <neo.venu@gmail.com> 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
0
Dave
10/6/2010 11:49:34 PM
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 <hart@ntp.org> wrote:

> On Wed, Oct 6, 2010 at 09:42 AM, Venu Gopal <neo.venu@gmail.com> 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
>
0
Venu
10/7/2010 4:36:26 AM
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
0
Venu
10/26/2010 8:37:07 AM
On 10/26/2010 1:37 AM, Venu Gopal wrote:
> 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?

On 10/1/2010 3:52 AM, Venu Gopal wrote:
> 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

Do you need to change that to 127.127.20.4 ?

ntp-dev-4.2.7p72 refclock_nmea.c
 * GPS sentences other than RMC (the default) may be enabled by setting
 * the relevent bits of 'mode' in the server configuration line
 * server 127.127.20.x mode X
 *
 * bit 0 - enables RMC (1)
 * bit 1 - enables GGA (2)
 * bit 2 - enables GLL (4)
 * bit 3 - enables ZDA (8) - Standard Time & Date
 * bit 3 - enables ZDG (8) - Accord GPS Clock's custom sentence with GPS time
 *			     very close to standard ZDA
 *
 * Multiple sentences may be selected except when ZDG/ZDA is selected.

-- 
E-Mail Sent to this address <BlackList@Anitech-Systems.com>
  will be added to the BlackLists.
0
E
10/26/2010 7:22:15 PM
T24gVHVlLCBPY3QgMjYsIDIwMTAgYXQgMTk6MjIgVVRDLCBCbGFja0xpc3RzIHdyb3RlOgo+IERv
IHlvdSBuZWVkIHRvIGNoYW5nZSB0aGF0IHRvIDEyNy4xMjcuMjAuNCA/Cj4KPiBudHAtZGV2LTQu
Mi43cDcyIHJlZmNsb2NrX25tZWEuYwo+IMKgKiBHUFMgc2VudGVuY2VzIG90aGVyIHRoYW4gUk1D
ICh0aGUgZGVmYXVsdCkgbWF5IGJlIGVuYWJsZWQgYnkgc2V0dGluZwo+IMKgKiB0aGUgcmVsZXZl
bnQgYml0cyBvZiAnbW9kZScgaW4gdGhlIHNlcnZlciBjb25maWd1cmF0aW9uIGxpbmUKPiDCoCog
c2VydmVyIDEyNy4xMjcuMjAueCBtb2RlIFgKPiDCoCoKPiDCoCogYml0IDAgLSBlbmFibGVzIFJN
QyAoMSkKWy4uLl0KPiDCoCogTXVsdGlwbGUgc2VudGVuY2VzIG1heSBiZSBzZWxlY3RlZCBleGNl
cHQgd2hlbiBaREcvWkRBIGlzIHNlbGVjdGVkLgoKVGhlIHdvcmRpbmcgaXMgbGVzcyB0aGFuIGlk
ZWFsLCBidXQgdGhlICJtb2RlIiBiaXRzIGNvbWUgbm90IGluIHRoZQpmaW5hbCBvY3RldCBvZiB0
aGUgMTI3LjEyNy5kcml2ZXIudW5pdCBhZGRyZXNzLCBidXQgaW4gdGhlIG1vZGUgYnl0ZSwKYXMg
aW4KCnNlcnZlciAxMjcuMTI3LjIwLjAgbW9kZSAxNgoKdG8gb3BlbiBOTUVBIHVuaXQgMCBhdCA5
NjAwYnBzLgoKQ2hlZXJzLApEYXZlIEhhcnQKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KcXVlc3Rpb25zIG1haWxpbmcgbGlzdApxdWVzdGlvbnNAbGlzdHMu
bnRwLm9yZwpodHRwOi8vbGlzdHMubnRwLm9yZy9saXN0aW5mby9xdWVzdGlvbnM=

0
Dave
10/26/2010 7:43:43 PM
Reply:

Similar Artilces:

Using parse driver rather then nmea driver?
Hi All I have a NMEA GPS device that outputs the correct strings. However due to where I have to position the device it doesn't always have a lock on three satellites and then goes into Void mode. However the time values are still being collected (It always sees at least one satellite). Is it possible to write a parse (127,127,8,0) driver to read only the time values and ignore the void message and thereby make it the stratum 0 source? Thanks in advance. >I have a NMEA GPS device that outputs the correct strings. However >due to where I have to position the device it doesn...

NTP NMEA driver
Hello everyone, I have a handful of questions regarding the implementation of the NTP NMEA (and 1PPS) driver. As I'm sure many of you know, these drivers synchronize a local clock using any of a handful of NMEA sentences (ZDA, RMC, GGA, GLL, etc.) received on a serial port and, if present and configured to do so, further synchronizes using a 1 PPS signal. First, it is unclear to me why one would use a time stamp from any sentence other than that provided in the ZDA message. Time stamps in the other messages mark the time of a position fix, also reported in those messages, not the ...

How to load workspace data at run time using code generated with Real Time Workshop
Hello, I want to generate Real Time Workshop code that is independent by workspace data contents. In this way, I don't need to re build the RTW code when I update the workshop data content. Thank's mauro.capoleoni@elv.it (Cartesio) wrote in message news:<e2bf0386.0406010652.176a39d8@posting.google.com>... > Hello, I want to generate Real Time Workshop code that is independent > by workspace data contents. In this way, I don't need to re build the > RTW code when I update the workshop data content. > > Thank's Your is an interesting subject, but I think ...

Re: [ntp:questions] using ntpd to initialise time instead of ntpdate sets wrong time.
----- Original Message Follows ----- > I've got an embedded linux machine whose initial time is 1, Jan, 1970. > When I use ntpdate to set the correct time at boot time it does this > correctly, but when I use ntpd to do this it sets the time backwards > to 1937. The debug shows that the offset is seen as a negative value. > The documentation suggests that ntpd -q can be used as a replacement > for ntpdate. > Try using ntpd -gq since -g will ignore limits. What version of ntpd do you have on this system? Recent versions will set the date correctly (modulo 68 years...

Has anyone already use the Simulink 6.0's newest feature of embedding M code into Real Time code?
The latest version of Simulink, ver. 6.0 just gives the 1st phase of feature that enable the embedding of M codes into the Real Time codes. Has anyone already successfully used it (suceessfully build/compile your model)? I have some problem when compiling the codes... If anyone has experienced this kinda application, please reply to me and then I will show the error messages I met! Thanks a lot for your attention! Claude. Would anyone please give me a reply with your experience? Thanks very much~~ Claude wrote: > > > The latest version of Simulink, ver. 6.0 just gives the 1st ph...

NTP vs BCD vs Unix ('unsinged int' or 'unsigned long int') time format coding: is there a sensible explaination for the differences in coding?
NTP vs BCD vs Unix ('unsigned int' or 'unsigned long int') time format coding: is there a sensible explanation for the differences in coding? I like [raw] Unix Time's lack of ambiguity is best suited for setting the clocks on most computers and as a universal unambiguous binary time and date format, but NTP-64 and NTP-128 are best suited for scientific and business applications (including modern OS file system time stamps). BCD seems to be best suited for consumer devices, for its ease of decoding -- but BCD formats are not as standardized as NTP nor are they as una...

Which To Use
Is Times the standard serif font? I'm deciding which font to use for a book I'm writing. My printer, HP 4ML PostScript, has the resident PostScript font Times Roman (strangely, the bold, italic and bold italic are Times). I recall that PageMaker 5 pushed for using Times. I now have PageMaker 7, and in its font list (the same list that appears in any application) is Times and Times New Roman. Would appreciate your explanation as to how resident printer fonts relate to whatever font I select from the font list (these are usually True Type, although there are other kinds). Also, a recomme...

NTP ( Network Time protocol ) With Ingres
Does somebody use NTP ( ntpdate or xntpd ) with Ingres. Officialy NTP is not compatible with Ingres. Thanks. Bruno. At 11:34 AM 7/18/2003 +0200, Bruno Wipier wrote: >Does somebody use NTP ( ntpdate or xntpd ) with Ingres. Officialy NTP is not >compatible with Ingres. > >Thanks. > >Bruno. Bruno, I guess I'm a bit flustered. Is there some list of UNIX utilities that are or are not "compatible" with Ingres? NTP merely keeps your clock in sync, usually within milliseconds of the 'master'. Is Ingres not compatible with the c...

How to get Region code from protocol driver
Hi Friends, I am working with a protocol driver. From my protocol driver I want to know what is the region code in which the Wireless adapter card work with. I couldn't find out any Standard NDIS supported OID to request Region Code. Is there any standard OID to request Region code ??. If not how can I extract this value from any other request. ??? Please help me ?? Thanks & Regards, Biju CP ...

Network Time Protocol (NTP) for NonStop
Has anyone used ntp on NonStop? HP has ported this for the OSS target. I know Bowden systems sells NSK-NTP, but I am wondering if anyone has used the open-source version. Thanks in advance. NonStopForEver wrote: > Has anyone used ntp on NonStop? HP has ported this for the OSS target. > I know Bowden systems sells NSK-NTP, but I am wondering if anyone has > used the open-source version. > > Thanks in advance. We use a product written by a german guy. It only acts as a client but does the job. If you wany some details then PM me. Hi Mark. Is this the C code that gets...

M$Windows and ntp (and other time protocols)
Looking for timeserv to sync a M$nt4 machine, I found this doucment at MicroSoft: http://www.microsoft.com/windows2000/docs/wintimeserv.doc. It nicely states (official?) details about M$Windows and time sync. Is there a faq or such where this pointer / information can be added? CBee CBee wrote: > Looking for timeserv to sync a M$nt4 machine, I found this doucment at > MicroSoft: http://www.microsoft.com/windows2000/docs/wintimeserv.doc. > It nicely states (official?) details about M$Windows and time sync. > > Is there a faq or such where this pointer / information can be...

I could use some help making this Python code run faster using only Python code.
I am new to Python however I would like some feedback from those who know more about Python than I do at this time. def scrambleLine(line): s = '' for c in line: s += chr(ord(c) | 0x80) return s def descrambleLine(line): s = '' for c in line: s += chr(ord(c) & 0x7f) return s def scrambleFile(fname,action=1): if (path.exists(fname)): try: f = open(fname, "r") toks = fname.split('.') while (len(toks) > 2): toks.pop() fname = '.'.j...

Unable to get time from the internet using NTP
I have to setup a couple of servers that will get their time from the internet. I have following the steps listed at http://www.pool.ntp.org/ The following is the contents of ntp.conf: driftfile /drift/ntp.drift server 0.us.pool.ntp.org server 1.us.pool.ntp.org server 2.us.pool.ntp.org server 3.us.pool.ntp.org When I start NTP, the start up hands with ntpdate trying to get the time from the servers. I have verified that the server names do verify in DNS. Do I need to pick a different set of servers? Any idea/suggestions would be greatly appreciatd. Thanks Dew Wrobel wrote: > I have...

Real Time Protocol
in my pc there is a DB with songs and i want to send/ transmit using RTP real time protocol to different devices so I want send media over RTP/UDP/IP using fpgas On Monday, November 5, 2012 3:55:15 PM UTC-7, Emil Imrith wrote: > in my pc there is a DB with songs and i want to send/ transmit using RTP real time protocol to different devices so I want send media over RTP/UDP/IP using fpgas I have the understanding of the RTP header and I know there so ip libraries for ethernet networking so I want to descript a hardware to transmit my media probably I will need an encoder with...

Web resources about - NMEA driver using common PPSAPI code - comp.protocols.time.ntp

Peter Gregg (racing driver) - Wikipedia, the free encyclopedia
Peter Holden Gregg (May 4, 1940 – December 15, 1980) was a racecar driver during the golden age of the Trans-Am Series and a four-time winner ...

NSW Police accused of targeting poorer drivers by omitting cocaine swab from roadside tests
Why are roadside police not testing for a drug commonly associated with wealth?

NVIDIA releases 361.75 WHQL Game Ready Driver
... new release of Rise of the Tomb Raider and the upcoming Tom Clancy’s The Division beta, NVIDIA has diligently prepared a new game ready driver ...

Lyft, drivers settle labor lawsuit with $12.25M payment, new work agreement
(credit: Lyft ) California drivers who sued Lyft in 2013 over whether they should be treated as employees or contractors have settled their ...

Uber Loses Bid to Pause Drivers Group Lawsuit as Trial Looms
Uber Technologies Inc. lost its bid to freeze a lawsuit bound for trial over California drivers’ demands to be treated as employees while the ...

Lyft just agreed to pay more than $12 million to settle a driver lawsuit — here’s what that means for ...
On Tuesday, Lyft agreed to settle a proposed class-action lawsuit with its drivers in California. Lyft agreed to pay $12.25 million to its drivers ...

Pants-less driver in Detroit dies in wreck watching porn
Michigan State Police say the fatal car crash of Clifford Ray Jones, 58, was the strangest thing they've ever seen

Some Uber, Lyft drivers seek protections
Despite Lyft's decision to settle a suit this week, the issue of reclassifying drivers and workplace protections is far from over.

Lyft pays $12M to settle class action suit with California drivers
The ride-hailing company won't be on the hook to provide drivers with benefits like unemployment and health insurance.

Lyft Will Pay California Drivers Total Of $12.25M, Still Won’t Call Them Employees
The companies operating the two largest ride-hailing fleets, Uber and Lyft, both have lawsuits against them in California where drivers seek ...

Resources last updated: 1/28/2016 11:14:17 PM