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

[Arthur Lambert]

Hi,

I am currently using ntpd for my project. My need is to be able to use
new ntp url when I put a new url in ntp.conf even if the ntp daemon is
already running. Currently, I need to kill and reboot ntpd to be able
to use the new ntp url set in my configuration file. i guess that my
solution right now is to start ntpd in a hat process to be able to
restart it if I detect a change in ntp conf file.

Do I have really to restart ntpd to see new ntp url ? I tried to check
option on ntpd to find a way to handle this case but I am not able to
see this feature in the current implementation of ntpd

Thanks & Regards
- Arthur LAMBERT
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

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

[a . everett . 000]

On Monday, 16 September 2013 08:00:09 UTC+1, Igor Pavlov  wrote:
> Hi!
> 
> 
> 
> I am using GPS-receiver based on Geos-1m chip (
> 
> http://www.geostar-navigation.com/en/navigation_05.html)
> 
> 
> 
> I connected it to serial port and configured NTP.
> 
> It becomes unused by NTP: when do ntpq -p reuest ti puts "x" near
> 
> "GPS_NMEA(1)" record.
> 
> 
> 
> What reasons can be for this?
> 
> 
> 
> Example of "ntpq -p" output
> 
> 
> 
>  remote   refid  st t when poll reach   delay   offset
> 
>  jitter
> 
> ==
> 
> xGPS_NMEA(1) .GPS.0 l   14   16  3770.000  -303.07
> 
> 4.292
> 
> *stratum1.net.PPS.1 u   62   64  377   62.800  -68.052
> 
>  43.693
> 
> +dl120g7.naviteh 194.190.168.12 u   58   64  377   30.151  -100.04
> 
>  52.432
> 
> +89.221.207.113  192.36.133.252 u-   64  377   10.006  -105.88
> 
>  64.279
> 
> 
> 
> 
> 
> -- 
> 
> Igor Pavlov

We find that the problem with many (not all) NMEA GPS receivers is that often 
too much data is transmitted between each PPS output. This can have the effect 
that the time output (ZDA) sentence can occasionally shift either side of its 
corresponding pulse output. This has the effect of a 1 second offset 
occasionally being added to time stamps supplied to the NTP daemon.
Sometimes, increasing the baud rate from the standard 4800 bps to 9600 or even 
19200 bps can help by allowing more characters (data) to be transmitted between 
each 1PPS output.

Also, as previously mentioned, simply feeding a 3.3V or 5V pps output from a 
GPS receiver into a RS232 port will not work as the voltage levels are 
different. You will need a simple TTL logic to RS232 converter such as a MAX232 
device to convert the PPS output signal to the correct voltage level.

Andy Everett
TimeTools GPS-Referenced NTP Servers
http://www.timetoolsglobal.com/information/gps-ntp-network-sync-products/

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

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

[Steve Kostecke]

On 2014-04-08, a.everett@gmail.com  wrote:

> On Monday, 16 September 2013 08:00:09 UTC+1, Igor Pavlov wrote:
>
> [---=| Quote block shrinked by t-prot: 45 lines snipped |=---]
>
>>  64.279
>
>We find that the problem with many (not all) NMEA GPS receivers is that
>often too much data is transmitted between each PPS output. This can
>have the effect that the time output (ZDA) sentence can occasionally
>shift either side of its corresponding pulse output.

According to http://doc.ntp.org/4.2.6p5/drivers/driver20.html the NMEA
driver uses the last processed sentence received during each cycle.

So the simple solution is to have only one sentence enabled.

>This has the effect of a 1 second offset occasionally being added to
>time stamps supplied to the NTP daemon. Sometimes, increasing the baud
>rate from the standard 4800 bps to 9600 or even 19200 bps can help by
>allowing more characters (data) to be transmitted between each 1PPS
>output.

4800bps (8N1) transfers 480 bytes (8-bit characters) per second.

NMEA 0183 sentences are limited to 79 characters. So a single NMEA
sentence is fits easily into the 480cps limit.

-- 
Steve Kostecke 
NTP Public Services Project - http://support.ntp.org/

___
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 Lord]

a.everett@gmail.com wrote:

On Monday, 16 September 2013 08:00:09 UTC+1, Igor Pavlov  wrote:

Hi!



