Re: [ntp:questions] Can NTP sync within 1ms

[William Unruh]

On 2014-04-27, Rob  wrote:
> j...@specsol.spam.sux.com  wrote:
>>> The listeners should enjoy a smooth reception while driving around.
>>> So of course there should be no time lag between the modulation signals
>>> of the different transmitters.  Experts in the field tell us we should
>>> be within 12us.
>>
>> Unless I fat fingered the calculator, that means the difference in distance
>> between transmitters relative to the receiver can be no more than 3.6 km.
>>
>> 300 meters per microsecond; it is the law...
>
> The goal is not to have 12us difference in arrival time, but to be
> within 12us for transmission time.

Why not within 12 psec? Ie, what is the reason for this requirement? 
And I thought this thread started with 1ms.

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

Re: [ntp:questions] Can NTP sync within 1ms

[Jochen Bern]

On -10.01.-28163 20:59, Rob wrote:
> Jochen Bern  wrote:
>> I'm afraid I don't get it yet. You're trying to sync waveforms on the HF
>> side (~100 MHz?) instead of switching between two transmitters on the AF
>> side (couple kHz, with that much more leeway for the sync), a la
>> perfectly normal car radio with RDS AF and dual tuners, because ... ?
> 
> It is not an FM broadcast system, it is an amateur radio repeater system
> with wide area coverage.

Alright, I think I'm closing in on some basic concepts now. :-} You have
existing mobile FM transceivers and existing individual repeaters
(including the non-equidistant rather far in-between sites they're
installed at) and you want to add sort of a central control to the
repeaters so that they act in unison, relaying one input to the *entire*
coverage area, and in such a way that the mobile transceivers do not
have to care (read: QSY) which single repeater they're currently covered
by - RX as well as TX.

First good news, you won't have much of a problem if a participant
getting handed over from one repeater to another experiences a "time
jump" (relative to the master audio stream) even of several tenths of a
second.

Second good news, the audio stream will likely experience pauses
(everytime one OM hands the mic to another) more often than the mobile
devices will need to switch over to a new repeater. With tight enough a
"squelch", your repeaters can actually drop output power during that
pause, which might help the mobiles switch over even in the presence of
capture effect etc. during the power-up phases.

On the not-so-good side, once a random participant finally got the PTT
squished, your repeaters will have to have a quorum decision which
repeater's *input* to use for the master audio stream of the entire
system. (And you might want to modulate the repective repeater's ID over
it in CW, or else crocodile hunting will get pretty tedious. ;-)

However, that *does* leave me wondering where the 12 us figure comes
into play. With the typical distances between 2m and even 70cm
repeaters, the mobile transceivers will see shifts *far* beyond that
between different repeaters' signals. FWIW, will you have the audio
cards output AM (that will then get modulated onto an otherwise
unsynchronized HF), or do you plan to have the card generate HF directly
into the PA?

Regards,
DD0KZ
-- 
*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] Can NTP sync within 1ms

[jimp]

Rob  wrote:
> j...@specsol.spam.sux.com  wrote:
>> Rob  wrote:
>>> j...@specsol.spam.sux.com  wrote:
 Rob  wrote:
> j...@specsol.spam.sux.com  wrote:
>>> The listeners should enjoy a smooth reception while driving around.
>>> So of course there should be no time lag between the modulation signals
>>> of the different transmitters.  Experts in the field tell us we should
>>> be within 12us.
>>
>> Unless I fat fingered the calculator, that means the difference in 
>> distance
>> between transmitters relative to the receiver can be no more than 3.6 km.
>>
>> 300 meters per microsecond; it is the law...
> 
> The goal is not to have 12us difference in arrival time, but to be
> within 12us for transmission time.

 What good does that do you?

 And regarding "smooth reception while driving around", have you ever heard
 of multipath or the capture effect?
>>> 
>>> Well, smooth reception must be explained as "communication is possible",
>>> not with the HIFI quality expected from a broadcast station.
>>> 
>>> What I mean is that you can drive around and receive the signal all over
>>> the place, even when you drive out of range of one transmitter into the
>>> range of the next.  It works perfectly when the capture effect results
>>> in reception of one transmitter, and in the area where two transmitters
>>> are equal in strength it requires suitable synchronization to still have
>>> good communication.
>>
>> Picket fencing makes it irrelevant.
> 
> This precisely makes it a requirement to synchronize the audio.
> When this is not done, there will be extreme jitter in the audio which
> makes it unintelligible.
> What surprises me is that the audio has to be synchronized so well.
> But we are just going to do that, or approach it as closely as possible.

Nope, it is precisely what makes synchronized audio irrelevant.

If you have picket fencing, you have no intelligible audio no matter
what you do at the transmitters.

>>> I did not come up with the 12us figure, I would have guessed it a bit
>>> higher.  The figure comes from different experts in the field.  The
>>> people that designed and deployed such systems in the world of emergency
>>> services etc.
>>
>> Are you sure that figure is NOT for data communications?
>>
>> Most "emergency services" have voice and data these days.
> 
> Emergency services don't use NBFM systems anymore.  At least not here.
> The networks I am talking about were deployed between the seventies and
> nineties of last century.

Then what the hell are you talking about?

>>> We can now try it in amateur radio because the advances in technology
>>> have made things like GPSDOs and fast network connections affordable.
>>
>> I don't see where that is relevant to anything here.
> 
> I am ending this discussion, I only answered the question "what are you
> trying to do" and I don't need to account for our experiment to you or
> anyone else on this group.

No, you don't.

You can ignore any comments by people with over half a century of experience
and go off and waste your time tilting at windmills.



-- 
Jim Pennino

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

Re: [ntp:questions] Can NTP sync within 1ms

[jimp]

Rob  wrote:
> j...@specsol.spam.sux.com  wrote:
 Your transmitters will have to be contained within a circle of 3.6km, 
 reduced by the timing errors in the modulation at 0.3km/microsecond.
>>> 
>>> This turns out to be not the case.  Networks like this have been operating
>>> for decades, only those were constructed using analog leased lines so
>>> there was no relation to ntp, soundcards etc.
>>
>> Just what part, given your original conditions, is not true about this?
> 
> It turns out to be working even though there are differences in path
> lengths, but for it to be working well one must not start off with a
> large difference in modulation timing.  The goal is to be within 12us.

Why?

What would you see as a timing difference given no correction?

What is your definition of "working well"?

How do you avoid picket fencing?



-- 
Jim Pennino

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

Re: [ntp:questions] Can NTP sync within 1ms

[Rob]

j...@specsol.spam.sux.com  wrote:
> Rob  wrote:
>> j...@specsol.spam.sux.com  wrote:
>>> Rob  wrote:
 j...@specsol.spam.sux.com  wrote:
>> The listeners should enjoy a smooth reception while driving around.
>> So of course there should be no time lag between the modulation signals
>> of the different transmitters.  Experts in the field tell us we should
>> be within 12us.
>
> Unless I fat fingered the calculator, that means the difference in 
> distance
> between transmitters relative to the receiver can be no more than 3.6 km.
>
> 300 meters per microsecond; it is the law...
 
 The goal is not to have 12us difference in arrival time, but to be
 within 12us for transmission time.
>>>
>>> What good does that do you?
>>>
>>> And regarding "smooth reception while driving around", have you ever heard
>>> of multipath or the capture effect?
>> 
>> Well, smooth reception must be explained as "communication is possible",
>> not with the HIFI quality expected from a broadcast station.
>> 
>> What I mean is that you can drive around and receive the signal all over
>> the place, even when you drive out of range of one transmitter into the
>> range of the next.  It works perfectly when the capture effect results
>> in reception of one transmitter, and in the area where two transmitters
>> are equal in strength it requires suitable synchronization to still have
>> good communication.
>
> Picket fencing makes it irrelevant.

This precisely makes it a requirement to synchronize the audio.
When this is not done, there will be extreme jitter in the audio which
makes it unintelligible.
What surprises me is that the audio has to be synchronized so well.
But we are just going to do that, or approach it as closely as possible.

>> I did not come up with the 12us figure, I would have guessed it a bit
>> higher.  The figure comes from different experts in the field.  The
>> people that designed and deployed such systems in the world of emergency
>> services etc.
>
> Are you sure that figure is NOT for data communications?
>
> Most "emergency services" have voice and data these days.

Emergency services don't use NBFM systems anymore.  At least not here.
The networks I am talking about were deployed between the seventies and
nineties of last century.

>> We can now try it in amateur radio because the advances in technology
>> have made things like GPSDOs and fast network connections affordable.
>
> I don't see where that is relevant to anything here.

