Re: [ntp:questions] Reasons of NTP not to use GPS source

[E-Mail Sent to this address will be added to the BlackLists]

Paul wrote:
> However it doesn't matter if William Unruh has never seen level
>  matching problems or if Null@blacklist has always seen it.

I don't know about "always", "still" is probably a more accurate word.

I do have dozens (if not hundreds) that mostly use max232 chips,
 which won't drive as hard (for really long out of spec length serial lines,
 ~ hundreds of feet on cat5e), however they switch at around 1.5 v,
 so they work fine without a TTL - RS232 level converter.

 Trying to drive TTL into RS232 receivers can be easily tested,
   for any giving receiver / chipset;
  If you however drive RS232 drivers into TTL inputs,
   you can certainly damage them (unless on a really long cable),
   {I've have a few people toast (TTL) serial and parallel ports that way,
 not to mention an occasional 422 or 485 serial port too}.

> If the device under test works it works and if not you
>  have to condition the pulse or find another solution.

Certainly, if it works for you, problem solved;
 If it doesn't you shouldn't be too surprised.


-- 
E-Mail Sent to this address 
  will be added to the BlackLists.

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

Re: [ntp:questions] Handle ntp conf modification when ntp is already running

[John Hasler]

David Woolley writes:
> A daemon is generally a session leader.  The first TTY it opens will
> become its controlling terminal.

Not if the terminal is opened with O_NOCTTY.
-- 
John Hasler 
jhas...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

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

Re: [ntp:questions] Handle ntp conf modification when ntp is already running

[David Woolley]

On 10/04/14 17:51, Rob wrote:

A modemline attached to a process does not send SIGHUP when the modem
drops carrier unless the process has that modemline as a controlling TTY.


A daemon is generally a session leader.  The  first TTY it opens will 
become its controlling terminal.


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

[ntp:questions] How does NTP configure serial port parameters?

[Jason Rabel]

I've seen in the reflock driver sources where they hard-code in the serial port 
speed (i.e. 9600), but what about the parameter
settings? i.e. the data bits, parity bit, and stop bit?

Specifically I'm using the palisade driver, but have selected 'mode 1' because 
I'm using an Endrun Technologies timing board
emulating a palisade (long story short, the little SBC took a dive but the rest 
of the hardware is good). I've peeled through
documents and nothing really says what the complete port settings should be for 
this particular mode.

NTP says 8O1 by default for Palisade but 8N1 for the Thunderbolt. Again, I 
looked through the reflock source and couldn't find
anything beyond the speed setting, unless I'm just totally oblivious and missed 
it.

The default Trimble TSIP settings for every receiver I've seen is 8O1, but 
seeing that document mention 8N1 for the thunderbolt just
kind of threw me for a loop.

I'll probably just end up trying both ways, but I'm trying to avoid some 
possible unknown errors if I end up using the wrong
settings...



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

Re: [ntp:questions] Handle ntp conf modification when ntp is already running

[Harlan Stenn]

Rob writes:
> Harlan Stenn  wrote:
> > Amongst the many reasons why we did not let SIGHUP restart the daemon
> > was that back in the old days we used modem drivers a lot more often.
> > The HUP signal was generic - it was not really associated with any
> > specific device.
> 
> I think you are confusing two things.
> 
> A modemline attached to a process does not send SIGHUP when the modem
> drops carrier unless the process has that modemline as a controlling TTY.
> 
> So, when you have a daemon like ntpd that would open a modemline for
> some communication, it will not get the SIGHUP from there.
> 
> SIGHUP as sent between processes to force a configuration reload is
> completely unrelated to SIGHUP as sent by tty lines when carrier drops.
> (and used to save files in editors, terminate an interactive session, etc)
> 
> Sure it is confusing that the same signal is used.  Probably there should
> have been a separate SIGRECONF or similar.  However, in those days
> designers worried about using up a small number space, like signal
> numbers that are bitnumbers in a word, and thus limited to 1-31.

I'm still missing something then.

Unix signal handlers don't get any callback context.

So how can the handler know if it got a sighup because of a TTY HUP as
opposed to the signal arriving because the user wants to do a reload?

And I used to do a lot of signal stuff in general and SIGHUP processing
(both re ttys and for reload) but haven't done this in Years.  I may be
misremembering.

> Furthermore, the "simple solution" of having SIGHUP perform an exec
> of the same binary, thus in fact restarting the entire process and
> losing all state information, is not the only possible solution.