I am using GPS-receiver based on Geos-1m chip (

http://www.geostar-navigation.com/en/navigation_05.html)



I connected it to serial port and configured NTP.

It becomes unused by NTP: when do ntpq -p reuest ti puts "x" near

"GPS_NMEA(1)" record.



What reasons can be for this?



Example of "ntpq -p" output



 remote   refid  st t when poll reach   delay   offset

 jitter

==

xGPS_NMEA(1) .GPS.0 l   14   16  3770.000  -303.07

4.292

*stratum1.net.PPS.1 u   62   64  377   62.800  -68.052

 43.693

+dl120g7.naviteh 194.190.168.12 u   58   64  377   30.151  -100.04

 52.432

+89.221.207.113  192.36.133.252 u-   64  377   10.006  -105.88

 64.279





--

Igor Pavlov


We find that the problem with many (not all) NMEA GPS receivers is that often 
too much data is transmitted between each PPS output. This can have the effect 
that the time output (ZDA) sentence can occasionally shift either side of its 
corresponding pulse output. This has the effect of a 1 second offset 
occasionally being added to time stamps supplied to the NTP daemon.
Sometimes, increasing the baud rate from the standard 4800 bps to 9600 or even 
19200 bps can help by allowing more characters (data) to be transmitted between 
each 1PPS output.

Also, as previously mentioned, simply feeding a 3.3V or 5V pps output from a 
GPS receiver into a RS232 port will not work as the voltage levels are 
different. You will need a simple TTL logic to RS232 converter such as a MAX232 
device to convert the PPS output signal to the correct voltage level.


I've used ttl to parallel port with offset being same as via
serial port.

Some gpio ports have timestamps that can be used by a modified
ntpd refclock driver to obtain sub us offsets.
http://www.febo.com/pages/soekris/


If you are lucky the serial port thresholds might be above ttl
low and can be used without problem.


David



Andy Everett
TimeTools GPS-Referenced NTP Servers
http://www.timetoolsglobal.com/information/gps-ntp-network-sync-products/


___
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 Lord]

Arthur Lambert wrote:

Hi,

I am currently using ntpd for my project. My need is to be able to use
new ntp url when I put a new url in ntp.conf even if the ntp daemon is
already running. Currently, I need to kill and reboot ntpd to be able
to use the new ntp url set in my configuration file. i guess that my
solution right now is to start ntpd in a hat process to be able to
restart it if I detect a change in ntp conf file.

Do I have really to restart ntpd to see new ntp url ? I tried to check
option on ntpd to find a way to handle this case but I am not able to
see this feature in the current implementation of ntpd


Hi

I've lived with "your problem" since 1997 when I switched from
mostly running chrony to mostly running ntp.

I never saw it as a problem.


David

___
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

[Dowd, Greg]

do you mean a new association?  Like the ntpdc addserver command?  

-Original Message-
From: questions-bounces+greg.dowd=microsemi@lists.ntp.org 
[mailto:questions-bounces+greg.dowd=microsemi@lists.ntp.org] On Behalf Of 
David Lord
Sent: Tuesday, April 08, 2014 6:39 AM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] Handle ntp conf modification when ntp is already 
running

Arthur Lambert wrote:
> Hi,
> 
> I am currently using ntpd for my project. My need is to be able to use 
> new ntp url when I put a new url in ntp.conf even if the ntp daemon is 
> already running. Currently, I need to kill and reboot ntpd to be able 
> to use the new ntp url set in my configuration file. i guess that my 
> solution right now is to start ntpd in a hat process to be able to 
> restart it if I detect a change in ntp conf file.
> 
> Do I have really to restart ntpd to see new ntp url ? I tried to check 
> option on ntpd to find a way to handle this case but I am not able to 
> see this feature in the current implementation of ntpd

Hi

I've lived with "your problem" since 1997 when I switched from mostly running 
chrony to mostly running ntp.

I never saw it as a problem.


David

___
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] Handle ntp conf modification when ntp is already running

[Paul]

On Tue, Apr 8, 2014 at 12:24 PM, Dowd, Greg  wrote:

> do you mean a new association?  Like the ntpdc addserver command?
>

Beyond the limited set of options and unpleasant syntax of addserver isn't
ntpdc deprecated? (and disabled by default in recent builds)

Perhaps :config and config-from-file are the intended replacements.
___
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

[Arthur Lambert]

Hi David,

I don't get your point. You know that we can live just with fire ? Why do
we invent electricity  And computer ? This is exactly the same here. I
change the channel on my tv, I dont want to reboot it to get the new tv
channel It's worked ok but it a very strange choice of architecture.

But I can guess with your answer that I cannot handle modification on my
ntp conf without restart it. I will try to patch it to get it work with my
need.

Thanks,
Arthur.
Le 8 avr. 2014 16:19, "David Lord"  a écrit :