I am ending this discussion, I only answered the question "what are you
trying to do" and I don't need to account for our experiment to you or
anyone else on this group.

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

Re: [ntp:questions] Can NTP sync within 1ms

[jimp]

Rob  wrote:
> j...@specsol.spam.sux.com  wrote:
>> Rob  wrote:
>>> j...@specsol.spam.sux.com  wrote:
> The listeners should enjoy a smooth reception while driving around.
> So of course there should be no time lag between the modulation signals
> of the different transmitters.  Experts in the field tell us we should
> be within 12us.

 Unless I fat fingered the calculator, that means the difference in distance
 between transmitters relative to the receiver can be no more than 3.6 km.

 300 meters per microsecond; it is the law...
>>> 
>>> The goal is not to have 12us difference in arrival time, but to be
>>> within 12us for transmission time.
>>
>> What good does that do you?
>>
>> And regarding "smooth reception while driving around", have you ever heard
>> of multipath or the capture effect?
> 
> Well, smooth reception must be explained as "communication is possible",
> not with the HIFI quality expected from a broadcast station.
> 
> What I mean is that you can drive around and receive the signal all over
> the place, even when you drive out of range of one transmitter into the
> range of the next.  It works perfectly when the capture effect results
> in reception of one transmitter, and in the area where two transmitters
> are equal in strength it requires suitable synchronization to still have
> good communication.

Picket fencing makes it irrelevant.

> I did not come up with the 12us figure, I would have guessed it a bit
> higher.  The figure comes from different experts in the field.  The
> people that designed and deployed such systems in the world of emergency
> services etc.

Are you sure that figure is NOT for data communications?

Most "emergency services" have voice and data these days.

> We can now try it in amateur radio because the advances in technology
> have made things like GPSDOs and fast network connections affordable.

I don't see where that is relevant to anything here.



-- 
Jim Pennino

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

Re: [ntp:questions] Can NTP sync within 1ms

[jimp]

Rob  wrote:
> Jochen Bern  wrote:
>> [Resend to list, rather than non-working(?) sender e-mail address]
>>
>> On -10.01.-28163 20:59, Rob wrote:
>>> We are setting up a co-channel diversity network.  That means multiple
>>> FM transmitters that are transmitting the same signal on the same
>>> frequency on different sites, where the receive areas partly overlap.
>>> 
>>> The listeners should enjoy a smooth reception while driving around.
>>> So of course there should be no time lag between the modulation signals
>>> of the different transmitters.  Experts in the field tell us we should
>>> be within 12us.
>>
>> I'm afraid I don't get it yet. You're trying to sync waveforms on the HF
>> side (~100 MHz?) instead of switching between two transmitters on the AF
>> side (couple kHz, with that much more leeway for the sync), a la
>> perfectly normal car radio with RDS AF and dual tuners, because ... ?
> 
> It is not an FM broadcast system, it is an amateur radio repeater system
> with wide area coverage.
> Similar systems are in use, or at least have been in use, in repeater
> systems used by emergency services, taxi companies, etc.
> 
> Of course it is possible to use different transmitters and find some
> way to switch the receivers.  It is also possible to use a mobile phone
> to communicate.
> 
> But amateur radio is about experimenting and self-education, and we just
> want to see if it can be done.  In fact, it already has been done by
> another group using a different system setup, and we want to see if it
> can be done this way as well.

It is all made irrelevant by a combination of channel bandwidth and the
capture effect.

http://en.wikipedia.org/wiki/Capture_effect

Unless there is a huge difference in transmission times, no one is going 
to notice unless they are somewhere where the signal strength of multiple
transmitters is roughly equal and then your major problem will be picket
fencing, not audio synchronization.


-- 
Jim Pennino

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

Re: [ntp:questions] Can NTP sync within 1ms

[Rob]

j...@specsol.spam.sux.com  wrote:
> Rob  wrote:
>> j...@specsol.spam.sux.com  wrote:
 The listeners should enjoy a smooth reception while driving around.
 So of course there should be no time lag between the modulation signals
 of the different transmitters.  Experts in the field tell us we should
 be within 12us.
>>>
>>> Unless I fat fingered the calculator, that means the difference in distance
>>> between transmitters relative to the receiver can be no more than 3.6 km.
>>>
>>> 300 meters per microsecond; it is the law...
>> 
>> The goal is not to have 12us difference in arrival time, but to be
>> within 12us for transmission time.
>
> What good does that do you?
>
> And regarding "smooth reception while driving around", have you ever heard
> of multipath or the capture effect?

Well, smooth reception must be explained as "communication is possible",
not with the HIFI quality expected from a broadcast station.

What I mean is that you can drive around and receive the signal all over
the place, even when you drive out of range of one transmitter into the
range of the next.  It works perfectly when the capture effect results
in reception of one transmitter, and in the area where two transmitters
are equal in strength it requires suitable synchronization to still have
good communication.

I did not come up with the 12us figure, I would have guessed it a bit
higher.  The figure comes from different experts in the field.  The
people that designed and deployed such systems in the world of emergency
services etc.

We can now try it in amateur radio because the advances in technology
have made things like GPSDOs and fast network connections affordable.

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

Re: [ntp:questions] Can NTP sync within 1ms

[Rob]

j...@specsol.spam.sux.com  wrote:
>>> Your transmitters will have to be contained within a circle of 3.6km, 
>>> reduced by the timing errors in the modulation at 0.3km/microsecond.
>> 
>> This turns out to be not the case.  Networks like this have been operating
>> for decades, only those were constructed using analog leased lines so
>> there was no relation to ntp, soundcards etc.
>
> Just what part, given your original conditions, is not true about this?

It turns out to be working even though there are differences in path
lengths, but for it to be working well one must not start off with a
large difference in modulation timing.  The goal is to be within 12us.

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

Re: [ntp:questions] Can NTP sync within 1ms

[jimp]

Rob  wrote:
> David Woolley  wrote:
>> On 27/04/14 17:28, Rob wrote:
>>> We are setting up a co-channel diversity network.  That means multiple
>>> FM transmitters that are transmitting the same signal on the same
>>> frequency on different sites, where the receive areas partly overlap.
>>
>> This problem has already been solved using COFDM (aka DAB) and it is 
>> much more tolerant of fading that is inevitable with co-channel 
>> transmitters than your system.
> 
> It is not FM broadcast, it is (NB)FM communication.

Which makes all of this even more irrelvant as communications circuits
usually bandwidth limit to around 3.5 kHz.

>>> The listeners should enjoy a smooth reception while driving around.
>>> So of course there should be no time lag between the modulation signals
>>> of the different transmitters.  Experts in the field tell us we should
>>> be within 12us.
>>
>> Your transmitters will have to be contained within a circle of 3.6km, 
>> reduced by the timing errors in the modulation at 0.3km/microsecond.
> 
> This turns out to be not the case.  Networks like this have been operating
> for decades, only those were constructed using analog leased lines so
> there was no relation to ntp, soundcards etc.

Just what part, given your original conditions, is not true about this?


-- 
Jim Pennino

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

Re: [ntp:questions] Can NTP sync within 1ms

[jimp]

Rob  wrote:
> j...@specsol.spam.sux.com  wrote:
>>> The listeners should enjoy a smooth reception while driving around.
>>> So of course there should be no time lag between the modulation signals
>>> of the different transmitters.  Experts in the field tell us we should
>>> be within 12us.
>>
>> Unless I fat fingered the calculator, that means the difference in distance
>> between transmitters relative to the receiver can be no more than 3.6 km.
>>
>> 300 meters per microsecond; it is the law...
> 
> The goal is not to have 12us difference in arrival time, but to be
> within 12us for transmission time.

What good does that do you?

And regarding "smooth reception while driving around", have you ever heard
of multipath or the capture effect?


-- 
Jim Pennino

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

Re: [ntp:questions] Attn Linux distributors - pse include PPS

[Rob]

William Unruh  wrote:
> On 2014-04-27, Rob  wrote:
>> William Unruh  wrote:
>>> But those modules give timing to one a few (5-10) usec. because of
>>> interrupt handling issues. Your shm solution would seem to me to be more
>>> than adequate for any timing requirements if they can be solved with an
>>> interrupt driven pps. 
>>
>> Well, the kernel PPS API does the timestamping in the interrupt handler
>> while my gpsd/SHM solution does timestamping in a user process that is
>> marked to be ready to run in an interrupt handler.
>
> ?? I do not think so-- the kernel has interrupt handlers which stamp the
> PPS input via interrupt routines. They hand the result to gpsd which
> puts it into an shm, if I understand correctly. Thus both the kernel and
> gpsd use the same interrupt timestamping. 

