Re: [ntp:questions] shared memory driver not working under windows4.2.7p273++ build?
On Wed, Jul 4, 2012 at 12:34 AM, Kennedy, Paul p.kenn...@fugro.com.au wrote: Good morning Sir, I am not sure what this reply indicates. Does it mean the Windows port does not / cannot support shared memory drivers? The comment is a little ambiguous (replaced with what?) CommitLog-4.1.0(5519,45): * ports/winnt/: Replaced with new code (no SHM or PALISADE) I'm not sure as I wasn't involved in ntpd development at the time, but the implication was that there was special support in the Windows port for SHM and PALISADE drivers (perhaps duplicating/replacing the common driver code) which was removed as part of an overhaul of the Windows ntpd port. ntp-dev-4.2.7p270\ports\winnt\include\config.h(348,19):/* # define CLOCK_SHM */ ntp-dev-4.2.7p285\ports\winnt\include\config.h(349,19):/* # define CLOCK_SHM */ These simply indicate that as you noticed, the Windows port currently does not include the SHM driver. However, the code in refclock_shm.c once was portable to Windows, and probably can be made so again without too much effort. You'll need to edit ports\winnt\include\config.h to #define CLOCK_SHM to enable it, then fix any problems compiling the code under Windows. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] shared memory driver not working under windows 4.2.7p273++ build?
E-Mail Sent to this address will be added to the BlackLists wrote: Kennedy, Paul wrote: shared memory driver under windows. CommitLog-4.1.0(5519,45): * ports/winnt/: Replaced with new code (no SHM or PALISADE) ntp-dev-4.2.7p270\ports\winnt\include\config.h(348,19):/* # define CLOCK_SHM */ ntp-dev-4.2.7p285\ports\winnt\include\config.h(349,19):/* # define CLOCK_SHM */ I noticed: http://norloff.org/ntp/shm-test/ SHM test for windows? Yes and no: This is testcode that verified the possibility of handling 100k to 1M shared memory messages per second, without using any kind of OS locking primitives. The key idea is to use a msg array in round robin fashion, each msg aligned and sized so that it uses one or more separate cache lines. It has _not_ been integrated into ntpd, it would require a new sub-mode for the SHM driver. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] questions] Leapsecond on FreeBSD or Windows - no showstopper bugs, but ...
On Tue, Jul 3, 2012 at 06:20 UTC, David J Taylor wrote: Presumably, Dave, if the leap second /had/ been inserted, the second message would not have happened? The would have gone backward 1 times message was triggered by the intentional backward step, which wouldn't have occurred at the time it did if the insertion had slewed as designed. That diagnostic is supposed to be suppressed when ntpd steps the clock, but the evidence suggests imperfection. Clearing an additional variable might be all that's needed. Personally, I would correct the missing insertion, and treat the second message as a warning that /something/ unexpected had happened! I want to preserve the unexpected aspect by not logging that message when the clock is expected to step back. If the leap second /had/ been inserted, then would ntp have been confused in the period before the GPS 18/x started emitting correct seconds? It would quickly notice a 1s offset for the NMEA, which would most likely be suppressed initially as a popcorn spike. Whether the clock would be stepped to follow depends on the mix and agreement of sources. I also wonder why the 1-second step doesn't appear to have been reported in the event log. I wondered the same thing. I saw a step logged on Windows ntpd with GPS 18x LVC: 30 Jun 23:59:59 ntpd[2272]: 0.0.0.0 041b 0b leap_event 1 Jul 00:00:00 ntpd[2272]: Leap second announcement disarmed 1 Jul 00:00:15 ntpd[2272]: 0.0.0.0 0413 03 spike_detect -0.98 s 1 Jul 00:03:45 ntpd[2272]: 2001:4f8:fff7:1::17 962a 8a sys_peer 1 Jul 00:12:29 ntpd[2272]: 0.0.0.0 061c 0c clock_step -1.006282 s (followed by re-initializing interpolation spew normally seen only at startup) You may need to add +sysall or more narrowly +sysevent to logconfig in ntp.conf. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] questions] Leapsecond on FreeBSD or Windows - no showstopper bugs, but ...
Dave Hart wrote in message news:CAMbSiYAqZsDnuNtcyYGn1XU0JBcK4DB3DHUVnsOiJy6hop6w=w...@mail.gmail.com... On Tue, Jul 3, 2012 at 06:20 UTC, David J Taylor wrote: Presumably, Dave, if the leap second /had/ been inserted, the second message would not have happened? The would have gone backward 1 times message was triggered by the intentional backward step, which wouldn't have occurred at the time it did if the insertion had slewed as designed. That diagnostic is supposed to be suppressed when ntpd steps the clock, but the evidence suggests imperfection. Clearing an additional variable might be all that's needed. Personally, I would correct the missing insertion, and treat the second message as a warning that /something/ unexpected had happened! I want to preserve the unexpected aspect by not logging that message when the clock is expected to step back. If the leap second /had/ been inserted, then would ntp have been confused in the period before the GPS 18/x started emitting correct seconds? It would quickly notice a 1s offset for the NMEA, which would most likely be suppressed initially as a popcorn spike. Whether the clock would be stepped to follow depends on the mix and agreement of sources. I also wonder why the 1-second step doesn't appear to have been reported in the event log. I wondered the same thing. I saw a step logged on Windows ntpd with GPS 18x LVC: 30 Jun 23:59:59 ntpd[2272]: 0.0.0.0 041b 0b leap_event 1 Jul 00:00:00 ntpd[2272]: Leap second announcement disarmed 1 Jul 00:00:15 ntpd[2272]: 0.0.0.0 0413 03 spike_detect -0.98 s 1 Jul 00:03:45 ntpd[2272]: 2001:4f8:fff7:1::17 962a 8a sys_peer 1 Jul 00:12:29 ntpd[2272]: 0.0.0.0 061c 0c clock_step -1.006282 s (followed by re-initializing interpolation spew normally seen only at startup) You may need to add +sysall or more narrowly +sysevent to logconfig in ntp.conf. Cheers, Dave Hart == Thanks , Dave. Understood about the suppression of the would have gone backward 1 times message, so me getting it was a [good] indicator that something was amiss. I agree with ntpd's treatment of these messages. I don't have a logconfig in my ntp.conf, but I could add one if reminded before any further tests. I presume the omission of these messages is part of the ntpd say the least approach, but I wonder whether on more critical servers (perhaps those claiming to be at stratum 1?), there should be less suppression of messages? Against that is the problem of more options meaning more support queries, and more chance of confusion for the poor user! G. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] questions] Leapsecond on FreeBSD or Windows - no showstopper bugs, but ...
On Wed, Jul 4, 2012 at 19:22 UTC, David J Taylor wrote: I don't have a logconfig in my ntp.conf, but I could add one if reminded before any further tests. For maximum eventlog/syslog/ntp.log verbosity: logconfig =clockall +peerall +syncall +sysall If you're using recent 4.2.7 and don't expect to ever use older versions, you can abbreviate: logconfig =allall The default without logconfig is: logconfig =syncall Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] shared memory driver not working under windows4.2.7p273++ build?
These simply indicate that as you noticed, the Windows port currently does not include the SHM driver. However, the ?code in refclock_shm.c once was portable to Windows, and probably can be made so again without too much effort. You'll need to edit ports\winnt\include\config.h to #define CLOCK_SHM to enable it, then fix any problems compiling the code under Windows. pkIndeed, we did get this up and running a couple of years back with a forked version ntp, but we then abandoned the fork in favour of your ongoing builds. If we sort this out and test it, would you consider merging it into your codebase? We really do not want to fork off permanently, especially with win8 in the offing. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