If the current process has chroot()ed, how do you re-exec?  How do you
handle the things that are done before the chroot()?  Again, I haven't
looked at the code to be sure, but I believe there are some things that
will behave differently if they are attempted from the chroot() target.

Sure, one could have a top-level master process that simply waits for
the chroot()ed subprocess to die and then restarts it, but we're
starting to get in to a lot of wheel-reinventing here, and would this
really be worth the overhead on a program that is already larger and
more complicated than many folks want?

> It is also possible to make SIGHUP parse the configfile into a new
> datastructure, then let the program determine the differences between
> the old and new situation, and perform the necessary changes (like adding
> and removing servers), without disturbing existing associations and the
> frequency control loop.
> 
> This of course requires a lot more effort, especially when this was
> not designed in from the start.

Yes, and it is something we can slate in for at least consideration for
the next rewrite of the codebase.

H
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Handle ntp conf modification when ntp is already running

[Jochen Bern]

On 10.04.2014 14:00, questions-requ...@lists.ntp.org digested:
> From: Terje Mathisen 
> 
> Rob wrote:
>> > OF COURSE ntpd should simply listen for SIGHUP and when it is received
>> > re-read the config file.  Like almost all Unix daemons do.
> 
> Here's the crux of the matter:
> ntpd is _not_ a "Unix daemon", or at least not just that: The same code 
> runs on many different operating systems, some of which don't implement 
> SIGHUP at all, or at least not in a compatible manner.

Now this sounds dangerously close to "ntpd cannot possibly use a config
file, because it is supposed to be running on various OSes with
incompatible character and end-of-line encodings" ...

> From: Harlan Stenn 
> 
> Amongst the many reasons why we did not let SIGHUP restart the daemon
> was that back in the old days we used modem drivers a lot more often.
> The HUP signal was generic - it was not really associated with any
> specific device.

I wouldn't be surprised if spurious SIGHUPs were still occuring (and
possibly reaching unrelated daemon processes) today - just think of how
many DSL routers happen to have a unixoid OS and are actually running a
pppd (whose manpage mentions HUPs a lot). Point is, for daemons *other*
than ntpd, "rereading the config" that nobody did edit will likely have
no noticeable effect at all. For ntpd, with the round robin DNS pools
yielding different servers every time you resolve, and possibly losing
status even for those servers that did *not* change ... things might
look different.

Then again, it's not like there are no established unixoid methods
*other* than HUP - from USR1 (no example whose name I'd remember off the
top of my head) to polling the config file's stat() periodically (a la
/etc/crontab) to a simple CLI via local special files (a la Nagios
command pipe, or even "echo 1 > /proc/sys/foo/bar") to opaque IPC hidden
behind a dedicated util's command line options (a la apachectl, or
fetchmail --quit). At the end of the day, lots of people - and the most
important clustering solutions - won't care to look past the OS'
meta-command, be it "service mumblefoo reload" or "svcadm restart
mumblefoo", as long as that *works*. :-}

Regards,
J. Bern
-- 
*NEU* - NEC IT-Infrastruktur-Produkte im :
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH 
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Handle ntp conf modification when ntp is already running

[Rob]

Harlan Stenn  wrote:
> Amongst the many reasons why we did not let SIGHUP restart the daemon
> was that back in the old days we used modem drivers a lot more often.
> The HUP signal was generic - it was not really associated with any
> specific device.

I think you are confusing two things.

A modemline attached to a process does not send SIGHUP when the modem
drops carrier unless the process has that modemline as a controlling TTY.

So, when you have a daemon like ntpd that would open a modemline for
some communication, it will not get the SIGHUP from there.

SIGHUP as sent between processes to force a configuration reload is
completely unrelated to SIGHUP as sent by tty lines when carrier drops.
(and used to save files in editors, terminate an interactive session, etc)

Sure it is confusing that the same signal is used.  Probably there should
have been a separate SIGRECONF or similar.  However, in those days
designers worried about using up a small number space, like signal
numbers that are bitnumbers in a word, and thus limited to 1-31.

Furthermore, the "simple solution" of having SIGHUP perform an exec
of the same binary, thus in fact restarting the entire process and
losing all state information, is not the only possible solution.

It is also possible to make SIGHUP parse the configfile into a new
datastructure, then let the program determine the differences between
the old and new situation, and perform the necessary changes (like adding
and removing servers), without disturbing existing associations and the
frequency control loop.