That is a later version, not the one I wrote.  It requires kernel PPS API,
which mine didn't.  That one is still used when kernel PPS API is not
available.  It uses the TIOCMIWAIT ioctl.

The GPS I use (actually a GPSDO) cannot work with gpsd.  It has 1PPS
and 10MHz outputs but no serial datastream other than some very limited
interface that can be used for monitoring.  It does not provide time/date.

So we use ntpd with a couple of network clocks and the 1PPS with the
ATOM refclock (refclock 22).  That works OK.  At least when ntpd is
compiled correctly.

>> Especially on a loaded system it can be less accurate due to scheduling.
>> I experimented with marking the process for realtime scheduling, but
>> the disadvantage is that it hangs the entire system when it goes in
>> a loop due to some bug.
>>
>> On my system the offset and jitter for kernel PPS from a professional
>> GPS receiver (Datum) are usually 1 or 2 microseconds in the ntpq display,
>> but always less than 5.
>
> Yes, that is consistant with what I found with my own interrupt handler.
> I got the feeling but have not done any real tests, that the serial port
> pps (eg
> /lib/modules/3.10.28-desktop-1.mga3/kernel/drivers/pps/clients/pps-ldisc.ko.xz)
>  
> routine was a bit more ragged.) Or is this module what you mean by
> kernel PPS? 

Yes that is what I use.  PPS timestamping in the kernel, with the PPS API.

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

Re: [ntp:questions] Can NTP sync within 1ms

[Rob]

Jochen Bern  wrote:
> [Resend to list, rather than non-working(?) sender e-mail address]
>
> On -10.01.-28163 20:59, Rob wrote:
>> We are setting up a co-channel diversity network.  That means multiple
>> FM transmitters that are transmitting the same signal on the same
>> frequency on different sites, where the receive areas partly overlap.
>> 
>> The listeners should enjoy a smooth reception while driving around.
>> So of course there should be no time lag between the modulation signals
>> of the different transmitters.  Experts in the field tell us we should
>> be within 12us.
>
> I'm afraid I don't get it yet. You're trying to sync waveforms on the HF
> side (~100 MHz?) instead of switching between two transmitters on the AF
> side (couple kHz, with that much more leeway for the sync), a la
> perfectly normal car radio with RDS AF and dual tuners, because ... ?

It is not an FM broadcast system, it is an amateur radio repeater system
with wide area coverage.
Similar systems are in use, or at least have been in use, in repeater
systems used by emergency services, taxi companies, etc.

Of course it is possible to use different transmitters and find some
way to switch the receivers.  It is also possible to use a mobile phone
to communicate.

But amateur radio is about experimenting and self-education, and we just
want to see if it can be done.  In fact, it already has been done by
another group using a different system setup, and we want to see if it
can be done this way as well.

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

Re: [ntp:questions] Attn Linux distributors - pse include PPS

[William Unruh]

On 2014-04-27, Rob  wrote:
> William Unruh  wrote:
>> But those modules give timing to one a few (5-10) usec. because of
>> interrupt handling issues. Your shm solution would seem to me to be more
>> than adequate for any timing requirements if they can be solved with an
>> interrupt driven pps. 
>
> Well, the kernel PPS API does the timestamping in the interrupt handler
> while my gpsd/SHM solution does timestamping in a user process that is
> marked to be ready to run in an interrupt handler.

?? I do not think so-- the kernel has interrupt handlers which stamp the
PPS input via interrupt routines. They hand the result to gpsd which
puts it into an shm, if I understand correctly. Thus both the kernel and
gpsd use the same interrupt timestamping. 

>
> Especially on a loaded system it can be less accurate due to scheduling.
> I experimented with marking the process for realtime scheduling, but
> the disadvantage is that it hangs the entire system when it goes in
> a loop due to some bug.
>
> On my system the offset and jitter for kernel PPS from a professional
> GPS receiver (Datum) are usually 1 or 2 microseconds in the ntpq display,
> but always less than 5.

Yes, that is consistant with what I found with my own interrupt handler.
I got the feeling but have not done any real tests, that the serial port
pps (eg
/lib/modules/3.10.28-desktop-1.mga3/kernel/drivers/pps/clients/pps-ldisc.ko.xz) 
routine was a bit more ragged.) Or is this module what you mean by
kernel PPS? 

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

Re: [ntp:questions] Can NTP sync within 1ms

[Rob]

David Woolley  wrote:
> On 27/04/14 17:28, Rob wrote:
>> We are setting up a co-channel diversity network.  That means multiple
>> FM transmitters that are transmitting the same signal on the same
>> frequency on different sites, where the receive areas partly overlap.
>
> This problem has already been solved using COFDM (aka DAB) and it is 
> much more tolerant of fading that is inevitable with co-channel 
> transmitters than your system.

It is not FM broadcast, it is (NB)FM communication.

>> The listeners should enjoy a smooth reception while driving around.
>> So of course there should be no time lag between the modulation signals
>> of the different transmitters.  Experts in the field tell us we should
>> be within 12us.
>
> Your transmitters will have to be contained within a circle of 3.6km, 
> reduced by the timing errors in the modulation at 0.3km/microsecond.

This turns out to be not the case.  Networks like this have been operating
for decades, only those were constructed using analog leased lines so
there was no relation to ntp, soundcards etc.

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

Re: [ntp:questions] Can NTP sync within 1ms

[Rob]

j...@specsol.spam.sux.com  wrote:
>> The listeners should enjoy a smooth reception while driving around.
>> So of course there should be no time lag between the modulation signals
>> of the different transmitters.  Experts in the field tell us we should
>> be within 12us.
>
> Unless I fat fingered the calculator, that means the difference in distance
> between transmitters relative to the receiver can be no more than 3.6 km.
>
> 300 meters per microsecond; it is the law...

The goal is not to have 12us difference in arrival time, but to be
within 12us for transmission time.

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

Re: [ntp:questions] Can NTP sync within 1ms

[Jochen Bern]

[Resend to list, rather than non-working(?) sender e-mail address]

On -10.01.-28163 20:59, Rob wrote:
> We are setting up a co-channel diversity network.  That means multiple
> FM transmitters that are transmitting the same signal on the same
> frequency on different sites, where the receive areas partly overlap.
> 
> The listeners should enjoy a smooth reception while driving around.
> So of course there should be no time lag between the modulation signals
> of the different transmitters.  Experts in the field tell us we should
> be within 12us.

I'm afraid I don't get it yet. You're trying to sync waveforms on the HF
side (~100 MHz?) instead of switching between two transmitters on the AF
side (couple kHz, with that much more leeway for the sync), a la
perfectly normal car radio with RDS AF and dual tuners, because ... ?

https://en.wikipedia.org/wiki/Radio_Data_System#Content_and_implementation

Anyway - if you'ld like to talk to people who apparently have experience
with syncing the HF side, at least to *some* degree, you might want to
contact the companies operating the (toll) highways in France. They also
operate radio stations with traffic announcements, and it's just *one*
frequency (107.7 MHz) all across the country (since before the time they
adopted RDS at all). I never noticed any transmitter hand-over within
any single operator's coverage (while handover from one to another, with
a completely different radio programme, is of course rather messy).

http://www.autoroutes.fr/en/FM-107-7-radio.htm

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] Can NTP sync within 1ms

[Henry Hallam]

On Apr 27, 2014 10:19 AM, "David Woolley" 
wrote:
>
> On 27/04/14 17:28, Rob wrote:
>>
>> We are setting up a co-channel diversity network.  That means multiple
>> FM transmitters that are transmitting the same signal on the same
>> frequency on different sites, where the receive areas partly overlap.
>
>
> This problem has already been solved using COFDM (aka DAB) and it is much
more tolerant of fading that is inevitable with co-channel transmitters
than your system.

DAB is a nice system but unfortunately there are parts of the world where
DAB receivers are unheard-of.

> Your transmitters will have to be contained within a circle of 3.6km,
reduced by the timing errors in the modulation at 0.3km/microsecond.

Only the distance between the receiver and all transmitters strong enough
for it to receive need be < 4 km.  The overall network can be bigger if
each transmitter is weak enough not to be heard too far away.

Of course there will still be multipath issues with destructive
interference at the carrier frequency even at much shorter distances.

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

Re: [ntp:questions] Can NTP sync within 1ms

[David Woolley]

On 27/04/14 17:28, Rob wrote:

We are setting up a co-channel diversity network.  That means multiple
FM transmitters that are transmitting the same signal on the same
frequency on different sites, where the receive areas partly overlap.


This problem has already been solved using COFDM (aka DAB) and it is 
much more tolerant of fading that is inevitable with co-channel 
transmitters than your system.