> Arthur Lambert wrote:
>
>> Hi,
>>
>> I am currently using ntpd for my project. My need is to be able to use
>> new ntp url when I put a new url in ntp.conf even if the ntp daemon is
>> already running. Currently, I need to kill and reboot ntpd to be able
>> to use the new ntp url set in my configuration file. i guess that my
>> solution right now is to start ntpd in a hat process to be able to
>> restart it if I detect a change in ntp conf file.
>>
>> Do I have really to restart ntpd to see new ntp url ? I tried to check
>> option on ntpd to find a way to handle this case but I am not able to
>> see this feature in the current implementation of ntpd
>>
>
> Hi
>
> I've lived with "your problem" since 1997 when I switched from
> mostly running chrony to mostly running ntp.
>
> I never saw it as a problem.
>
>
> David
>
> ___
> 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] Handle ntp conf modification when ntp is already running

[Steve Kostecke]

On 2014-04-08, Arthur Lambert  wrote:

> But I can guess with your answer that I cannot handle modification on my
> ntp conf without restart it. I will try to patch it to get it work with my
> need.

ntpd parses the configuration file at start-up.

ntpd does not monitor the configuration file for changes.

ntpd does not, AFAIK, reparse the configuration file in response to any
signals (e.g. SIGHUP).

Please contibute a patch with your changes to our BTS at http://bugs.ntp.org

> [---=| TOFU protection by t-prot: 31 lines snipped |=---]

...

-- 
Steve Kostecke 
NTP Public Services Project - http://support.ntp.org/

___
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 08.04.2014 20:30, questions-requ...@lists.ntp.org digested:
> From: Arthur Lambert 
> 
> Hi David,
> 
> I don't get your point. You know that we can live just with fire ? Why do
> we invent electricity  And computer ? This is exactly the same here. I
> change the channel on my tv, I dont want to reboot it to get the new tv
> channel It's worked ok but it a very strange choice of architecture.
> 
> But I can guess with your answer that I cannot handle modification on my
> ntp conf without restart it. I will try to patch it to get it work with my
> need.

As Paul already noted, there *are* mechanisms to change aspects of the
configuration during runtime, but they've gotten *quite* disparate from
the effects that a restart with a changed config file has, up to and
including downright missing functionality. In other words, you *do* have
an interest to check whether the changed config file does work as
expected while you're still sitting there with the editor at hand.

Or else, to stay in your analogy, you might find that your TV happily
changed channels for years on end, but flat out fails to turn on after a
power failure (or OS update, or ...) finally "rebooted" it for you.

>From a theoretical point of view, restarting ntpd on a single server
will force it to drop its "working" stratum and associations for a
while, but its system clock should continue to be fine-tuned according
to the latest results (loaded from the drift file) with virtually no
interruption. That shouldn't be a problem unless other hosts sync
against that one - in which case having more than one local server for
your clients would be the proper fix.

There's no genuine advantage (caches loaded, more statistic

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

[Jochen Bern]

On 08.04.2014 22:28, Jochen Bern wrote:
> There's no genuine advantage (caches loaded, more statistic

...al data gathered, priorization through higher uptime, ...) for an
ntpd in having a higher runtime.

(Sorry, badly placed touchpad sent the original mail prematurely.)

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] Frequency adjustments in a local network

[William Unruh]

On 2014-04-07, Maximilian Brehm  wrote:
>
>
> William Unruh schrieb:
>> On 2014-04-04, Maximilian Brehm  wrote:
>>> Hey again,
>>>
>>> thanks for the feedback so far. From your messages I realize I should
>>> provide you with more information.
>>> I would like to adjust the real time clock frequency of the destination
>>> system. In the current setup the reference system has temperature
>>> independent oscillators with a known drift (up to +/-2ppm) and the
>>> destination system has standard computer oscillators (up to +/-100ppm).
>> 
>> There is a difference between "real time clock (RTC) which is a clock
>> chip in the bios, and the system clock of the operating system, which is
>> run from the computer oscillator, and is set from the RTC. 
>> 
> Thanks for the correction, so I actually meant the system clock. 
>>> The reference system supplies timestamps, however, they do not
>>> reference
>>> absolute time points but time points that are relative to the start of
>>> the system. The destination's clock is synchronized via NTP over the
>>> Internet and as mentioned incorrectly before, the destination system
>>> needs the absolute time. In the current implementation, the timestamps
>>> are already sent from the reference to the destination system for other
>>> purposes and may be used for clock synchronization.
>>> In a first approach (1), when the connection to the NTP servers
>>> drops, the destination's clock should be adjusted based on the
>>> reference
>>> system's timestamps (but with the absolute time). In a second approach
>>> (2), the NTP algorithm filter and adjustment algorithms should be
>>> improved based on the reference system's timestamps.
>>> The logic has to be implemented on the destination system using the
>>> timestamps from the reference system. Do you think that a refclock
>>> driver for (1) sufficient? And is there anything like (2) already
>>> implemented or is a rewrite of NTP required? Do you have any general
>>> ideas on either (1) or (2) or another one? PTP looks good but NTP is a
>>> necessessity.
>> 
>> I am afraid that I find your explanation more confusing than before. 
>> 
>> The way ntp works is to to use the offset between the time as stated by
>> the system, and the time as stated by the server/source to speed up or
>> slow down the clock in order to bring that offset to zero. Thus it
>> measures the offset and adjusts the rate of the clock. That means that
>> an offset aof 80 years say will drive it nuts (well actually it will
>> simply jump the clock). 
> Could not I just measure the offset in the destination system and add
> the offsets to the timestamps of the reference system before processing
> them?