This of course requires a lot more effort, especially when this was
not designed in from the start.

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

Re: [ntp:questions] WinXP no DCD interupts unless RTS/CTS handshaking enabled

[David Taylor]

On 10/04/2014 09:49, James Gibb wrote:

I'm not sure if this is a generic problem or something weird has happened to 
the UARTs on my box, but I find I only see DCD events if RTS/CTS handshaking is 
on.  This is true for David Taylor's SerialPort LEDs viewer, RealTerm (a 
Windows terminal/debugging program) and NTPd.  I've hacked refclock_open to set 
the DCB flags fOutxCtsFlow to 1 and fRtsControl to RTS_CONTROL_HANDSHAKE and it 
sees PPS; otherwise it does not.

Now, last week it was seeing the PPS without those hacks.  Since then I've 
disconnected an oscilloscope and re-worked the wiring around a level converter 
which temporarily broke PPS at the wire level.  I can't remember using anything 
except the LED viewer and RealTerm to check I'd got it working again and I had 
used both prior to that and they didn't cause this interrupt disabling.

Anyone any ideas what's happened?

// James Gibb


James, that doesn't rung any bells with me in software, perhaps you 
damaged more than just the PPS line when working on the interface.  A 
flake of solder, perhaps?  But that's just a guess.


There's nothing special in the Serial Port LEDs program which would 
require that.

--
Cheers,
David
Web: http://www.satsignal.eu

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

Re: [ntp:questions] Has anyone thought about this?

[Terje Mathisen]

Brian Utterback wrote:

On 4/10/2014 3:22 AM, Terje Mathisen wrote:


The maximum ntpd slew is � 500 ppm, which means that the absolute
maximum possible slew between UTC and the local clock would be 1000
ppm (i.e. the clock is maximally bad, at +500 ppm, and we are
currently slewing at -500 ppm), in which case the maximum error
component from this would be 1/1000th of the actual time delta. (In
real operating systems the actual errors are several orders of
magnitude less! Typical clock frequency adjustments due to temperature
cycling are in the single ppm range, but even a few tens of ppm gives
relative errors in the 1e-4 to 1e-5 range, which doesn't impact the
control loop at all.


I am pretty sure that the � 500 ppm is absolute and is already the sum
of the frequency correction and the current clock slewing. But one of


Oh sure, that is why I wrote that this is the theoretical maximum 
possible, with real-life servers being at least an order of magnitude 
better behaved.



the reasons for having a maximum in the first place is to put a cap on
the error introduced because if the instantaneous frequency corrections
taking place at the time the timestamps are taken. This is all covered
in chapter 11, Analysis of Errors, in the first edition of Das Buch
(Computer Network Time Synchronization, Mills, 2006). I am pretty sure
that it is also in the 2nd ed, but I don't have access to that one.


Neither do I, but I am absolutely sure Dr Mills included this error 
component in his stability and convergence calculations. :-)


If you do allow far higher slew rates, like some other programs do, then 
you would indeed have to separate the offset slew from the frequency 
correction, and use the frequency clock only to measure delta-Ts.


The easiest way to do this is of course to keep a sw delta clock around, 
this one would start out the same as the OS clock, but then only include 
any frequency adjustments to its rate, and not any slew adjustments. At 
this point either HPET or RDTSC could be used as the common frequency 
source for both clocks.


Terje

--
- 
"almost all programming can be viewed as an exercise in caching"

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

[ntp:questions] Fwd: Simulate PPS devices

[Maximilian Brehm]

I wrote the message before I actually checked out shmpps. It seems 
that it does not use the Kernel-PPS interface but simply transmits a 
timestamp via the shared memory interface each second.


The reason I want to use the Kernel-PPS interface (RFC 2783 mentions 
that it supports asynchronous signals) and simulate devices is that it 
includes additional sanity checks. I guess I could alternatively 
implement the logic myself (could I?), that is, wait for a packet with 
an offset greater than one second compared to the last used package and 
pass it to my own PPS discipline.


Regards
Maximilian


 Original Message 
Subject: [ntp:questions] Simulate PPS devices
Date: Thu, 10 Apr 2014 15:26:52 +0200
From: Maximilian Brehm 
To: 



Hey,

so, I wrote a program to communicate with NTP via the shared
memory driver. It currently uses CLOCK_REALTIME and CLOCK_MONOTONIC to
simulate an offset and NTP wanders there correctly.