The listeners should enjoy a smooth reception while driving around.
So of course there should be no time lag between the modulation signals
of the different transmitters.  Experts in the field tell us we should
be within 12us.


Your transmitters will have to be contained within a circle of 3.6km, 
reduced by the timing errors in the modulation at 0.3km/microsecond.


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

Re: [ntp:questions] Can NTP sync within 1ms

[jimp]

Rob  wrote:
> William Unruh  wrote:
>>> The next problem is to send output to a soundcard and making it send
>>> a sample at the sampling clock edge closest to a specified time.
>>> (48kHz sampling rate corresponds to a sampling clock period of 20.8us)
>>
>> It will certainly depend on the sound card. AFAIK most have their own
>> internal oscillators, that are not adjustable. I suspect you will have
>> to build your ownsoundcard to accomplish this. 
> 
> There are soundcards for professional use that support locking of the
> sampling clock to an external source.
> 
> There is also a circuit from a French guy that generates a S/PDIF signal
> from an external reference and he claims many soundcards with S/PDIF
> can lock to that.  I need to further investigate that.
> 
>>> When that has been achieved, it of course is easy to wire up two of
>>> those systems, place them closely together, and check on a scope.
>>>
>>> It could be further improved when we can somehow lock the sampling
>>> clock to the PPS signal, so another +/- 10uS uncertainty/jitter is
>>> removed.
>>
>> 48KHz is 20us. Why are you worried about a few us? What are you trying
>> to do?
> 
> We are setting up a co-channel diversity network.  That means multiple
> FM transmitters that are transmitting the same signal on the same
> frequency on different sites, where the receive areas partly overlap.
> 
> The listeners should enjoy a smooth reception while driving around.
> So of course there should be no time lag between the modulation signals
> of the different transmitters.  Experts in the field tell us we should
> be within 12us.

Unless I fat fingered the calculator, that means the difference in distance
between transmitters relative to the receiver can be no more than 3.6 km.

300 meters per microsecond; it is the law...



-- 
Jim Pennino

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

Re: [ntp:questions] "Oneshot" time sync without risk of jumping time?

[David Woolley]

On 27/04/14 15:54, mike cook wrote:



So it looks like -g allows the step even with the tinker variable when the 
difference is really big.


Yes.  That's its purpose.  It disables the first panic.


Also -x sets a large but finite value for when ntpd will step.  (That 
value also disables the kernel discipline.)


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

Re: [ntp:questions] Can NTP sync within 1ms

[Rob]

William Unruh  wrote:
>> The next problem is to send output to a soundcard and making it send
>> a sample at the sampling clock edge closest to a specified time.
>> (48kHz sampling rate corresponds to a sampling clock period of 20.8us)
>
> It will certainly depend on the sound card. AFAIK most have their own
> internal oscillators, that are not adjustable. I suspect you will have
> to build your ownsoundcard to accomplish this. 

There are soundcards for professional use that support locking of the
sampling clock to an external source.

There is also a circuit from a French guy that generates a S/PDIF signal
from an external reference and he claims many soundcards with S/PDIF
can lock to that.  I need to further investigate that.

>> When that has been achieved, it of course is easy to wire up two of
>> those systems, place them closely together, and check on a scope.
>>
>> It could be further improved when we can somehow lock the sampling
>> clock to the PPS signal, so another +/- 10uS uncertainty/jitter is
>> removed.
>
> 48KHz is 20us. Why are you worried about a few us? What are you trying
> to do?

We are setting up a co-channel diversity network.  That means multiple
FM transmitters that are transmitting the same signal on the same
frequency on different sites, where the receive areas partly overlap.

The listeners should enjoy a smooth reception while driving around.
So of course there should be no time lag between the modulation signals
of the different transmitters.  Experts in the field tell us we should
be within 12us.

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

Re: [ntp:questions] Attn Linux distributors - pse include PPS

[Rob]

Jochen Bern  wrote:
> On -10.01.-28163 20:59, Rob wrote:
>> What I mean is that for building packages they need not only building
>> tools but also -dev packages for many libraries that are going to be
>> used by the packages being built.  There is a long list of packages that
>> one is supposed to install before even attempting to build a single
>> package from source, and then the particular package adds more requirements.
>> This timepps.h file is just one tiny little file between many other
>> .h .a and .so files.
>
> Ah, I see. So there actually are *three* areas of "installed software"
> on a build system that need to be properly set up: The stuff that makes
> the build machine itself (architecture A) run, the packages that you
> want it to produce (for architecture B), and the source/devel packages
> that those latter need only *during compilation*.
>
> FWIW, you might find this open Debian bug interesting:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691672
>
> It does not only state the problem, but also lists the proper technical
> term (Build-Depend) and an e-mail address to (supposedly) poke the
> actual package maintainers through. (And IIRC Debian is the upstream for
> a fair *lot* of distribs.)

Ah that looks good, they know what to do since in Aug 2013 mr Zehl
posted the correct diff.

Now let's hope that someone applies it...

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

Re: [ntp:questions] Attn Linux distributors - pse include PPS

[Rob]

William Unruh  wrote:
> But those modules give timing to one a few (5-10) usec. because of
> interrupt handling issues. Your shm solution would seem to me to be more
> than adequate for any timing requirements if they can be solved with an
> interrupt driven pps. 

Well, the kernel PPS API does the timestamping in the interrupt handler
while my gpsd/SHM solution does timestamping in a user process that is
marked to be ready to run in an interrupt handler.

Especially on a loaded system it can be less accurate due to scheduling.
I experimented with marking the process for realtime scheduling, but
the disadvantage is that it hangs the entire system when it goes in
a loop due to some bug.

On my system the offset and jitter for kernel PPS from a professional
GPS receiver (Datum) are usually 1 or 2 microseconds in the ntpq display,
but always less than 5.

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

Re: [ntp:questions] Can NTP sync within 1ms

[William Unruh]

On 2014-04-27, Jason Rabel  wrote:
>> First, we sync all machines to locally connected GPS receivers with
>> PPS output.  We use ntpd and kernel PPS.  This is wellknown territory.
>
>> In the ntpq -p stats this appears to bring the systems within 10us,
>> often within 2us, of the PPS signal.  We still have to find out if this
>> is reality or just output of a program.
>
> You need to look up the specs of your GPS units to see what the PPS 
> performance is spec'ed for. That uncertainty needs to be
> factored into your final figure.
>
> Likewise, are you inputting surveyed antenna coordinates at each location or 
> just letting the receiver auto-survey? If the "assumed"
> position is off that is another source of time error.

2nano sec per meter, max. And the gps units are going to self survey to
within 10m. which is 20ns max. Why in the world would they be worrying
about that when interrupt latencies are are at the microsecond level?
If you are going to be timing neutrinos from Cern to Grand Sasso, your
concern is certainly valid. But you would not be using interrupts on a 
commodity 
computer for that. 

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

Re: [ntp:questions] Can NTP sync within 1ms

[Joe Gwinn]

In article , William Unruh
 wrote:

> On 2014-04-26, Joe Gwinn  wrote:
> > In article
> ><8188ba2b01fb534a99c03d79c62ce1d80982f...@uusnwe3a.global.utcmail.com>,
> > Montgomery, Peter BIS  wrote:
> >
> >> I am new to NTP. But I have a quick question that I need to answer soon.
> >> 
> >> I would like to know whether NTP can sync between a client and a server
> >> within 1ms if the client and server are Linux applications on a simple
> >> local
> >> network ( less than 10 nodes).
> >
> > Not reliably, for a million reasons.  A better rule is 10 milliseconds,
> > and even that requires work and care.  
> 
> Well, since I have 8 machines that reliably sync from one GPS PPS driven
> machine (all using chrony) and they get time reliability of about
> 10microseconds, your experience seems a bit different than mine. 
> And how did you determine that you were only getting 10ms. As I said,
> you cannot conclude that by looking at the offsets reported by ntpd.

I've managed 7 microseconds rms in a sterile lab setup, but I would
hardly tell people that they will achieve anything like that in an
unconstrained and complex network.

We know next to nothing about the OP's network et al, so I quoted a
worst case.  With added data, we may be able to tighten the estimate. 
Or, widen it if there turns out to be something unfortunate in the
design.


> > The most reliable approach is an IRIG network.
> 
> Or put a gps pps receiver onto each  machine. 

Yes, but IRIG is simpler and cheaper, and the OP asked for synchronized
time, and did not mention any need for accurate time.  

For all we know, the OP has no access to the sky.


> > But you need to describe your problem and constraints before people can
> > give better answers.
> 
> 
> Agreed.

And this is the key.


Joe Gwinn

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

Re: [ntp:questions] Attn Linux distributors - pse include PPS