You would not want the server altering its time given the time of a
client. Let the client figure out its own problems and solve them.

>> 
>> You could run an interrupt line to the system, and use say shm_pps to
>> look at the interrupt, get the subsecond offset from that interrupt, but
>> use the system time to the nearest second as the seconds. Ie, by
>> definition the offset is never more than .5 sec. This would discipline
>> the time by keeping the microseconds offset between the two as near zero
>> as possible, but ignore the seconds part of the offset. 
>> You could even write a routine using shm to do that. 
>> 
>> I suppose you could also rewrite ntp to use some remote server in that
>> way-- ie one in which the seconds part of the time from that remote
>> receiver was replaced by the nearest second from your local clock. 
>> 
>> Now, this would mean that you would have to use some other source at
>> boot up to get your clock to be accurate within a second before
>> switching to this new source. 
> I have to admit I do not understand you here. Is shm_pps already
> implemented? I believe it references the Shared Memory driver in
> conjunction with Pulse-Per-Second? In the NTP code I have not found
> these drivers working in conjunction. Does this work?
It is a separate program which reads a pps source and delivers the time
to the shm memory location for the ntp shm refclock driver to read. It
relies on the system having a second outside client to bring the system
to within 1/2 a second of the right time, and then uses the system
seconds to tack onto the timestamped microsecond from the pps source. 
Now, in your case, you do not care about the seconds.

The name is actually shmpps. Note that you would have to redo it so as
to get the microseconds from you bad server instead of from an interrupt
driven timestamping.
>> 
>>>
>>> Regards
>>> Maximilian

___
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

[William Unruh]

On 2014-04-08, Arthur Lambert  wrote:
> Hi,
>
> I am currently using ntpd for my project. My need is to be able to use
> new ntp url when I put a new url in ntp.conf even if the ntp daemon is
> already running. Currently, I need to kill and reboot ntpd to be able
> to use the new ntp url set in my configuration file. i guess that my
> solution right now is to start ntpd in a hat process to be able to
> restart it if I detect a change in ntp conf file.
>
> Do I have really to restart ntpd to see new ntp url ? I tried to check
> option on ntpd to find a way to handle this case but I am not able to
> see this feature in the current implementation of ntpd

I believe you can tell ntpd anthing that ntp.conf would by using ntpq.
I do not believe that there is a way of telling it to reread the .conf
file. 

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

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

[William Unruh]

On 2014-04-08, Steve Kostecke  wrote:
> On 2014-04-08, a.everett@gmail.com  wrote:
>
> According to http://doc.ntp.org/4.2.6p5/drivers/driver20.html the NMEA
> driver uses the last processed sentence received during each cycle.
>
> So the simple solution is to have only one sentence enabled.
>
>>This has the effect of a 1 second offset occasionally being added to
>>time stamps supplied to the NTP daemon. Sometimes, increasing the baud
>>rate from the standard 4800 bps to 9600 or even 19200 bps can help by
>>allowing more characters (data) to be transmitted between each 1PPS
>>output.
>
> 4800bps (8N1) transfers 480 bytes (8-bit characters) per second.
>
> NMEA 0183 sentences are limited to 79 characters. So a single NMEA
> sentence is fits easily into the 480cps limit.

While certainly true, it is not quite so simple because almost all gps
do not immediately send out the nmea sentence at the interrupt. They sit
there cogitating for a while (eg for .2 sec or more) before starting to
send out the sentences. This means the the max number of sentences is
less than a naive calculation would suggest. On the otherhand even .5
sec should be more than enough time to send out one sentence. 

>

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

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

[William Unruh]

On 2014-04-08, David Lord  wrote:
>
>
> If you are lucky the serial port thresholds might be above ttl
> low and can be used without problem.

Have you ever ( in the past 10 years) seen one that could not handle it?