Now I would like
to include support for PPS. I found gpsd (http://gpsd.berlios.de/) and
shmpps (thanks to William Unruh,
http://pkgs.fedoraproject.org/cgit/shmpps.git/) for reference. As far 
as

I see they both rely on hardware devices and connections via serial or
parallel port or USB. I also found an interesting hack of shmpps using
/dev/rtc at http://www.wraith.sf.ca.us/ntp/#parallel-port. As 
mentioned

in previous emails, I need the PPS signal to be simulated by analyzing
the timestamps of a packet stream from a reference system in a
destination system. The programs mentioned above use the Kernel-PPS
interface which relies on devices as far as I can see. So do you know 
a

proper way to approach this? Could I simulate a device similar to
/dev/rtc and make use of the hack?

Is this still the correct mailing
list for this purpose?

Thanks

Maximilian


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

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

Re: [ntp:questions] Has anyone thought about this?

[Brian Utterback]

On 4/10/2014 3:22 AM, Terje Mathisen wrote:


The maximum ntpd slew is ± 500 ppm, which means that the absolute 
maximum possible slew between UTC and the local clock would be 1000 
ppm (i.e. the clock is maximally bad, at +500 ppm, and we are 
currently slewing at -500 ppm), in which case the maximum error 
component from this would be 1/1000th of the actual time delta. (In 
real operating systems the actual errors are several orders of 
magnitude less! Typical clock frequency adjustments due to temperature 
cycling are in the single ppm range, but even a few tens of ppm gives 
relative errors in the 1e-4 to 1e-5 range, which doesn't impact the 
control loop at all. 


I am pretty sure that the ± 500 ppm is absolute and is already the sum 
of the frequency correction and the current clock slewing. But one of 
the reasons for having a maximum in the first place is to put a cap on 
the error introduced because if the instantaneous frequency corrections 
taking place at the time the timestamps are taken. This is all covered 
in chapter 11, Analysis of Errors, in the first edition of Das Buch 
(Computer Network Time Synchronization, Mills, 2006). I am pretty sure 
that it is also in the 2nd ed, but I don't have access to that one.


Brian Utterback
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

[ntp:questions] Simulate PPS devices

[Maximilian Brehm]

Hey, 

so, I wrote a program to communicate with NTP via the shared
memory driver. It currently uses CLOCK_REALTIME and CLOCK_MONOTONIC to
simulate an offset and NTP wanders there correctly. 

Now I would like
to include support for PPS. I found gpsd (http://gpsd.berlios.de/) and
shmpps (thanks to William Unruh,
http://pkgs.fedoraproject.org/cgit/shmpps.git/) for reference. As far as
I see they both rely on hardware devices and connections via serial or
parallel port or USB. I also found an interesting hack of shmpps using
/dev/rtc at http://www.wraith.sf.ca.us/ntp/#parallel-port. As mentioned
in previous emails, I need the PPS signal to be simulated by analyzing
the timestamps of a packet stream from a reference system in a
destination system. The programs mentioned above use the Kernel-PPS
interface which relies on devices as far as I can see. So do you know a
proper way to approach this? Could I simulate a device similar to
/dev/rtc and make use of the hack? 

Is this still the correct mailing
list for this purpose? 

Thanks 

Maximilian 

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

[ntp:questions] WinXP no DCD interupts unless RTS/CTS handshaking enabled

[James Gibb]

I'm not sure if this is a generic problem or something weird has happened to 
the UARTs on my box, but I find I only see DCD events if RTS/CTS handshaking is 
on.  This is true for David Taylor's SerialPort LEDs viewer, RealTerm (a 
Windows terminal/debugging program) and NTPd.  I've hacked refclock_open to set 
the DCB flags fOutxCtsFlow to 1 and fRtsControl to RTS_CONTROL_HANDSHAKE and it 
sees PPS; otherwise it does not.

Now, last week it was seeing the PPS without those hacks.  Since then I've 
disconnected an oscilloscope and re-worked the wiring around a level converter 
which temporarily broke PPS at the wire level.  I can't remember using anything 
except the LED viewer and RealTerm to check I'd got it working again and I had 
used both prior to that and they didn't cause this interrupt disabling.

Anyone any ideas what's happened?

// James Gibb
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Reasons of NTP not to use GPS source

[Paul]

A remarkable amount of traffic for a question posted last September.
Particularly considering voltage matching wasn't mentioned.

However it doesn't matter if William Unruh has never seen level matching
problems or if Null@blacklist has always seen it. If the device under test
works it works and if not you have to condition the pulse or find another
solution.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Reasons of NTP not to use GPS source

[John Hasler]

David Woolley writes:
> How do they meet the requirement for unpowered control lines to appear
> to be off?

If they are unpowered they will never exceed the positive threshold and
therefor will never appear to be on.
-- 
John Hasler 
jhas...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

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

Re: [ntp:questions] Handle ntp conf modification when ntp is already running

[Harlan Stenn]

Amongst the many reasons why we did not let SIGHUP restart the daemon
was that back in the old days we used modem drivers a lot more often.
The HUP signal was generic - it was not really associated with any
specific device.

It looks like that code is now gone from the distribution, but there are
still a few places in the code (lib/isc/unix/app.c and
libntp/work_fork.c) that would need to be looked at.

Additionally, on non-windows platforms somebody would have to look at
SIGDIE1.

H
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Handle ntp conf modification when ntp is already running

[Terje Mathisen]

Rob wrote:

For Arthur: you need to modify the ntp.conf in case the system is
rebooted outside your control (it will then use the values from ntp.conf)
and at the same time use the above method to add the new server
immediately.
Then you do not need to restart ntpd and you can still change the config.


Right.


OF COURSE ntpd should simply listen for SIGHUP and when it is received
re-read the config file.  Like almost all Unix daemons do.


Here's the crux of the matter:

ntpd is _not_ a "Unix daemon", or at least not just that: The same code 
runs on many different operating systems, some of which don't implement 
SIGHUP at all, or at least not in a compatible manner.


However, you will have a hard time convincing the group here, as you
already found out.


I personally believe it would be nice if we did support SIGHUP on 
platforms where that is easily implementable, otoh ntpd is moving 
strongly towards a more or less auto-configurable setup:


A single 'pool pool.ntp.org' in the ntp.conf file (possibly added as 
default if started without a config file at all), and then the ntpd 
process will automatically redo the dns lookup every hour or so, pruning 
away the worst-performing servers and replacing them with new entries 
from the dns pool.


Terje

--
- 
"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] Reasons of NTP not to use GPS source

[David Woolley]

On 10/04/14 01:20, E-Mail Sent to this address will be added to the


Yes, I have several hundreds (if not thousands)
  that use a TI chip, that will not change the logic level,
  if the input does not go negative.



How do they meet the requirement for unpowered control lines to appear 
to be off?


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

Re: [ntp:questions] Has anyone thought about this?

[Terje Mathisen]

Dowd, Greg wrote:

However, t1 and t4 are not really in seconds if the client clock is slewing.
That is, the
difference t4 - t1 will be shorter than seconds if the clock is being slowed 
down
and larger if the clock is being sped up.  Hence the clock slew may be a source 
of
variation that is not presently being accounted for.


Yes, but see below...



One some systems the frequency of the Performance Counter (PC) is constant
because it is driven by the High Performance Event Timer (HPET).  And
according to one article on the Internet, the PC can be made to be driven
by the HPET on Win 8 by this edit: " run cmd as admin and paste
'bcdedit /set {current} useplatformclock Yes'".


Would NTPD have less variation in offset and delay if, say, t4 were measured
by the difference in PC readings between the time t1 is measured and the
time T4 is presently measured?


Not really.

First of all, the HPET (or TSC) counters have no known frequency to 
start with, you have to measure that using regular "wall clock", i.e. 
ntp packet exchanges.


Secondly, even if you do have a "perfect interval timer", say a TCXO on 
your network card, the clock slew rate can only contribute very marginal 
second-order effects:


The maximum ntpd slew is +/- 500 ppm, which means that the absolute 
maximum possible slew between UTC and the local clock would be 1000 ppm 
(i.e. the clock is maximally bad, at +500 ppm, and we are currently 
slewing at -500 ppm), in which case the maximum error component from 
this would be 1/1000th of the actual time delta. (In real operating 
systems the actual errors are several orders of magnitude less! Typical 
clock frequency adjustments due to temperature cycling are in the single 
ppm range, but even a few tens of ppm gives relative errors in the 1e-4 
to 1e-5 range, which doesn't impact the control loop at all.


Terje

--
- 
"almost all programming can be viewed as an exercise in caching"

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