[William Unruh]

On 2014-04-27, Rob  wrote:

> Notice:
> Several years ago I wanted to sync my clock to a GPS providing PPS.
> At that time, PPS support in the kernel was only available as a set
> of patches.  You had to apply them to a kernel source tree and rebuild
> the kernel.  And I think there were several competing patchsets.
> You also needed to build a program that would actually bind the PPS
> to a device pin.
>
> Not wanting to go through all that trouble, I wrote the part of the
> gpsd program that takes the PPS info in a userspace thread and puts
> the information in an SHM segment that ntpd can use as a refclock.
> Support for PPS without having to patch or recompile existing binaries.
>
> This worked well, but lately I have been working on a project that has
> more strict timing requirements and I investigated the current state
> of things w.r.t kernel PPS.
>
> PPS support has been incorporated in the kernel.  Distributors compile
> kernels with PPS support built in, and include modules for parallel,
> serial and gpio ports.  Things are looking good.

But those modules give timing to one a few (5-10) usec. because of
interrupt handling issues. Your shm solution would seem to me to be more
than adequate for any timing requirements if they can be solved with an
interrupt driven pps. 
>
> ntpd has support for this kernel PPS in its source tree.  Availability
> of PPS API is autodetected, and ntpd refclock drivers are using it.
>
> Linux distributors compile ntpd with a (default) set of options that
> basically says: please include all refclock drivers that are supported
> on this system.  Fine!
>
> BUT STILL IT DOES NOT WORK
> Why?  Because a single file was missing during compilation.

I agree that ntpd should supply that file. It would cost nothing, unless
it is true that that file differs depending on distribution/kernel/...

>
> And when I suggest to fix that, all kinds of reasons are popping up
> why this isn't going to happen, isn't wanted, etc.
>
> I think it is a big waste of effort made by many people who contributed
> to what we now have.  Pity.

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

Re: [ntp:questions] Can NTP sync within 1ms

[William Unruh]

On 2014-04-27, Rob  wrote:
> Paul  wrote:
>> I don't know what "terribly accurate" might be to you but in the real world
>> sufficient accuracy depends on the circumstance.
>>
>> Someone should conduct an experiment.
>
> I am in a group that works on a project that needs synchronous audio
> on geographically distributed PCs.
>
> Of course there are several hurdles.
> First, we sync all machines to locally connected GPS receivers with
> PPS output.  We use ntpd and kernel PPS.  This is wellknown territory.
>
> In the ntpq -p stats this appears to bring the systems within 10us,
> often within 2us, of the PPS signal.  We still have to find out if this
> is reality or just output of a program.

reality. You can test the interrupt latencies on the machines (a few us) 

>
> The next problem is to send output to a soundcard and making it send
> a sample at the sampling clock edge closest to a specified time.
> (48kHz sampling rate corresponds to a sampling clock period of 20.8us)

It will certainly depend on the sound card. AFAIK most have their own
internal oscillators, that are not adjustable. I suspect you will have
to build your ownsoundcard to accomplish this. 

>
> When that has been achieved, it of course is easy to wire up two of
> those systems, place them closely together, and check on a scope.
>
> It could be further improved when we can somehow lock the sampling
> clock to the PPS signal, so another +/- 10uS uncertainty/jitter is
> removed.

48KHz is 20us. Why are you worried about a few us? What are you trying
to do?


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

Re: [ntp:questions] "Oneshot" time sync without risk of jumping time?

[William Unruh]

On 2014-04-27, mike cook  wrote:
>
> Le 27 avr. 2014 ? 10:49, Manuel Reimer a ?crit :
>
>> Hello,
>> 
>> I want to keep the time updated on a small Embedded Linux device.
>> 
>> The clock doesn't have to be very accurate. An offset of a few seconds is OK.
>> 
>> This small device only has Internet for a few minutes a day and I have to 
>> pay for each byte that gets transmitted, so I want to keep the traffic low.
>> 
>> My idea to solve this was to run "ntpd -xq" as soon as I have established my 
>> Internet connection.
>> 
>> The problem with this is that the time jumps if the difference is above 600s.
>> 
>> The documentation about the "-g" option says that there is a "panic 
>> threshold" which is 1000s "by default". What does "by default" mean? Does 
>> this mean that this value is configurable? If so: How?
>
>   use the tinker directive in the ntp conf file.
>
>ex. tinker panic 600
>
>> 
>> What I want ntpd to do is to exit with error status if the time difference 
>> is above the 600s limit. I don't want it to set the time forcefully (jumping 
>> time) as this may cause trouble with cronjobs running on the device.
>> 
>
> then use ntpd -gxq and it should slew up to the new panic value, exiting 
> if a correction is needed which is greater.

No, not -g. That says "don't panic-- once" and once is all he uses it
for. 

You could also run chrony constantly, taking it offline when the network
goes down, and online when it comes up and telling it, via chronyc, to
do a burst everytime it comes up. (ntp packets are very small) 

That way it will try to keep disciplining your clock over the long term,
and getting an estimate, over a few days, of the clock rate error.


>
>> Greetings,
>> 
>> Manuel
>> 
>> ___
>> 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] Attn Linux distributors - pse include PPS

[William Unruh]

