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
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
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
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
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
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
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
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
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
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
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),
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
Harlan Stenn st...@ntp.org 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
On 10.04.2014 14:00, questions-requ...@lists.ntp.org digested:
From: Terje Mathisen terje.mathi...@tmsw.no
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
Rob writes:
Harlan Stenn st...@ntp.org 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
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
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.
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
___
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
19 matches
Mail list logo