On another issue, please stop using google to send your usenet posts.
Google adds a blank line between every line you quote even if both are
blank lines. This makes replies rapidly unreadable. Perhaps they remove
them in delivering them to you as well so you never notice the absolute
mess that google makes of your posts. 

>
>
> David
>
>> 
>> Andy Everett
>> TimeTools GPS-Referenced NTP Servers
>> http://www.timetoolsglobal.com/information/gps-ntp-network-sync-products/

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

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

[William Unruh]

On 2014-04-08, a.everett@gmail.com  wrote:
>
> Also, as previously mentioned, simply feeding a 3.3V or 5V pps output from a 
> GPS receiver into a RS232 port will not work as the voltage levels are 
> different. You will need a simple TTL logic to RS232 converter such as a 
> MAX232 device to convert the PPS output signal to the correct voltage level.
>
Actually false form most serial ports these days. While the standard
says 5V the actuallity is that 3,3 V will trigger it on almost all
serial ports. Ie, in general it is a non-issue. Note that the fact that
serial and parallel ports and their interrupts are disappearing from
almost all computer is probably a bigger problem. 

___
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 Lord]

William Unruh wrote:

On 2014-04-08, David Lord  wrote:


If you are lucky the serial port thresholds might be above ttl
low and can be used without problem.


Have you ever ( in the past 10 years) seen one that could not handle it?



Hi Bill

I've never tried but have specs for chips in different serial cards
some of which can't handle ttl.



On another issue, please stop using google to send your usenet posts.


I've never used google

I use nntpd?

but I possibly don't clean up the posts I'm replying to, to your
satisfaction :-)


David


Google adds a blank line between every line you quote even if both are
blank lines. This makes replies rapidly unreadable. Perhaps they remove
them in delivering them to you as well so you never notice the absolute
mess that google makes of your posts. 



David


Andy Everett
TimeTools GPS-Referenced NTP Servers
http://www.timetoolsglobal.com/information/gps-ntp-network-sync-products/


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

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

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

On 4/8/2014 2:57 PM, William Unruh wrote:
> On 2014-04-08,  wrote:
>>
>> Also, as previously mentioned,
>>  simply feeding a 3.3V or 5V pps output from a GPS receiver
>>   into a RS232 port will not work as the voltage levels are different.
>>  You will need a simple TTL logic to RS232 converter such as a MAX232
>>   device to convert the PPS output signal to the correct voltage level.
>>
> Actually false form most serial ports these days. While the standard
> says 5V the actuallity is that 3,3 V will trigger it on almost all
> serial ports. Ie, in general it is a non-issue. Note that the fact that
> serial and parallel ports and their interrupts are disappearing from
> almost all computer is probably a bigger problem.

The current version is TIA/EIA-232-F (circa 1997, last updated 2002?)

 Electrical Specification
 A logic 0 is represented by a driven voltage between 5 V and 15 V
  and a logic 1 of between –5 V and –15 V.
 At the receiving end, a voltage between 3 V and 15 V represents a 0
  and a voltage of between –3 V and –15 V represents a 1.
 Voltages between ±3 V are undefined and lie in the transition region.
  This effectively gives a 2-V minimum noise margin at the receiver.


I've used some current TI (RS232-F speced),
  that don't switch if the voltage remains positive;
However I have also used some current Maxium that switch at ~ 1.5 V.

 I haven't really seen this change much in the last two years,
  however I certainly could be missing out on some modern chipset's RS232 
features.


-- 
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

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

On 4/8/2014 2:49 PM, William Unruh wrote:
> On 2014-04-08, Arthur Lambert wrote:
-|-|-|-|-|-|
>> I am currently using ntpd for my project.
>>  My need is to be able to use new ntp url when I put a
>>   new url in ntp.conf even if the ntp daemon is already running.
>>  Currently, I need to kill and reboot ntpd to be able to
>>   use the new ntp url set in my configuration file.
>>  i guess that my solution right now is to start ntpd in a
>>   hat process to be able to restart it if I detect a change
>>   in ntp conf file.
>>
>> Do I have really to restart ntpd to see new ntp url ?
>> I tried to check option on ntpd to find a way to handle
>>  this case but I am not able to see this feature in the
>>  current implementation of ntpd

You would likely need to use a fairly bleeding edge Dev Release.


e.g. Development  4.2.7p439  2014/04/03




> I believe you can tell ntpd anthing that ntp.conf would by using ntpq.

:config

> I do not believe that there is a way of telling it to reread the .conf
> file.
>

config-from-file filename



 I haven't tried either (yet).


or e.g. {In the case of the dev ver I last downloaded}
 See: Control-Message-Commands



-- 
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