On 2014-04-27, mike cook  wrote:
>
> Le 27 avr. 2014 ? 05:36, Paul a ?crit :
>
>> On Sat, Apr 26, 2014 at 5:05 PM, Paul  wrote:
>> 
>>> I think it's fair to wonder why the  NTP tar ball doesn't include
>>> timepps-Linux.h along with others they do include.
>>> 
>
>> On Sat, Apr 26, 2014 at 7:54 PM, Harlan Stenn  wrote:
>> 
>>> Is there only one version of that file that is compatible with the
>>> places NTP will be built?  ...
>>> And even if so, why should this issue cost-shift to the NTP Project?
>>> 
>> 
>> 
>> So why does the distribution include multiple, platform specific, instances
>> of timepps.h viz.
>> timepps-SCO.h
>> timepps-Solaris.h
>> timepps-SunOS.h
>
>   If you look at those, they are included because the API does not ( or 
> didn't ) exist in the OSs whereas it does for Linux so responsibility should 
> reside there.
>   IIRC, the OP was a heads up which IS useful, but complaints should go to 
> the distributers, rather than here as has been previously mentioned. 

ntpd needs timepps.h. timepps.h is only sporadically included in
distros. So ntpd should supply what it needs. It is bizarre that if the
distro does not have the API ntpd supplies the timepps, but if it does
it washes its hands of the problem? Sorry, makes no sense to me. 
Now, if each distro required a different timepps.h your argument would
make sense, but as far as I know, there is a common timepps.h that will
work on all versions of Linux. So, include it. 
Otherwise why not tell people to but the SCO or Solaris kernel
developers to include the API and refuse to include a workaround in the
ntpd code? It is the kernel's fault!
To waste thousands of people's time, to tell someone to run around to
all thousand linux distros and submit a bug report to each one, when one
could simply include yet another .h file in the code seems pretty
perverse to me. 

Now the above IS predicated on the assumption that there is a common
timepps.h file which could be used for all Linux kernels. If that is
wrong, if it really is kernel or distribution specific, then my argument fails. 

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

Re: [ntp:questions] Attn Linux distributors - pse include PPS

[Paul]

On Sun, Apr 27, 2014 at 12:57 AM, mike cook  wrote:

> If you look at those, they are included because the API does not ( or
> didn't ) exist in the OSs whereas it does for Linux



I'll admit to being largely uninformed but to me it looks like all the
complete (per the RFC) instances of timepps.h define the RFC functions in
terms of ioctl.  So I'm not yet persuaded that the kernel devs believe
their job is unfinished.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Attn Linux distributors - pse include PPS

[Jochen Bern]

On -10.01.-28163 20:59, Rob wrote:
> What I mean is that for building packages they need not only building
> tools but also -dev packages for many libraries that are going to be
> used by the packages being built.  There is a long list of packages that
> one is supposed to install before even attempting to build a single
> package from source, and then the particular package adds more requirements.
> This timepps.h file is just one tiny little file between many other
> .h .a and .so files.

Ah, I see. So there actually are *three* areas of "installed software"
on a build system that need to be properly set up: The stuff that makes
the build machine itself (architecture A) run, the packages that you
want it to produce (for architecture B), and the source/devel packages
that those latter need only *during compilation*.

FWIW, you might find this open Debian bug interesting:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691672

It does not only state the problem, but also lists the proper technical
term (Build-Depend) and an e-mail address to (supposedly) poke the
actual package maintainers through. (And IIRC Debian is the upstream for
a fair *lot* of distribs.)

But, for sake of completeness: While the Build-Depend needs to point to
whichever package contains timepps.h, the question of whether that file
*belongs* there is, I gather, rather irrelevant for ntp package brewmasters.

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] "Oneshot" time sync without risk of jumping time?

[mike cook]

Le 27 avr. 2014 à 16:19, mike cook a écrit :

> 
> Le 27 avr. 2014 à 14:59, Manuel Reimer a écrit :
> 
>> On 04/27/2014 11:37 AM, mike cook wrote:
>>>  use the tinker directive in the ntp conf file.
>>> 
>>>   ex. tinker panic 600
>> 
>> Thank you for this information, but where is this documented? At least my 
>> "man ntp.conf" doesn't know a "tinker".
> 
>   in 4.2.4p4, not yours or  in 4.2.7p319
> 
> I tried setting it and started ntpd in debug mode and didn't get any error.  
> Maybe the option has been removed. I'll do a test.
 

mike@raspberrypi ~ $ grep tinker /etc/ntp.conf
# tinker options
  tinker panic 600

Setting the date back lots


mike@raspberrypi ~ $ sudo date -u 03272014
Thu Mar 27 20:14:00 UTC 2014
mike@raspberrypi ~ $ date
Thu Mar 27 21:14:03 CET 2014
mike@raspberrypi ~ $ sudo /usr/bin/ntpd -c /etc/ntp.conf -gxq
27 Mar 21:14:18 ntpd[3436]: ntpd 4.2.7p319@1.2483 Tue May 28 11:26:22 UTC 2013 
(2): Starting
27 Mar 21:14:18 ntpd[3436]: proto: precision = 2.000 usec (-19)
27 Mar 21:14:18 ntpd[3436]: Listen and drop on 0 v4wildcard 0.0.0.0:123
27 Mar 21:14:18 ntpd[3436]: Listen normally on 1 lo 127.0.0.1:123
27 Mar 21:14:18 ntpd[3436]: Listen normally on 2 eth0 192.168.1.15:123
27 Mar 21:14:18 ntpd[3436]: peers refreshed
27 Mar 21:14:18 ntpd[3436]: Listening on routing socket on fd #19 for interface 
updates
27 Mar 21:14:18 ntpd[3436]: refclock_atom: /dev/pps0: No such file or directory
27 Mar 21:14:18 ntpd[3436]: 127.127.22.0 local addr 127.0.0.1 -> 
27 Apr 16:15:38 ntpd[3436]: ntpd: time set +2656870.060204 s
ntpd: time set +2656870.060204s

So it looks like -g allows the step even with the tinker variable when the 
difference is really big.

Setting date back  a little

mike@raspberrypi ~ $ sudo date -u 042714252014.20
Sun Apr 27 14:25:20 UTC 2014
mike@raspberrypi ~ $ date
Sun Apr 27 16:25:26 CEST 2014
mike@raspberrypi ~ $ sudo /usr/bin/ntpd -c /etc/ntp.conf -gxq
27 Apr 16:26:04 ntpd[3518]: ntpd 4.2.7p319@1.2483 Tue May 28 11:26:22 UTC 2013 
(2): Starting
27 Apr 16:26:04 ntpd[3518]: proto: precision = 2.000 usec (-19)
27 Apr 16:26:04 ntpd[3518]: Listen and drop on 0 v4wildcard 0.0.0.0:123
27 Apr 16:26:04 ntpd[3518]: Listen normally on 1 lo 127.0.0.1:123
27 Apr 16:26:04 ntpd[3518]: Listen normally on 2 eth0 192.168.1.15:123
27 Apr 16:26:04 ntpd[3518]: peers refreshed
27 Apr 16:26:04 ntpd[3518]: Listening on routing socket on fd #19 for interface 
updates
27 Apr 16:26:04 ntpd[3518]: refclock_atom: /dev/pps0: No such file or directory
27 Apr 16:26:04 ntpd[3518]: 127.127.22.0 local addr 127.0.0.1 -> 
27 Apr 16:26:14 ntpd[3518]: ntpd: time slew +107.943014 s
ntpd: time slew +107.943014s

   slews fine , this is a normal case

setting date > panicgate time and just using -xq

mike@raspberrypi ~ $ sudo date -u 042714152014.20
Sun Apr 27 14:15:20 UTC 2014
mike@raspberrypi ~ $ sudo /usr/bin/ntpd -c /etc/ntp.conf -xq
27 Apr 16:15:31 ntpd[3533]: ntpd 4.2.7p319@1.2483 Tue May 28 11:26:22 UTC 2013 
(2): Starting
27 Apr 16:15:31 ntpd[3533]: proto: precision = 2.000 usec (-19)
27 Apr 16:15:31 ntpd[3533]: Listen and drop on 0 v4wildcard 0.0.0.0:123
27 Apr 16:15:31 ntpd[3533]: Listen normally on 1 lo 127.0.0.1:123
27 Apr 16:15:31 ntpd[3533]: Listen normally on 2 eth0 192.168.1.15:123
27 Apr 16:15:31 ntpd[3533]: peers refreshed
27 Apr 16:15:31 ntpd[3533]: Listening on routing socket on fd #19 for interface 
updates
27 Apr 16:15:31 ntpd[3533]: refclock_atom: /dev/pps0: No such file or directory
27 Apr 16:15:31 ntpd[3533]: 127.127.22.0 local addr 127.0.0.1 -> 
mike@raspberrypi ~ $ date
Sun Apr 27 16:15:46 CEST 2014
mike@raspberrypi ~ $ ntpdate -d muon
27 Apr 16:17:18 ntpdate[3540]: ntpdate 4.2.7p319@1.2483 Tue May 28 11:26:37 UTC 
2013 (2)

27 Apr 16:17:25 ntpdate[3540]: step time server 192.168.1.4 offset 992.846341 
sec
mike@raspberrypi ~ $ 

So it looks like ntpd made no action with the tinker at its new value but less 
than the default of 1000s

 Not sure this covers all cases.


> 
>> 
>> $ ntpd --version
>> ntpd 4.2.6p5
>> ntpd 4.2.6p5@1.2349-o Tue Mar 11 04:36:06 UTC 2014 (1)
>> 
>> ___
>> 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
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] "Oneshot" time sync without risk of jumping time?

[mike cook]

Le 27 avr. 2014 à 14:59, Manuel Reimer a écrit :

> On 04/27/2014 11:37 AM, mike cook wrote:
>>   use the tinker directive in the ntp conf file.
>> 
>>ex. tinker panic 600
> 
> Thank you for this information, but where is this documented? At least my 
> "man ntp.conf" doesn't know a "tinker".

   in 4.2.4p4, not yours or  in 4.2.7p319

I tried setting it and started ntpd in debug mode and didn't get any error.  
Maybe the option has been removed. I'll do a test.

> 
> $ ntpd --version
> ntpd 4.2.6p5
> ntpd 4.2.6p5@1.2349-o Tue Mar 11 04:36:06 UTC 2014 (1)
> 
> ___
> 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

[ntp:questions] What is up with utcnist.colorado.edu ???

[Jason Rabel]

I noticed yesterday morning that my time dispersion suddenly tightened up on my 
server... Odd...

http://www.rabel.org/ntp/graph_dispersion.png

(Sorry for the jump at the end, that is when I restarted it earlier this 
morning.)

At first I thought maybe NTP switched to a different server, so I logged in and 
noticed a couple weird things:

 remote   refid  st t when poll reach delay offset jitter
=
-imap.mail.rice. 10.64.99.17  2 u  432  512  377  1.768 -0.049  1.766
-clepsydra.dec.c .GPS.1 u  309  512  377 46.961 -0.280  0.005
+ntp.okstate.edu .GPS.1 u  334  512  377 23.210  0.064  0.375
-ntp.tmc.edu 10.22.24.11  2 u  360  512  377 11.921  0.522  0.318
*india.colorado. .NIST.   1 u   28   64  377 20.556  0.051  0.730
+ntp.quintex.com .CDMA.   1 u  383  512  377 22.333 -0.145  0.041

utcnist.colorado.edu (aka india.colorado.edu) dropped its poll time down to 
64s? But also the refid changed from ACTS to NIST?

I just restarted my NTP server this morning, and for some reason it's still 
keeping that one server @ 64s?

Is there something I can do to dig deeper and find out why it's doing that? I 
didn't make any changes to my config or to my server.
The server lines in NTP look like:

server ntp.rice.edu maxpoll 9
server clepsydra.dec.com maxpoll 9
server ntp.okstate.edu maxpoll 9
server ntp.tmc.edu maxpoll 9
server utcnist.colorado.edu maxpoll 9
server ntp.quintex.com maxpoll 9

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

Re: [ntp:questions] "Oneshot" time sync without risk of jumping time?

[Jason Rabel]

> I want to keep the time updated on a small Embedded Linux device.
>
> The clock doesn't have to be very accurate. An offset of a few seconds 
> is OK.
>
> This small device only has Internet for a few minutes a day and I have 
> to pay for each byte that gets transmitted, so I want to keep the 
> traffic low.

Manuel,

If you want to keep track of time better without resorting to the Internet as 
much you could go a couple different routes.

1. Add a GPS module, preferably with a PPS output to your device. That will 
give you accurate time 24/7. However, you would need a
GPS antenna and visible sky access. GPS modules are so small and low-power, 
it's usually not too difficult to cram them into
embedded cases and leech power from the main board.

2. Replace the cheap crystal oscillator on the embedded device with a better 
TCXO or OCXO.


If you wanted to make a little bit of a jump in size and power you could use a 
Rubidium module, either to replace the device's
oscillator, or use as a PPS source.


Just some thoughts...

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

Re: [ntp:questions] Can NTP sync within 1ms

[Jason Rabel]

> First, we sync all machines to locally connected GPS receivers with
> PPS output.  We use ntpd and kernel PPS.  This is wellknown territory.

> In the ntpq -p stats this appears to bring the systems within 10us,
> often within 2us, of the PPS signal.  We still have to find out if this
> is reality or just output of a program.

You need to look up the specs of your GPS units to see what the PPS performance 
is spec'ed for. That uncertainty needs to be
factored into your final figure.

Likewise, are you inputting surveyed antenna coordinates at each location or 
just letting the receiver auto-survey? If the "assumed"
position is off that is another source of time error.



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

Re: [ntp:questions] Attn Linux distributors - pse include PPS

[Rob]

Jochen Bern  wrote:
> On -10.01.-28163 20:59, Rob wrote:
>> Apparently there is unresolved discussion whether a .h describing a
>> PPS API belongs in the set of kernel include files or in a separate
>> package.
>
> There is? Can't say I've ever dealt with PPS, but *if* this .h provides
> the necessary information that *several* pieces of userland software
> need to use a kernel API, with the details/version of that API tied to
> the underlying kernel version and nothing else, then there should be
> only three kinds of package suitable to provide that .h:
> a) the kernel itself (i.e., always present),
> b) the package providing the kernel module providing the API (*if* made
>into a module for the distributed kernel), or
> c) a hypothetical "devel" package that provides the .h, but *not* some
>set of userland utilities on top unless they're strictly necessary
>(e.g., to "configure" the API in some way before it can be used).

I fully agree with that.
(I wondered why the .h file is in package pps-tools and not pps-tools-dev
or in the kernel include file set)

> Of course, if there's some history of this API's development that needs
> to be taken into account for compatibility reasons, things can get ...
> complicated. There's no such thing as 'if [ -f foo.h ]; then #include
>  ; else #include "my_foo.h"' (post-./configure) ...

There apparently is some confusion whether timepps.h should be in
/usr/include or /usr/include/sys but the ./configure for ntpd already
handles that.

>> But the separate package pps-tools which includes this file already
>> exists.
>
> I wonder whether we can take the package description:
>   https://packages.debian.org/de/sid/pps-tools
> as an actual declaration of *intent* from Debian to keep the .h there.

LinuxPPS support tools and headers

This package includes the necessary headers for using LinuxPPS
PPSAPI kernel interface in user-space applications and several
support tools:

 * ppstest: PPSAPI interface tester
 * ppsldisc: setup correct RS232 line discipline
 * ppswatch: continuously print PPS timestamps
 * ppsctl: PPS device manager
 * ppsfind: find pps device by name

Apparently they realize that they have mixed up two things in one package.
But those tools are minute in size and will not disturb anything.

>> I don't understand why this is a problem that can be fixed in a minute.
>> There must be TENS of packages that have to be installed on the build
>> machine to successfully build the binaries in the distribution.
>> Compilers, linkers, packaging tools, libraries, etc etc etc.
>> 
>> Can't they add just one simple package to that?
>
> Well *there* you're confusing the software installed on it *to make it a
> build machine* and the packages installed so as to *get built*. Imagine
> cross-compiling being involved and you'll see how one needs to be kept
> separate from the other.

What I mean is that for building packages they need not only building
tools but also -dev packages for many libraries that are going to be
used by the packages being built.  There is a long list of packages that
one is supposed to install before even attempting to build a single
package from source, and then the particular package adds more requirements.
This timepps.h file is just one tiny little file between many other
.h .a and .so files.

> I'd imagine that the folks dealing with embedded devices would have a
> couple choice words about forcing the entire pps-tools into *every*
> installation just so as to make the PPSAPI available, maybe even the IT
> security people (particularly if there's set[ug]id involved with them).

There isn't:
ls -l /usr/bin/pps*
-rwxr-xr-x 1 root root 10672 May 25  2012 /usr/bin/ppsctl
-rwxr-xr-x 1 root root   298 May 25  2012 /usr/bin/ppsfind
-rwxr-xr-x 1 root root 10352 May 25  2012 /usr/bin/ppstest
-rwxr-xr-x 1 root root 10576 May 25  2012 /usr/bin/ppswatch

I am not forcing anything upon embedded devices, it may even be that
those devices don't support the PPS API.  I only suggest that the
file required to enable PPS support is installed on systems used for
building the binaries, so nptd will be compiled with PPS support in
environments where this is available.

Notice:
Several years ago I wanted to sync my clock to a GPS providing PPS.
At that time, PPS support in the kernel was only available as a set
of patches.  You had to apply them to a kernel source tree and rebuild
the kernel.  And I think there were several competing patchsets.
You also needed to build a program that would actually bind the PPS
to a device pin.

Not wanting to go through all that trouble, I wrote the part of the
gpsd program that takes the PPS info in a userspace thread and puts
the information in an SHM segment that ntpd can use as a refclock.
Support for PPS without having to patch or recompile existing binaries.

This worked well, but lately I have been working on a project that has
more strict t

Re: [ntp:questions] "Oneshot" time sync without risk of jumping time?

[Manuel Reimer]

On 04/27/2014 11:37 AM, mike cook wrote:

   use the tinker directive in the ntp conf file.

ex. tinker panic 600


Thank you for this information, but where is this documented? At least 
my "man ntp.conf" doesn't know a "tinker".


$ ntpd --version
ntpd 4.2.6p5
ntpd 4.2.6p5@1.2349-o Tue Mar 11 04:36:06 UTC 2014 (1)


 then use ntpd -gxq and it should slew up to the new panic value, exiting 
if a correction is needed which is greater.


The man page says:

| Normally, ntpd exits with a message to the system log if the offset
| exceeds the panic threshold, which is 1000 s by default.

So are you sure I need the "-g" switch if the normal behaviour is to 
exit if the offset exceeds the panic threshold?


Greetings,

Manuel

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

Re: [ntp:questions] Can NTP sync within 1ms

[Charles Elliott]

  I use Windows 8.1 and regularly see offsets of less than 1 ms.  

Right now the offset is -0.105 and the jitter is 0.028.  Twas not 

always thus; several factors contributed to these results:

 

1. Use of Gigabyte Ethernet on the LAN, and the LAN is lightly loaded.  

 

2. A high speed Internet connection; either 15 Mbps or about 28 

   Mbps will improve accuracy because the delays between your 

   LAN timer server and the Internet time servers are more consistent 

   and more than halved WRT to a 1-3 Mbps connection.

 

3.  The NTP client and LAN server is on a computer that runs FreeNAS, 

which is lightly loaded.  FreeNAS runs on FreeBSD.  Anecdotally, 

NTPD serves more accurate time on FreeBSD.

 

4. The ISP router to which you are connected really matters.  

   If that router is congested so that delays through it vary by time 

   of day, or increase greatly every time a neighbor downloads a movie 

   or other long file, then you will serve widely varying time to the LAN.

 

5. The Internet Stratum 2 or 1 time servers you choose should be close-by 

   (50-75 miles) and lightly loaded.  If your LAN time server accesses 

   time from a heavily loaded network and/or server, or the servers are 

   more than 50-75 miles away, there is little hope of serving time with

   low jitter.  You can find a list of U.S. Government time servers and 

   their status by searching for "NIST time servers," and of course 

   there is a complete list of servers on www.ntp.org.

 

 

Charles Elliott

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

Re: [ntp:questions] Attn Linux distributors - pse include PPS

[Jochen Bern]

On -10.01.-28163 20:59, Rob wrote:
> Apparently there is unresolved discussion whether a .h describing a
> PPS API belongs in the set of kernel include files or in a separate
> package.

There is? Can't say I've ever dealt with PPS, but *if* this .h provides
the necessary information that *several* pieces of userland software
need to use a kernel API, with the details/version of that API tied to
the underlying kernel version and nothing else, then there should be
only three kinds of package suitable to provide that .h:
a) the kernel itself (i.e., always present),
b) the package providing the kernel module providing the API (*if* made
   into a module for the distributed kernel), or
c) a hypothetical "devel" package that provides the .h, but *not* some
   set of userland utilities on top unless they're strictly necessary
   (e.g., to "configure" the API in some way before it can be used).

Of course, if there's some history of this API's development that needs
to be taken into account for compatibility reasons, things can get ...
complicated. There's no such thing as 'if [ -f foo.h ]; then #include
 ; else #include "my_foo.h"' (post-./configure) ...

> But the separate package pps-tools which includes this file already
> exists.

I wonder whether we can take the package description:
https://packages.debian.org/de/sid/pps-tools
as an actual declaration of *intent* from Debian to keep the .h there.

> I don't understand why this is a problem that can be fixed in a minute.
> There must be TENS of packages that have to be installed on the build
> machine to successfully build the binaries in the distribution.
> Compilers, linkers, packaging tools, libraries, etc etc etc.
> 
> Can't they add just one simple package to that?

Well *there* you're confusing the software installed on it *to make it a
build machine* and the packages installed so as to *get built*. Imagine
cross-compiling being involved and you'll see how one needs to be kept
separate from the other.

I'd imagine that the folks dealing with embedded devices would have a
couple choice words about forcing the entire pps-tools into *every*
installation just so as to make the PPSAPI available, maybe even the IT
security people (particularly if there's set[ug]id involved with them).

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] Attn Linux distributors - pse include PPS

[Rob]

mike cook  wrote:
>
> Le 27 avr. 2014 à 12:28, Rob a écrit :
>
>> mike cook  wrote:
>>>  If you look at those, they are included because the API does not ( or 
>>> didn't ) exist in the OSs whereas it does for Linux so responsibility 
>>> should reside there.
>>>  IIRC, the OP was a heads up which IS useful, but complaints should go to 
>>> the distributers, rather than here as has been previously mentioned. 
>> 
>> That is very clear to me, but do you know about a better point of
>> contact for "the distributors"?
>> 
>> E.g. is there a mailinglist or newsgroup where all those distributors
>> are reading so I don't need to create accounts on a zillion different
>> bugzillas and file a bug there?
>
>I very much doubt it. I tried to see what support ubuntu were offering and 
> when wanting to ask a Q, got directed to a launchpad login page.
>So it sort of depends on how much you want a fix! I feel for you. 

In fact I don't need a fix at all.  I already solved my problem.
I only want to help the community so this error can be removed in
future products.  You know, the always acclaimed strong point of open
source projects: anyone can hunt for errors, correct them and the product
will be better.
When they don't want to listen, too bad.  Maybe it is not like that
after all.

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

Re: [ntp:questions] Attn Linux distributors - pse include PPS

[David Woolley]

On 27/04/14 11:28, Rob wrote:

is there a mailinglist or newsgroup where all those distributors
are reading so I don't need to create accounts on a zillion different
bugzillas and file a bug there?


You are still going to have to submit the individual bug reports as it 
will be such a minor issue to the distributors that, even if they do see 
it, they will forget about it unless it is in their issue tracking system.


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

Re: [ntp:questions] Attn Linux distributors - pse include PPS

[mike cook]

Le 27 avr. 2014 à 12:28, Rob a écrit :

> mike cook  wrote:
>>  If you look at those, they are included because the API does not ( or 
>> didn't ) exist in the OSs whereas it does for Linux so responsibility should 
>> reside there.
>>  IIRC, the OP was a heads up which IS useful, but complaints should go to 
>> the distributers, rather than here as has been previously mentioned. 
> 
> That is very clear to me, but do you know about a better point of
> contact for "the distributors"?
> 
> E.g. is there a mailinglist or newsgroup where all those distributors
> are reading so I don't need to create accounts on a zillion different
> bugzillas and file a bug there?

   I very much doubt it. I tried to see what support ubuntu were offering and 
when wanting to ask a Q, got directed to a launchpad login page.
   So it sort of depends on how much you want a fix! I feel for you. 

> 
> So far it appears to affect at least openSUSE, Ubuntu and probably Debian.
> 
> ___
> 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] Can NTP sync within 1ms

[Rob]

Paul  wrote:
> I don't know what "terribly accurate" might be to you but in the real world
> sufficient accuracy depends on the circumstance.
>
> Someone should conduct an experiment.

I am in a group that works on a project that needs synchronous audio
on geographically distributed PCs.

Of course there are several hurdles.
First, we sync all machines to locally connected GPS receivers with
PPS output.  We use ntpd and kernel PPS.  This is wellknown territory.

In the ntpq -p stats this appears to bring the systems within 10us,
often within 2us, of the PPS signal.  We still have to find out if this
is reality or just output of a program.

The next problem is to send output to a soundcard and making it send
a sample at the sampling clock edge closest to a specified time.
(48kHz sampling rate corresponds to a sampling clock period of 20.8us)

When that has been achieved, it of course is easy to wire up two of
those systems, place them closely together, and check on a scope.

It could be further improved when we can somehow lock the sampling
clock to the PPS signal, so another +/- 10uS uncertainty/jitter is
removed.

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

Re: [ntp:questions] Attn Linux distributors - pse include PPS

[Rob]

Paul  wrote:
> On Sat, Apr 26, 2014 at 6:30 PM, Rob  wrote:
>
>> Can't they add just one simple package to that?
>
>
>
> Well pps-tools is clearly special.  E.g. it's no longer advertised for 12.04

Well, it is for Ubuntu 14.04 LTS

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

Re: [ntp:questions] Attn Linux distributors - pse include PPS

[Rob]

mike cook  wrote:
>   If you look at those, they are included because the API does not ( or 
> didn't ) exist in the OSs whereas it does for Linux so responsibility should 
> reside there.
>   IIRC, the OP was a heads up which IS useful, but complaints should go to 
> the distributers, rather than here as has been previously mentioned. 

That is very clear to me, but do you know about a better point of
contact for "the distributors"?

E.g. is there a mailinglist or newsgroup where all those distributors
are reading so I don't need to create accounts on a zillion different
bugzillas and file a bug there?

So far it appears to affect at least openSUSE, Ubuntu and probably Debian.

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

Re: [ntp:questions] "Oneshot" time sync without risk of jumping time?

[mike cook]

Le 27 avr. 2014 à 10:49, Manuel Reimer a écrit :

> Hello,
> 
> I want to keep the time updated on a small Embedded Linux device.
> 
> The clock doesn't have to be very accurate. An offset of a few seconds is OK.
> 
> This small device only has Internet for a few minutes a day and I have to pay 
> for each byte that gets transmitted, so I want to keep the traffic low.
> 
> My idea to solve this was to run "ntpd -xq" as soon as I have established my 
> Internet connection.
> 
> The problem with this is that the time jumps if the difference is above 600s.
> 
> The documentation about the "-g" option says that there is a "panic 
> threshold" which is 1000s "by default". What does "by default" mean? Does 
> this mean that this value is configurable? If so: How?

  use the tinker directive in the ntp conf file.

   ex. tinker panic 600

> 
> What I want ntpd to do is to exit with error status if the time difference is 
> above the 600s limit. I don't want it to set the time forcefully (jumping 
> time) as this may cause trouble with cronjobs running on the device.
> 

then use ntpd -gxq and it should slew up to the new panic value, exiting if 
a correction is needed which is greater.

> Greetings,
> 
> Manuel
> 
> ___
> 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

[ntp:questions] "Oneshot" time sync without risk of jumping time?

[Manuel Reimer]

Hello,

I want to keep the time updated on a small Embedded Linux device.

The clock doesn't have to be very accurate. An offset of a few seconds 
is OK.


This small device only has Internet for a few minutes a day and I have 
to pay for each byte that gets transmitted, so I want to keep the 
traffic low.


My idea to solve this was to run "ntpd -xq" as soon as I have 
established my Internet connection.


The problem with this is that the time jumps if the difference is above 
600s.


The documentation about the "-g" option says that there is a "panic 
threshold" which is 1000s "by default". What does "by default" mean? 
Does this mean that this value is configurable? If so: How?


What I want ntpd to do is to exit with error status if the time 
difference is above the 600s limit. I don't want it to set the time 
forcefully (jumping time) as this may cause trouble with cronjobs 
running on the device.


Greetings,

Manuel

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