Re: [ntp:questions] ntpd: time reset problem

[Unruh]

David Lord  writes:

>David Lord wrote:

>> Below are values for offset and jitter from polls at
>> 30 min intervals.
>> 
>>   BR-304 gps18x-lvc gps18x-lvc
>>  rmcrmcrmc+pps
>>polls  offset  polls  offset  polls  offset
>>   % n   (ms) % n   (ms) % n   (ms)
>>  5090   9.235127   0.075476  0.002
>>  95   170  53.029249   0.1699   140  0.005
>>  99.5 178 435.84   10053   0.20   100   141  0.006
>> 
>> Problem with BR-304 was lack of sensitivity and being
>> unable to keep sufficient satellites in view, even
>> though positioned with slightly better view of sky than
>> the Garmin.

>Oops again since I'd deleted jitter results as I'd missed sorting
>them separate from the offsets. I'll put up a link to full table
>of results, once I've finished trying various sources and also
>settled on a reasonably consistent method for showing results.
>These can even include those from when using chrony with
>demand dial.

>Anyway here are what I have so far:

>Source Polls   % offset jitter   % offset jitter   % offset jitter
>   @30min   (ms)   (ms)   (ms)   (ms)   (ms)   (ms)
>(1)  141  54  0.002 99  0.005 100 0.006
>(2)  100  51  0.07  92  0.16  100 0.20
>(3)  179  50  9.23  95  53.0299.5 435.8
>(4)  203  50  0.185  0.086  95  0.642  0.255 99.5 1.111  0.488
>(5)   53  50  0.165  0.070  95  0.621  0.246 99.5 0.673  0.333
>(6)  164  50  1.928 95  9.162  99 21.48
>(7)  174  50  0.847 95  2.548  99 6.548

Your number 3 is really terrible. That gps should not be delivering the
time if it cannot lock on to enough sattelites. To deliver times that
are 1/2 sec out is really pretty terrible. 


>VIA EPIA C3-600
>NetBSD 4.1/4.99x/5.0 then 5.0.1
>(1) GPS_NMEAgps18x-lvc + rmc + pps
>(2) GPS_NMEAgps18x-lvc + rmc

What is rmc?


>(3) GPS_NMEAgs-br-304  + rmc
>(4) SHM MSF + serial + "radioclkd2 -s timepps tty00:-dcd"
>(5) SHM + PPS   MSF + serial + "radioclkd2 -s poll tty00:-dsr"
>(6) PARSE   DCF77 + serial
>(7) SHM DCF77 + serial + radioclkd2 + SHM
> (not sure if using timepps kernel)


>I didn't need serial-usb until very recently as all pcs here
>except new netbook have serial port so a converter wasn't
>needed when I tried out the GPS modules. I can't get converters
>to work reliably from ttl out of either Conrad module or my
>PPS extractor monostable both used for (5) above. I suspect a
>ttl to rs232 conversion is needed or some simple hack.

The problem is the interrupt. There is no way to deliver an interrupt to
usb AFAIK. From what I understant, seems that there is random latency in the
 usb system as well.



>David

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

Re: [ntp:questions] ntpd: time reset problem

[David Lord]

Unruh wrote:
> David Lord  writes:
> 
>> David Lord wrote:
> 
>>> Below are values for offset and jitter from polls at
>>> 30 min intervals.
>>>
>>>   BR-304 gps18x-lvc gps18x-lvc
>>>  rmcrmcrmc+pps
>>>polls  offset  polls  offset  polls  offset
>>>   % n   (ms) % n   (ms) % n   (ms)
>>>  5090   9.235127   0.075476  0.002
>>>  95   170  53.029249   0.1699   140  0.005
>>>  99.5 178 435.84   10053   0.20   100   141  0.006
>>>
>>> Problem with BR-304 was lack of sensitivity and being
>>> unable to keep sufficient satellites in view, even
>>> though positioned with slightly better view of sky than
>>> the Garmin.
> 
>> Oops again since I'd deleted jitter results as I'd missed sorting
>> them separate from the offsets. I'll put up a link to full table
>> of results, once I've finished trying various sources and also
>> settled on a reasonably consistent method for showing results.
>> These can even include those from when using chrony with
>> demand dial.
> 
>> Anyway here are what I have so far:
> 
>> Source Polls   % offset jitter   % offset jitter   % offset jitter
>>   @30min   (ms)   (ms)   (ms)   (ms)   (ms)   (ms)
>> (1)  141  54  0.002 99  0.005 100 0.006
>> (2)  100  51  0.07  92  0.16  100 0.20
>> (3)  179  50  9.23  95  53.0299.5 435.8
>> (4)  203  50  0.185  0.086  95  0.642  0.255 99.5 1.111  0.488
>> (5)   53  50  0.165  0.070  95  0.621  0.246 99.5 0.673  0.333
>> (6)  164  50  1.928 95  9.162  99 21.48
>> (7)  174  50  0.847 95  2.548  99 6.548
> 
> Your number 3 is really terrible. That gps should not be delivering the
> time if it cannot lock on to enough sattelites. To deliver times that
> are 1/2 sec out is really pretty terrible. 
> 
> 
>> VIA EPIA C3-600
>> NetBSD 4.1/4.99x/5.0 then 5.0.1
>> (1) GPS_NMEAgps18x-lvc + rmc + pps
>> (2) GPS_NMEAgps18x-lvc + rmc
> 
> What is rmc?

NMEA output is a whole bunch of sentences giving different data
and these can be split over more than a second (at default bps).

RMC is just one of the outputs that gives sufficient data for
the driver so setting the gps to only give minimal output
might be helpful (or not). The gps needs command string to
set required output sentences. On rollover any that cant fit
in a single second are split over two or more seconds.

RMC = recommended minimum
GSV = satellites in view

.

> 
>> I didn't need serial-usb until very recently as all pcs here
>> except new netbook have serial port so a converter wasn't
>> needed when I tried out the GPS modules. I can't get converters
>> to work reliably from ttl out of either Conrad module or my
>> PPS extractor monostable both used for (5) above. I suspect a
>> ttl to rs232 conversion is needed or some simple hack.

> The problem is the interrupt. There is no way to deliver an interrupt to
> usb AFAIK. From what I understant, seems that there is random latency in the
>  usb system as well.

Thanks I'd already got that pps was probably out from your
previous post. I can't even get data through the link though but
I should have mentioned a standalone modem is seen ok, but I've
not tried a dialout, just AT commands. From using mobile
broadband over usb with ntpd I can see there is a problem with
delays but I'm happy to get some numbers from radioclocks for
comparison. My MSF setup has sufficient outputs to steal from
and generate -5V for a better rs232 output if that's what's
needed.

Off topic even more, I'd setup my PPS extractor using sig-gen
and 'scope but when tried it was way off (aliasing?). The
radioclkd2 debug mode made setup of 950ms pulses very easy.
My old 'scope had 4sec long persistence phosphor and many
seconds timebase which would also have been a big help now,
but 4kV and 1.5kV supplies to crt and 300V for line output
valves all naked on bench are probably not allowed now :-(

 Jonathan Buzzard


 and Jon Atkins



David

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

Re: [ntp:questions] ntpd: time reset problem

[David Lord]

David Lord wrote:

> Below are values for offset and jitter from polls at
> 30 min intervals.
> 
>   BR-304 gps18x-lvc gps18x-lvc
>  rmcrmcrmc+pps
>polls  offset  polls  offset  polls  offset
>   % n   (ms) % n   (ms) % n   (ms)
>  5090   9.235127   0.075476  0.002
>  95   170  53.029249   0.1699   140  0.005
>  99.5 178 435.84   10053   0.20   100   141  0.006
> 
> Problem with BR-304 was lack of sensitivity and being
> unable to keep sufficient satellites in view, even
> though positioned with slightly better view of sky than
> the Garmin.

Oops again since I'd deleted jitter results as I'd missed sorting
them separate from the offsets. I'll put up a link to full table
of results, once I've finished trying various sources and also
settled on a reasonably consistent method for showing results.
These can even include those from when using chrony with
demand dial.

Anyway here are what I have so far:

Source Polls   % offset jitter   % offset jitter   % offset jitter
   @30min   (ms)   (ms)   (ms)   (ms)   (ms)   (ms)
(1)  141  54  0.002 99  0.005 100 0.006
(2)  100  51  0.07  92  0.16  100 0.20
(3)  179  50  9.23  95  53.0299.5 435.8
(4)  203  50  0.185  0.086  95  0.642  0.255 99.5 1.111  0.488
(5)   53  50  0.165  0.070  95  0.621  0.246 99.5 0.673  0.333
(6)  164  50  1.928 95  9.162  99 21.48
(7)  174  50  0.847 95  2.548  99 6.548

VIA EPIA C3-600
NetBSD 4.1/4.99x/5.0 then 5.0.1
(1) GPS_NMEAgps18x-lvc + rmc + pps
(2) GPS_NMEAgps18x-lvc + rmc
(3) GPS_NMEAgs-br-304  + rmc
(4) SHM MSF + serial + "radioclkd2 -s timepps tty00:-dcd"
(5) SHM + PPS   MSF + serial + "radioclkd2 -s poll tty00:-dsr"
(6) PARSE   DCF77 + serial
(7) SHM DCF77 + serial + radioclkd2 + SHM
 (not sure if using timepps kernel)


I didn't need serial-usb until very recently as all pcs here
except new netbook have serial port so a converter wasn't
needed when I tried out the GPS modules. I can't get converters
to work reliably from ttl out of either Conrad module or my
PPS extractor monostable both used for (5) above. I suspect a
ttl to rs232 conversion is needed or some simple hack.

David

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

Re: [ntp:questions] ntpd: time reset problem

[David Lord]

Unruh wrote:
> David Lord  writes:
> 
>> James Browning wrote:
>>> On Sep 17, 10:52 pm, "David J Taylor" >> this-part.nor-this.co.uk.invalid> wrote:
 Don't worry about trees - a modern GPS such as the GPS 18x LVC is very
 sensitive, and can work with a lot of obscuration.  Although my GPS 18 LVC
 is sitting on the roof, the GPS 18x LVC works just as well sitting in a
 room on the top floor of the house.
>>> I have a SiRF star III based USB dongle (US GlobalSat BU-353)
>>> that I got a location off of in a basement room about 6 feet from the
>>> window. currently it's attached to box whos' ntpd crashes every time
>>> I
>>> mention it. I think it's talking in the binary mode and the kernel
>>> device
>>> is tuck at the wrong speed. (I probably just need to restart it.)
> 
>> You can check with minicom or similar as to output. I used
>> Telix from DOS with my BR304 to set to just give a single
>> RMC sentence per second output. The codes needed to switch
>> modes were in the br304 manual I downloaded.
> 
>> Having said that the br304 is now in pieces to be explored
>> with scope probe in case it's possible to locate any signal
>> usable for ntp. Best I had was +/- 0.5 sec but it is much
>> less sensitive than the Garmin GPS18x-LVC that early in year
>> maintained an offset within 4us (that's until sats in view
>> reduced by tree growth so it became unusable).
> 
> Since the usb line has nothing to which a PPS interrupt could attach
> AFAIK, you are not going to get even ms timing from a usb dongle. You
> should certainly get better than .5 sec however.

Oops

sorry I missed that the BU-353 was usb. The BR-304 I have is rs232
same as Garmin GPS18x-LVC but no pps line. The BR304 is also
SiRF II rather than SiRF III.

Below are values for offset and jitter from polls at
30 min intervals.

   BR-304 gps18x-lvc gps18x-lvc
  rmcrmcrmc+pps
polls  offset  polls  offset  polls  offset
   % n   (ms) % n   (ms) % n   (ms)
  5090   9.235127   0.075476  0.002
  95   170  53.029249   0.1699   140  0.005
  99.5 178 435.84   10053   0.20   100   141  0.006

Problem with BR-304 was lack of sensitivity and being
unable to keep sufficient satellites in view, even
though positioned with slightly better view of sky than
the Garmin.


David

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

Re: [ntp:questions] ntpd: time reset problem

[Unruh]

David Lord  writes:

>James Browning wrote:
>> On Sep 17, 10:52 pm, "David J Taylor" > this-part.nor-this.co.uk.invalid> wrote:
>>> Don't worry about trees - a modern GPS such as the GPS 18x LVC is very
>>> sensitive, and can work with a lot of obscuration.  Although my GPS 18 LVC
>>> is sitting on the roof, the GPS 18x LVC works just as well sitting in a
>>> room on the top floor of the house.
>> 
>> I have a SiRF star III based USB dongle (US GlobalSat BU-353)
>> that I got a location off of in a basement room about 6 feet from the
>> window. currently it's attached to box whos' ntpd crashes every time
>> I
>> mention it. I think it's talking in the binary mode and the kernel
>> device
>> is tuck at the wrong speed. (I probably just need to restart it.)

>You can check with minicom or similar as to output. I used
>Telix from DOS with my BR304 to set to just give a single
>RMC sentence per second output. The codes needed to switch
>modes were in the br304 manual I downloaded.

>Having said that the br304 is now in pieces to be explored
>with scope probe in case it's possible to locate any signal
>usable for ntp. Best I had was +/- 0.5 sec but it is much
>less sensitive than the Garmin GPS18x-LVC that early in year
>maintained an offset within 4us (that's until sats in view
>reduced by tree growth so it became unusable).

Since the usb line has nothing to which a PPS interrupt could attach
AFAIK, you are not going to get even ms timing from a usb dongle. You
should certainly get better than .5 sec however.


 

>


>David

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

Re: [ntp:questions] ntpd: time reset problem

[David Lord]

James Browning wrote:
> On Sep 17, 10:52 pm, "David J Taylor"  this-part.nor-this.co.uk.invalid> wrote:
>> Don't worry about trees - a modern GPS such as the GPS 18x LVC is very
>> sensitive, and can work with a lot of obscuration.  Although my GPS 18 LVC
>> is sitting on the roof, the GPS 18x LVC works just as well sitting in a
>> room on the top floor of the house.
> 
> I have a SiRF star III based USB dongle (US GlobalSat BU-353)
> that I got a location off of in a basement room about 6 feet from the
> window. currently it's attached to box whos' ntpd crashes every time
> I
> mention it. I think it's talking in the binary mode and the kernel
> device
> is tuck at the wrong speed. (I probably just need to restart it.)

You can check with minicom or similar as to output. I used
Telix from DOS with my BR304 to set to just give a single
RMC sentence per second output. The codes needed to switch
modes were in the br304 manual I downloaded.

Having said that the br304 is now in pieces to be explored
with scope probe in case it's possible to locate any signal
usable for ntp. Best I had was +/- 0.5 sec but it is much
less sensitive than the Garmin GPS18x-LVC that early in year
maintained an offset within 4us (that's until sats in view
reduced by tree growth so it became unusable).




David

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

Re: [ntp:questions] ntpd: time reset problem

[Hal Murray]

>I have a SiRF star III based USB dongle (US GlobalSat BU-353)
>that I got a location off of in a basement room about 6 feet from the
>window. currently it's attached to box whos' ntpd crashes every time
>I
>mention it. I think it's talking in the binary mode and the kernel
>device
>is tuck at the wrong speed. (I probably just need to restart it.)

What version of ntpd are you using?  What sort of error message
do you get?

ntpd shouldn't crash just because it gets garbage from a refclock.
We should fix this, but we need more info.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

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

Re: [ntp:questions] ntpd: time reset problem

[James Browning]

On Sep 17, 10:52 pm, "David J Taylor"  wrote:
> Don't worry about trees - a modern GPS such as the GPS 18x LVC is very
> sensitive, and can work with a lot of obscuration.  Although my GPS 18 LVC
> is sitting on the roof, the GPS 18x LVC works just as well sitting in a
> room on the top floor of the house.

I have a SiRF star III based USB dongle (US GlobalSat BU-353)
that I got a location off of in a basement room about 6 feet from the
window. currently it's attached to box whos' ntpd crashes every time
I
mention it. I think it's talking in the binary mode and the kernel
device
is tuck at the wrong speed. (I probably just need to restart it.)

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

Re: [ntp:questions] ntpd: time reset problem

[David Lord]

David J Taylor wrote:
> 
> "David Lord" <> wrote in message news:7hh1ihf2smeu...@mid.individual.net...
> []
>> It's very wet round here with 90 +/- 10% R/H being common in
>> various locations including out back of house which is often
>> 95%. You could only hang washing out for it to get wet. This
>> means leaves are soaking wet and beginning of year when I
>> swapped from BR304 to GPS18-LVC I was getting continuous
>> reach 377 but this deteriorated as trees came into leaf.
> 
> Ah, I thought you were in the UK.  The 18x LVC is a lot more sensitive 
> than the 18 (without the x), for your information.

20 mile from Manchester, was a centre of cotton industry,
due to very high humidity meaning some of processes involved
were possible with much less risk of explosions.

Bacup and Stacksteads ... Money was made so quickly that the
valley became known as "The Golden Valley"

Unfortunately very far from that now.

David

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

Re: [ntp:questions] ntpd: time reset problem

[Unruh]

David Lord  writes:

>David J Taylor wrote:
>> 
>> "David Lord"  wrote in message 
>> news:7hg1jtf2s1lv...@mid.individual.net...
>>> David J Taylor wrote:
>>>
 You'll have to get a GPS puck and wireless PC on the roof!  Safely
>>>
>>> That looked a possibility earlier this year but treeline front
>>> and back has shot up maybe a couple of metres already and if
>>> same next year I'd be needing a mast.
>> 
>> Don't worry about trees - a modern GPS such as the GPS 18x LVC is very 
>> sensitive, and can work with a lot of obscuration.  Although my GPS 18 
>> LVC is sitting on the roof, the GPS 18x LVC works just as well sitting 
>> in a room on the top floor of the house.

>It's very wet round here with 90 +/- 10% R/H being common in
>various locations including out back of house which is often
>95%. You could only hang washing out for it to get wet. This
>means leaves are soaking wet and beginning of year when I
>swapped from BR304 to GPS18-LVC I was getting continuous
>reach 377 but this deteriorated as trees came into leaf.

I live in Vancouver, Canada. It has somewhat of a reputation for rain. 
As I said, my puck in on my front porch, with a house behind it, and 25m
trees 20m away. It works. 

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

Re: [ntp:questions] ntpd: time reset problem

[David J Taylor]

"David Lord" <> wrote in message 
news:7hh1ihf2smeu...@mid.individual.net...
[]
> It's very wet round here with 90 +/- 10% R/H being common in
> various locations including out back of house which is often
> 95%. You could only hang washing out for it to get wet. This
> means leaves are soaking wet and beginning of year when I
> swapped from BR304 to GPS18-LVC I was getting continuous
> reach 377 but this deteriorated as trees came into leaf.

Ah, I thought you were in the UK.  The 18x LVC is a lot more sensitive 
than the 18 (without the x), for your information.

> Datasheets on some receiver chips seem to use just a crystal
> but some seem to have some coupling back from output to input
> but it's not clear if feedback or forward. Otherwise all trf
> with agc from a peak detector but filtering time constants
> aren't easy to work out as just giving a suggested capacitor
> value.
>
> I tried similar interstage crystal coupling which produced a
> good oscillator until receiver module was shielded and moved
> away from aerial. That also lost me some of timecode pulses
> as not enough damping.

One of the times when designing by impulse response (of the envelope) 
rather than just bandwidth!

> Maplin circuit I have shows the fast timecode but more recent
> documentation from NPL doesn't mention any fast code and the
> slow code shown is different to that given with the Maplin
> circuit.

The fast-code signal was dropped in October 1998.

> I've seen widely different values used for filter of the
> NE567 from about 1ms upwards. Maplin design seems to be
> for loop filter of NE567 with bandwidth of about 8kHz
> (depends on input level) and 1ms with option of extra
> capacitor at input of Schmitt to give about 15ms to
> remove fast pulses.

I still think that nothing beat filtering as early as possible, in the 
detector stage it's rather last gasp.

> I'm suspecting I've something broken on my demodulator
> pcb so will be rebuilding with added 4093 and couple of
> pots to try different time constants. That's just a
> challenge since Conrad module with 60kHz crystal is
> tiny, low power and works ok.
>
> The Conrad module doesn't give a 60kHz output though and
> my aim was to use that as frequency reference same as
> Andy Talbot (G4JNT) design.
>
> David

Ah, I once thought of doing something similar with the 198KHz (was 200KHz) 
signal from Droitwich.  Clever chaps those who design the modules - as you 
say, they do work well.

73,
David 

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

Re: [ntp:questions] ntpd: time reset problem

[David Lord]

David J Taylor wrote:
> 
> "David Lord"  wrote in message 
> news:7hg1jtf2s1lv...@mid.individual.net...
>> David J Taylor wrote:
>>
>>> You'll have to get a GPS puck and wireless PC on the roof!  Safely
>>
>> That looked a possibility earlier this year but treeline front
>> and back has shot up maybe a couple of metres already and if
>> same next year I'd be needing a mast.
> 
> Don't worry about trees - a modern GPS such as the GPS 18x LVC is very 
> sensitive, and can work with a lot of obscuration.  Although my GPS 18 
> LVC is sitting on the roof, the GPS 18x LVC works just as well sitting 
> in a room on the top floor of the house.

It's very wet round here with 90 +/- 10% R/H being common in
various locations including out back of house which is often
95%. You could only hang washing out for it to get wet. This
means leaves are soaking wet and beginning of year when I
swapped from BR304 to GPS18-LVC I was getting continuous
reach 377 but this deteriorated as trees came into leaf.

> 
>> I'm signed up in protest at various network over mains systems
>> due to them splattering and killing QRP reception.
> 
> Me also.
> 
> []
>> I've not mastered the demodulation though and whilst on scope
>> it looks to be a clean and identifiable MSF timecode no
>> different than from Conrad module, a much closer look shows
>> noise spikes. I used an RC filter at output and suspect a
>> Schmitt as with Maplin circuit is needed.
>>
>> David
> 
> What sort of filtering is used these days?  I used to think a 60KHz 
> crystal was required, with a bandwidth of a few 10's or 100's of Hz 

Datasheets on some receiver chips seem to use just a crystal
but some seem to have some coupling back from output to input
but it's not clear if feedback or forward. Otherwise all trf
with agc from a peak detector but filtering time constants
aren't easy to work out as just giving a suggested capacitor
value.

I tried similar interstage crystal coupling which produced a
good oscillator until receiver module was shielded and moved
away from aerial. That also lost me some of timecode pulses
as not enough damping.

> (there used to be a fast-code transmission on the signal).  What's the 
> rise-time required through the filter?  20ms fast enough?  A Schmitt 
> trigger would be worth trying, because although there will be some 
> hysteresis on the PC input port, it will be more appropriate for RS-232 
> levels and not tailored to your signal.

Maplin circuit I have shows the fast timecode but more recent
documentation from NPL doesn't mention any fast code and the
slow code shown is different to that given with the Maplin
circuit.

I've seen widely different values used for filter of the
NE567 from about 1ms upwards. Maplin design seems to be
for loop filter of NE567 with bandwidth of about 8kHz
(depends on input level) and 1ms with option of extra
capacitor at input of Schmitt to give about 15ms to
remove fast pulses.

I'm suspecting I've something broken on my demodulator
pcb so will be rebuilding with added 4093 and couple of
pots to try different time constants. That's just a
challenge since Conrad module with 60kHz crystal is
tiny, low power and works ok.

The Conrad module doesn't give a 60kHz output though and
my aim was to use that as frequency reference same as
Andy Talbot (G4JNT) design.

David

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

Re: [ntp:questions] ntpd: time reset problem

[David J Taylor]

"David Lord"  wrote in message 
news:7hg1jtf2s1lv...@mid.individual.net...
> David J Taylor wrote:
>
>> You'll have to get a GPS puck and wireless PC on the roof!  Safely
>
> That looked a possibility earlier this year but treeline front
> and back has shot up maybe a couple of metres already and if
> same next year I'd be needing a mast.

Don't worry about trees - a modern GPS such as the GPS 18x LVC is very 
sensitive, and can work with a lot of obscuration.  Although my GPS 18 LVC 
is sitting on the roof, the GPS 18x LVC works just as well sitting in a 
room on the top floor of the house.

> I'm signed up in protest at various network over mains systems
> due to them splattering and killing QRP reception.

Me also.

[]
> I've not mastered the demodulation though and whilst on scope
> it looks to be a clean and identifiable MSF timecode no
> different than from Conrad module, a much closer look shows
> noise spikes. I used an RC filter at output and suspect a
> Schmitt as with Maplin circuit is needed.
>
> David

What sort of filtering is used these days?  I used to think a 60KHz 
crystal was required, with a bandwidth of a few 10's or 100's of Hz (there 
used to be a fast-code transmission on the signal).  What's the rise-time 
required through the filter?  20ms fast enough?  A Schmitt trigger would 
be worth trying, because although there will be some hysteresis on the PC 
input port, it will be more appropriate for RS-232 levels and not tailored 
to your signal.

Cheers,
David 

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

Re: [ntp:questions] ntpd: time reset problem

[Unruh]

David Lord  writes:

>David J Taylor wrote:

>> You'll have to get a GPS puck and wireless PC on the roof!  Safely 

>That looked a possibility earlier this year but treeline front
>and back has shot up maybe a couple of metres already and if
>same next year I'd be needing a mast.

I have my GPS18 buck on the banister of my front porch. House behind it,
taking up half the sky. large maple trees on the street about 10 or 15m
in front of the house along the street- each at least 20-25m high
 cutting off another 50% of the still available
sky. But it still works and gives me the time. 

Ie, a rooftop is almost certainly much better.


>> hidden in some cupboard up there.  Or even power-line connections 

>I'm signed up in protest at various network over mains systems
>due to them splattering and killing QRP reception.

>I hope the problems with MSF yesterday were a one-off, there
>was a lot of noise from what I took to be machinery nearby
>during that period but I couldn't see from out of window and
>when I went out to check there was nothing and of course when
>I got back MSF was received ok. Previously over 4 days with
>Conrad module tuned to MSF and logging ntpd, the reach had
>stayed at 377 throughout.
 
>> I built a loop using multi-strand cable inside a 1m diameter copper 
>> central-heating pipe (the pipe being open circuit, of course!), but at 
>> that time with CRT displays and TVs there was just too much 
>> interference. Having said that, the simple radio clocks which Maplin 

>Not sure about the Conrad module but my diy receiver uses a
>balanced input amp and output gives a reasonably stable trace
>on scope but if either input is grounded the output is just
>noise although slight 1Hz pulse can still be seen.

>I've not mastered the demodulation though and whilst on scope
>it looks to be a clean and identifiable MSF timecode no
>different than from Conrad module, a much closer look shows
>noise spikes. I used an RC filter at output and suspect a
>Schmitt as with Maplin circuit is needed.


>David

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

Re: [ntp:questions] ntpd: time reset problem

[David Lord]

David J Taylor wrote:

> You'll have to get a GPS puck and wireless PC on the roof!  Safely 

That looked a possibility earlier this year but treeline front
and back has shot up maybe a couple of metres already and if
same next year I'd be needing a mast.

> hidden in some cupboard up there.  Or even power-line connections 

I'm signed up in protest at various network over mains systems
due to them splattering and killing QRP reception.

I hope the problems with MSF yesterday were a one-off, there
was a lot of noise from what I took to be machinery nearby
during that period but I couldn't see from out of window and
when I went out to check there was nothing and of course when
I got back MSF was received ok. Previously over 4 days with
Conrad module tuned to MSF and logging ntpd, the reach had
stayed at 377 throughout.

> I built a loop using multi-strand cable inside a 1m diameter copper 
> central-heating pipe (the pipe being open circuit, of course!), but at 
> that time with CRT displays and TVs there was just too much 
> interference. Having said that, the simple radio clocks which Maplin 

Not sure about the Conrad module but my diy receiver uses a
balanced input amp and output gives a reasonably stable trace
on scope but if either input is grounded the output is just
noise although slight 1Hz pulse can still be seen.

I've not mastered the demodulation though and whilst on scope
it looks to be a clean and identifiable MSF timecode no
different than from Conrad module, a much closer look shows
noise spikes. I used an RC filter at output and suspect a
Schmitt as with Maplin circuit is needed.


David

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

Re: [ntp:questions] ntpd: time reset problem

[David J Taylor]

"David Lord" <> wrote in message 
news:7hevfhf2sksi...@mid.individual.net...
[]
> yes, now at endgame when it's all fitting together but not the
> pain getting there. Living inside an LF wavetrap (steel joists
> earth strapped to copper central heating pipes I'm guessing
> = several big shorted loops) doesn't help.
>
> Loop aerial for MSF 580mm (22.75") per side
> 
>
> That aerial can't manage DCF77 as self resonance is too low
> whilst with Conrad module's ferrite aerial there can be many
> periods when signal is lost, mostly evening and morning flips
> between ground and skywave, also but not so regular at any
> other time of day possibly from interference.
>
> David

You'll have to get a GPS puck and wireless PC on the roof!  Safely hidden 
in some cupboard up there.  Or even power-line connections (extreme yuk!). 
Nice to see how you can use (what I call) chocolate-block connectors.  I 
used to be VHF and video, so type-N, BNC (50-ohm and 75-ohm) connectors. 
Nowadays it's data over satellite TV - so those horrible F-connectors.

  http://www.satsignal.eu/wxsat/atovs/index.html

I built a loop using multi-strand cable inside a 1m diameter copper 
central-heating pipe (the pipe being open circuit, of course!), but at 
that time with CRT displays and TVs there was just too much interference. 
Having said that, the simple radio clocks which Maplin etc. supply seem to 
work fine today - probably a little more signal after the transmitter was 
moved north.

Cheers,
David 

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

Re: [ntp:questions] ntpd: time reset problem

[David Lord]

David J Taylor wrote:
> 
.

> It does sound as if you are enjoying yourself, in any case!

yes, now at endgame when it's all fitting together but not the
pain getting there. Living inside an LF wavetrap (steel joists
earth strapped to copper central heating pipes I'm guessing
= several big shorted loops) doesn't help.

Loop aerial for MSF 580mm (22.75") per side


That aerial can't manage DCF77 as self resonance is too low
whilst with Conrad module's ferrite aerial there can be many
periods when signal is lost, mostly evening and morning flips
between ground and skywave, also but not so regular at any
other time of day possibly from interference.


David

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

Re: [ntp:questions] ntpd: time reset problem

[Steve Kostecke]

On 2009-09-17, Unruh  wrote:

> Steve Kostecke  writes:
>
>>The NTP Stable release needs to poll a refclock 4 times before it
>>collects enough data to adjust (i.e. step or slew) the clock. The times
>>you quote are consistant with this.
>
> A refclock usually has a poll of 4 (16 sec) 4*16=64 sec.

Really?

I had to use 'minpoll 4' to reduce the NMEA driver poll interval from 64
sec to 16 sec for my GPS-18LVC.

The CHU refclock driver used by my NET-4801 has a default minpoll of 64.

grepping the ./ntpd directory in the current stable release shows that
refclock_palisade.h is the only place where a driver specific MINPOLL is
set.

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

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

Re: [ntp:questions] ntpd: time reset problem

[David J Taylor]

"David Lord" <> wrote in message 
news:7hee7pf2s1jo...@mid.individual.net...
[]
> What I've not tried so far over usb or direct to serial
> port, is pps on DCD with type 22 driver and radioclkd2
> using signal on a different pin CTS, DSR or possibly RNG.
>
> There are a couple of problems with that, the pps signal
> needs to be extracted from the demodulated carrier, and
> cable I have wired up only has DCD.
>
> I have a monostable setup to give a 950ms pulse before
> it can be retriggered and other half of chip generates a
> short pulse when 950ms pulse is triggered. I believe that
> should give me a pps output from MSF but not yet given it
> a try.
>
>
> David

It does sound as if you are enjoying yourself, in any case!

Cheers,
David 

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

Re: [ntp:questions] ntpd: time reset problem

[David Lord]

David J Taylor wrote:
> "David Lord" <> wrote in message news:7hd884f2t62h...@mid.individual.net...
> []
>> That's good enough for me. The usb connection rules out
>> PPS mode and seems to limit to +/-10ms.
>>
>>
>> cheers
>>
>> David
> 
> 
> Why rule out PPS?  I tried a GPS/PPS signal over USB and found a jitter 
> of about 45 microseconds:
> 
>  http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html#usb
> 
> I suspect that's far better than a radio-clock would require.  If your 
> USB hardware/software allows, I would certainly try PPS.

Hi

I have tried it with radioclkd2 and that locks up with
100% load on both systems tried from NetBSD or Linux on
eeepc whenever timepps is selected via serial to usb
and correct source is selected, ie if source doesn't
have signal active, receiver off, it does nothing but
with receiver powered up it locks up and if logging
output there are many MBs of errors in a few seconds
before lock up.

NetBSD doesn't support TIOCMIOWAIT mode available on
Linux and using poll mode gets me +/- 10ms.

On Linux I can use wait mode which gives better than
+/- 2ms.

The NetBSD server has multiple serial ports anyway and in
that case timepps mode of radioclkd2 does work very well,
much better than GPS without pps, but I can't find the
table of comparative results just now.

What I've not tried so far over usb or direct to serial
port, is pps on DCD with type 22 driver and radioclkd2
using signal on a different pin CTS, DSR or possibly RNG.

There are a couple of problems with that, the pps signal
needs to be extracted from the demodulated carrier, and
cable I have wired up only has DCD.

I have a monostable setup to give a 950ms pulse before
it can be retriggered and other half of chip generates a
short pulse when 950ms pulse is triggered. I believe that
should give me a pps output from MSF but not yet given it
a try.


David

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

Re: [ntp:questions] ntpd: time reset problem

[David J Taylor]

"David Lord" <> wrote in message 
news:7hd884f2t62h...@mid.individual.net...
[]
> That's good enough for me. The usb connection rules out
> PPS mode and seems to limit to +/-10ms.
>
>
> cheers
>
> David


Why rule out PPS?  I tried a GPS/PPS signal over USB and found a jitter of 
about 45 microseconds:

  http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html#usb

I suspect that's far better than a radio-clock would require.  If your USB 
hardware/software allows, I would certainly try PPS.

Cheers,
David 

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

Re: [ntp:questions] ntpd: time reset problem

[Unruh]

Steve Kostecke  writes:

>On 2009-09-16, David Lord  wrote:

>> Tonight I gave it another couple or tries with "ntpd -q"
>>
>> reset +0.150s within 300s
>> then used date to give a bigger initial offset
>> reset +66.9s within 330s
>> then started ntpd and was in sync within 260s

>The NTP Stable release needs to poll a refclock 4 times before it
>collects enough data to adjust (i.e. step or slew) the clock. The times
>you quote are consistant with this.

A refclock usually has a poll of 4 (16 sec) 4*16=64 sec.


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

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

Re: [ntp:questions] ntpd: time reset problem

[David Mills]

Terje,

Funny you should ask. Interplanetary timekeeping is covered in Chapters 
17 and 18 in the second edition of das Buch. However, one of the first 
things to learn in space is that where you are is much more important 
than what time it is.

To compare clocks on the Earth and Mars surfaces you have to transform 
proper time on the planetary surface to coordinate time at the solar 
system barycenter. To do that, you have to account for general 
relativity effects of planetary gravity (redshift) and surface velocity 
(time dilation) in the planetary-centric inertial frame. This is 
complicated by the facts that Earth bulges at the equator and Mars is 
something like a pear revolving on its side. For Earth a clock at the 
planetary center runs about 60 microseconds per day fast relative to one 
at sea level.

Then you have to transfer coordinate time at the center of the Earth to 
coordinate time at the solar system barycenter. Accounting for gravity 
and orbit variations this results in difference of approximately 17 
milliseconds over the Earth orbit.

Not done yet. Knowing the detailed geometry and motion of the surface 
state vector of both planets, you can use an iterated procedure 
described in the book to determine the light time and time of arrival of 
a ray from Earth. The NASA/JPL Deep Space Network can determine a 
position on Earth to within 2 cm and range to a spacecraft within 10 ns 
using radiometric ranging and lots of averaging. Using means described 
in the book, the spacecraft clock can be set to a nominal accuracy of 15 ns.

Using current techniques the spacecraft clock can be set within a few 
milliseconds via the telemetry stream. To get the ultimate accuracy 
would require minor changes at the DSN and spacecraft electronics. Given 
the current financial state and the slippage for the Mars Science 
Laboratory mission of two years, I doubt JPL is in the mood to do that 
anytime soon. However, the technology might be first deployed for 
missions to the Moon polar regions and used for vehicle navigation.

Disclaimer. You might consider this advance publicity for the book, 
which is about ready for the publisher.

Dave

Terje Mathisen wrote:

>Unruh wrote:
>
>>>IIRC, the round trip time approaches 40 min when they are
>>>farthest apart?  With the worst case velocity difference
>>>approaching 121K mph (54KmpS)?  Thats approaching 65km
>>>difference in distance between when a message is sent,
>>>and the response is sent?
>>>
>>So what? The signal goes from Mars to earth-- 20 min. On earth the clock
>>timestamps the receipt and the sending of the ntp packet. -- typically .1 
>>sec.
>>between those events. During that time the earth moves say 5 m.
>>Then going back the packet
>>takes 20min-5/3*10^8= 20min-.00016 sec. Ie, the outward and inward
>>time delays are the same to .016usec. Who cares what the earth does
>>before or after it receives the packet? That the earth happens to be
>>6 km closer to mars when the packet arrives at mars is irrelevant.
>>
>
>You are (for once) wrong here Unruh:
>
>To make it simple we can assume that the Earth is standing still and 
>only Mars is moving (towards Earth):
>
>ntpd on Mars sends a request at (local) time t1, it is received and 
>returned by Earth ot times t2, t3 (which are effectively the same), then 
>received back on Mars at t4, right? This is standard ntp after all!
>
>However, due to the way Mars is getting closer all the time, the return 
>path happens to be ~6 km shorter, so (t4-t3) will be 2 ms less than 
>(t2-t1).
>
>This bias is something I'm sure Dave Mills' interplanetary version of 
>ntp knows about, and can therefore correct for.
>
>
>>You are probably trying to analyse things from the viewpoint of the
>>earth. That is called the "synchronization" effect in special
>>relativity. Yes, the midpoint of the receive/send time on earth and the
>>midpoint of the send/receive time on mars are mot the same according to
>>the earth bound observer, but they are to the Mars observer which is
>>what counts. (In special relativity things which are synchronized to one
>>observer, or not to a moving observer)
>>
>
>IMHO, this is simply wrong.
>
>Terje
>
>

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

Re: [ntp:questions] ntpd: time reset problem

[Steve Kostecke]

On 2009-09-16, David Lord  wrote:

> Tonight I gave it another couple or tries with "ntpd -q"
>
> reset +0.150s within 300s
> then used date to give a bigger initial offset
> reset +66.9s within 330s
> then started ntpd and was in sync within 260s

The NTP Stable release needs to poll a refclock 4 times before it
collects enough data to adjust (i.e. step or slew) the clock. The times
you quote are consistant with this.

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

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

Re: [ntp:questions] ntpd: time reset problem

[David Lord]

David Lord wrote:
> Steve Kostecke wrote:
>> On 2009-09-15, David Lord  wrote:
>>
>>> Meanwhile I'll see if ntpd will step from refclock source as
>>
>> It will.
> 
> It does, sort of :-(
> 
> On NetBSD-5.0.1 with radioclkd2 + shm and Conrad module tuned
> to MSF connected via serial-usb converter, from four attempts
> I've twice hit ctrl+c after about 20 minutes, another attempt
> completed after 18 minutes with time reset -17.345sec, and
> last try completed after 7 minutes with time slewed 0.008s.
> 
> If the 7 minutes was typical, I'd go with that method
> but waiting 20 minutes or more is just too long.
> 
> That's most I can do today and I'll try similar with
> chrony either tomorrow or Friday before trying again
> with ntpd.
> 

Must have been some sort of interference this morning, but
led on module had been pulsing at 1s each time I looked.
Radioclkd2 -v -d had shown it was seeing MSF (rather than
WWVB or DCF) but I hadn't left that running long enough to
see it had actually worked out correct time.

Tonight I gave it another couple or tries with "ntpd -q"

reset +0.150s within 300s
then used date to give a bigger initial offset
reset +66.9s within 330s
then started ntpd and was in sync within 260s

That's good enough for me. The usb connection rules out
PPS mode and seems to limit to +/-10ms.


cheers

David

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

Re: [ntp:questions] ntpd: time reset problem

[Terje Mathisen]

Unruh wrote:
 >> Terje Mathisen wrote:
>> IMHO, this is simply wrong.
>
> Well, your humble opinion in this case does not accord with the way the
> world works.

Mea Culpa!

You are absolutely right: Mars does stand still, so as long as (t3-t2) 
is short, both times will be more or less identical. :-)

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

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

Re: [ntp:questions] ntpd: time reset problem

[Unruh]

>Unruh wrote:
>>> IIRC, the round trip time approaches 40 min when they are
>>> farthest apart?  With the worst case velocity difference
>>> approaching 121K mph (54KmpS)?  Thats approaching 65km
>>> difference in distance between when a message is sent,
>>> and the response is sent?
>>
>> So what? The signal goes from Mars to earth-- 20 min. On earth the clock
>> timestamps the receipt and the sending of the ntp packet. -- typically 
>> .1 sec.
>> between those events. During that time the earth moves say 5 m.
>> Then going back the packet
>> takes 20min-5/3*10^8= 20min-.00016 sec. Ie, the outward and inward
>> time delays are the same to .016usec. Who cares what the earth does
>> before or after it receives the packet? That the earth happens to be
>> 6 km closer to mars when the packet arrives at mars is irrelevant.

>You are (for once) wrong here Unruh:

>To make it simple we can assume that the Earth is standing still and 
>only Mars is moving (towards Earth):

Ah yes. relativity bites you in the tail again. This is exactly the
situation Einstein anaysed in 1905 to show that synchronization of time
depends on the frame of reference. 
To figure out the time on mars, you need to assume that mars is at rest
not the earth. 


>ntpd on Mars sends a request at (local) time t1, it is received and 
>returned by Earth ot times t2, t3 (which are effectively the same), then 
>received back on Mars at t4, right? This is standard ntp after all!

>However, due to the way Mars is getting closer all the time, the return 
>path happens to be ~6 km shorter, so (t4-t3) will be 2 ms less than 
>(t2-t1).

Yup, and thus you find that IF you use the earth's point of view, you
are correct. But surely if you want the time on mars, yo uwant Mars's
point of view. 


>This bias is something I'm sure Dave Mills' interplanetary version of 
>ntp knows about, and can therefore correct for.

Nothing to correct. Mars at rest is the correct point of view for mars
time. There IS a correction that is needed and that is the timedilation
effect. Ie, the procedure will transfer earth time to mars, but since
earth is moving with respect to mars, earth time goes more slowly than
mars time, and that effect does need correction. Mind you it is not much
(at your assumption of 60Km/s relative velocity, that effect is .02PPM
difference in rate. It is quite possible that that is unmeasureable, but
it does make about .01 sec difference in a year. 
)

>> You are probably trying to analyse things from the viewpoint of the
>> earth. That is called the "synchronization" effect in special
>> relativity. Yes, the midpoint of the receive/send time on earth and the
>> midpoint of the send/receive time on mars are mot the same according to
>> the earth bound observer, but they are to the Mars observer which is
>> what counts. (In special relativity things which are synchronized to one
>> observer, or not to a moving observer)

>IMHO, this is simply wrong.

Well, your humble opinion in this case does not accord with the way the
world works.


>Terje

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

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

Re: [ntp:questions] ntpd: time reset problem

[David Lord]

Steve Kostecke wrote:
> On 2009-09-15, David Lord  wrote:
> 
>> Meanwhile I'll see if ntpd will step from refclock source as
> 
> It will.

It does, sort of :-(

On NetBSD-5.0.1 with radioclkd2 + shm and Conrad module tuned
to MSF connected via serial-usb converter, from four attempts
I've twice hit ctrl+c after about 20 minutes, another attempt
completed after 18 minutes with time reset -17.345sec, and
last try completed after 7 minutes with time slewed 0.008s.

If the 7 minutes was typical, I'd go with that method
but waiting 20 minutes or more is just too long.

That's most I can do today and I'll try similar with
chrony either tomorrow or Friday before trying again
with ntpd.


David

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

Re: [ntp:questions] ntpd: time reset problem

[Terje Mathisen]

Unruh wrote:
>> IIRC, the round trip time approaches 40 min when they are
>> farthest apart?  With the worst case velocity difference
>> approaching 121K mph (54KmpS)?  Thats approaching 65km
>> difference in distance between when a message is sent,
>> and the response is sent?
>
> So what? The signal goes from Mars to earth-- 20 min. On earth the clock
> timestamps the receipt and the sending of the ntp packet. -- typically .1 
> sec.
> between those events. During that time the earth moves say 5 m.
> Then going back the packet
> takes 20min-5/3*10^8= 20min-.00016 sec. Ie, the outward and inward
> time delays are the same to .016usec. Who cares what the earth does
> before or after it receives the packet? That the earth happens to be
> 6 km closer to mars when the packet arrives at mars is irrelevant.

You are (for once) wrong here Unruh:

To make it simple we can assume that the Earth is standing still and 
only Mars is moving (towards Earth):

ntpd on Mars sends a request at (local) time t1, it is received and 
returned by Earth ot times t2, t3 (which are effectively the same), then 
received back on Mars at t4, right? This is standard ntp after all!

However, due to the way Mars is getting closer all the time, the return 
path happens to be ~6 km shorter, so (t4-t3) will be 2 ms less than 
(t2-t1).

This bias is something I'm sure Dave Mills' interplanetary version of 
ntp knows about, and can therefore correct for.

> You are probably trying to analyse things from the viewpoint of the
> earth. That is called the "synchronization" effect in special
> relativity. Yes, the midpoint of the receive/send time on earth and the
> midpoint of the send/receive time on mars are mot the same according to
> the earth bound observer, but they are to the Mars observer which is
> what counts. (In special relativity things which are synchronized to one
> observer, or not to a moving observer)

IMHO, this is simply wrong.

Terje

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

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

Re: [ntp:questions] ntpd: time reset problem

[Terje Mathisen]

Unruh wrote:
>> I believe the delays are asymmetric in large part due to vastly
>> different data rates from the earth to the ship (high rate) vs from
>> the ship (low rate).
>
> No idea why that would make it assymetric. Light does not travel at a
> different velocity simply because it is a crowd of other light ( or
> radio waves).

Maybe because there is always some telemetry and/or image data being 
sent from Mars back to Earth, meaning that even with realtime priority, 
the ntp request must wait until the current packet has finished going out?

OTOH, I'm sure a Mars station will have a network stack/card capable of 
timestamping packets as they actually go out, and not (just) when the 
ntpd process put them in the transmit queue!

Terje

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

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

Re: [ntp:questions] ntpd: time reset problem

[Unruh]

David Lord  writes:

>Unruh wrote:
>> David Lord  writes:
>...
>>> On Ubuntu it's made more difficult than it needs be as
>>> both default to running from startup. I've been trying
>>> to get radioclocks to work so need ntpd installed for
>>> those.  Anyway I'll try getting chrony installed
>>> standalone.
>> 
>> Lichvar now has a version of chrony whith shm support through which you
>> could run your radio clock. He also has a hack for ntpd with will use
>> any of its refclocks to feed data to chrony and thus get all of the ntp
>> support into chrony. (ntp runs but does nothing but feed refclock
>> readings to chrony)

>Any chance of a link to this as I've no problem trying on
>either Ubuntu or NetBSD. I'm on chrony mailing list but it's
>very quiet.

chrony-dev list.


>>> Radioclock idea was for when no dialup or lan was
>>> available but suffers same problem for mobile use that
>>> ntpd doesn't converge fast enough to be useful when
>>> several seconds off when started. It would be handy if
>>> refclock drivers had a step option but I can't see
>>> anything like that documented.
>> 
>> Again, chrony does, and yes it does work.

>I'm sold

>Meanwhile I'll see if ntpd will step from refclock source as
>I'd not considered it possible so not bothered to try.

The refclock support in chrony  is still in the testing stage, so your milage
 may vary (ie alpha code).


http://fedorapeople.org/~mlichvar/chrony/ntp-chrony.patch
for the ntp pach
git clone http://fedorapeople.org/~mlichvar/chrony/chrony.git
for the patched chrony.
But neither is really necessary for you, as the change is to try to get
chrony to use refclock support. If you just need network, chrony already
does that. (Chrony 1.23 which is in most of the distros) The one thing
that is still wonky is the real time clock support, since Linux has
changed that in the past couple of years, breaking almost everything
that uses the RTC. ( the key thing it used to do is give an interrupt on
the clock seconds rollover. That is now completely broken. )




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

Re: [ntp:questions] ntpd: time reset problem

[Unruh]

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

>Unruh wrote:
>> BlackLists writes:
>>> Unruh wrote:
 BlackLists writes:
> David Lord wrote:
>> Can you then suggest how it's at all possible for ntpd
>>  to be of any use on a mobile connection with such high
>>  latency?
> Interplanetary Timekeeping ?
> 
 IF the latency is known to be symmetric ( which it is
  on an interplanetary system) then large latency is no
  problem.
>>
>>> I don't see how they are likely to have symmetric latency.
>>
>>> e.g.
>>>  The earths orbital velocity is something like 67k mph?
>>>   mars orbital velocity is something like 54k mph?
>>
>>>  If you were to send a message, and wait for a response,
>>>   the planets would by significantly closer or farther
>>>   apart when the response was sent?
>>
>> The constant velocity does not matter. (Relativity).
>> Only the acceleration matters, and the accelerations
>>  are small.
>> I am on mars. I can regard mars as at rest ( and in
>>  fact the time on mars demands that I do so.
>> I send a message to earth.
>> It returns it after much less than a second.
>> The difference in distance in that time is tiny (eg in
>>  a msec the relative motion of the earth is much less
>>  than a Km, which means that the difference in travel
>>  time is less than 10usec.)

>IIRC, the round trip time approaches 40 min when they are
> farthest apart?  With the worst case velocity difference
> approaching 121K mph (54KmpS)?  Thats approaching 65km
> difference in distance between when a message is sent,
> and the response is sent?

So what? The signal goes from Mars to earth-- 20 min. On earth the clock
timestamps the receipt and the sending of the ntp packet. -- typically .1 
sec.
between those events. During that time the earth moves say 5 m. 
Then going back the packet
takes 20min-5/3*10^8= 20min-.00016 sec. Ie, the outward and inward
time delays are the same to .016usec. Who cares what the earth does
before or after it receives the packet? That the earth happens to be
6 km closer to mars when the packet arrives at mars is irrelevant.

You are probably trying to analyse things from the viewpoint of the
earth. That is called the "synchronization" effect in special
relativity. Yes, the midpoint of the receive/send time on earth and the
midpoint of the send/receive time on mars are mot the same according to
the earth bound observer, but they are to the Mars observer which is
what counts. (In special relativity things which are synchronized to one
observer, or not to a moving observer)





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

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

Re: [ntp:questions] ntpd: time reset problem

[Unruh]

Dave Hart  writes:

>On Sep 14, 9:33=A0pm, Unruh wrote:
>> IF the latency is known to be symmetric ( which it is on an
>> interplanetary system) then large latency is no problem. If it is not
>> known to be symmetric and worse, both in and out latencies are variable,
>> then it is pretty well impossible.

>I believe the delays are asymmetric in large part due to vastly
>different data rates from the earth to the ship (high rate) vs from
>the ship (low rate).

No idea why that would make it assymetric. Light does not travel at a
different velocity simply because it is a crowd of other light ( or
radio waves). 


>Cheers,
>Dave Hart

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

Re: [ntp:questions] ntpd: time reset problem

[Steve Kostecke]

On 2009-09-15, David Lord  wrote:

> Meanwhile I'll see if ntpd will step from refclock source as

It will.

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

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

Re: [ntp:questions] ntpd: time reset problem

[David Lord]

Unruh wrote:
> David Lord  writes:
...
>> On Ubuntu it's made more difficult than it needs be as
>> both default to running from startup. I've been trying
>> to get radioclocks to work so need ntpd installed for
>> those.  Anyway I'll try getting chrony installed
>> standalone.
> 
> Lichvar now has a version of chrony whith shm support through which you
> could run your radio clock. He also has a hack for ntpd with will use
> any of its refclocks to feed data to chrony and thus get all of the ntp
> support into chrony. (ntp runs but does nothing but feed refclock
> readings to chrony)

Any chance of a link to this as I've no problem trying on
either Ubuntu or NetBSD. I'm on chrony mailing list but it's
very quiet.

>> Radioclock idea was for when no dialup or lan was
>> available but suffers same problem for mobile use that
>> ntpd doesn't converge fast enough to be useful when
>> several seconds off when started. It would be handy if
>> refclock drivers had a step option but I can't see
>> anything like that documented.
> 
> Again, chrony does, and yes it does work.

I'm sold

Meanwhile I'll see if ntpd will step from refclock source as
I'd not considered it possible so not bothered to try.


cheers

David

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

Re: [ntp:questions] ntpd: time reset problem

[Dave Hart]

On Sep 14, 9:33 pm, Unruh wrote:
> IF the latency is known to be symmetric ( which it is on an
> interplanetary system) then large latency is no problem. If it is not
> known to be symmetric and worse, both in and out latencies are variable,
> then it is pretty well impossible.

I believe the delays are asymmetric in large part due to vastly
different data rates from the earth to the ship (high rate) vs from
the ship (low rate).

Cheers,
Dave Hart

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

Re: [ntp:questions] ntpd: time reset problem

[John Hasler]

Bill Unruh writes:
> Obviously ubuntu decided that since both do the same thing and would
> be in conflict if both were running at the same time, they will not
> allow both to be installed.

It's my fault (assuming Ubuntu uses my Debian package).  I made my
Chrony package conflict with Ntp because both start by default on
installation.

-- 
John Hasler 
jhas...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

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

Re: [ntp:questions] ntpd: time reset problem

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

Unruh wrote:
> BlackLists writes:
>> Unruh wrote:
>>> BlackLists writes:
 David Lord wrote:
> Can you then suggest how it's at all possible for ntpd
>  to be of any use on a mobile connection with such high
>  latency?
 Interplanetary Timekeeping ?
 
>>> IF the latency is known to be symmetric ( which it is
>>>  on an interplanetary system) then large latency is no
>>>  problem.
>
>> I don't see how they are likely to have symmetric latency.
>
>> e.g.
>>  The earths orbital velocity is something like 67k mph?
>>   mars orbital velocity is something like 54k mph?
>
>>  If you were to send a message, and wait for a response,
>>   the planets would by significantly closer or farther
>>   apart when the response was sent?
>
> The constant velocity does not matter. (Relativity).
> Only the acceleration matters, and the accelerations
>  are small.
> I am on mars. I can regard mars as at rest ( and in
>  fact the time on mars demands that I do so.
> I send a message to earth.
> It returns it after much less than a second.
> The difference in distance in that time is tiny (eg in
>  a msec the relative motion of the earth is much less
>  than a Km, which means that the difference in travel
>  time is less than 10usec.)

IIRC, the round trip time approaches 40 min when they are
 farthest apart?  With the worst case velocity difference
 approaching 121K mph (54KmpS)?  Thats approaching 65km
 difference in distance between when a message is sent,
 and the response is sent?

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

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

Re: [ntp:questions] ntpd: time reset problem

[Unruh]

David Lord  writes:

>Unruh wrote:
>> David Lord  writes:
>> 
>>> Unruh wrote:
 Steve Kostecke  writes:

> On 2009-09-14, David Lord  wrote:
>> Steve Kostecke wrote:
>>
>>> On 2009-09-14, David Lord  wrote:
>>>
 Frank Elsner wrote:

 OT you also have rather a lot of sources specified and if just for a
 single box it seems a bit excessive and could be trimmed to four or
 five (I'd also guess some of those eight get same refid).
>>> Red Herring.
>> No, you missed the OT.
> ???
 I've just been trying mobile broadband on a high latency connection
> [snip]
 Then this weekend after reconfigured to use "burst" in server lines
>>> The use of "burst" against other peoples' time servers is generally
>>> considered to be abuse unless you have received permission to do so.
> [snip]
>> Anyway "burst" works and I now give myself permission to use
>> "burst" to set time from my own ntp servers which is as good
>> a compromise as any :-)
> Great.
>> Can you then suggest how it's at all possible for ntpd to be
>> of any use on a mobile connection with such high latency?
> Add to that the effects of aggressive power saving.
>> I just need to get something working that's significantly
>> better than wristwatch time.
> Perhaps you need to choose a different tool.
 You could try chrony if you are running Linux or BSD. It might work
 better under your conditions. Your horrible latencies are worrysome, and
 make it hard to imagine how anything could work well. 
>> 
>>> Seems to be a feature of the Vodafone system here. Punch a hole
>>> through their network and latency will come down, that's why
>>> 'burst' works, just as explained in the documentation. Vodafone
>>> have port and nat translation but users aren't assigned a single
>>> ip address for a session so make several connections and it's
>>> possible several ip addresses will be used.
>> 
>>> Chrony gave a quicker convergence but doesn't seem to have
>>> equivalent to 'ntpd -q' and I'm converging from many seconds
>>> and even with the chrony equivalent of burst it takes too
>>> long compared to using 'ntpd -q' to set time reasonably close.
>> 
>> Put
>> initstepslew 10 client1 client3 client6
>> 
>> Which will use the three clients to determine the initial offset and if
>> greater than 10 sec will step rather than slew. 
>> ( change 10 to what you want).
>> 
>> Ie, it is like ntp with burst and -q only more configurable.

>I have 'initstepslew' but it doesn't actually appear to do
>the job that's needed and I've also tried 'burst n/m' and
>that's not seemed to help. John Hasler's makestep
>suggestion might be what's needed but using 'ntpd -q' to
>set the clock first does give required result, at least
>from last nights session.

>>> On Ubuntu I can't get both chrony and ntpd to coexist from
>>> package manager (conflicting packages).
>> 
>> You certainly do not want them both running at the same time. They will
>> battle each other. I do not know what other stuff could conflict.
>> chrony gives you the programs chronyd and chronyc and various docs and
>> init files. 

>I've had chrony installed along with ntpd on various
>systems for a long while and never considered having
>both running at once :-)

Obviously ubuntu decided that since both do the same thing and would be
in conflict if both were running at the same time, they will not allow
both to be installed. There is nothing about chrony or ntp which would
do this. 


>On Ubuntu it's made more difficult than it needs be as
>both default to running from startup. I've been trying
>to get radioclocks to work so need ntpd installed for
>those.  Anyway I'll try getting chrony installed
>standalone.

Lichvar now has a version of chrony whith shm support through which you
could run your radio clock. He also has a hack for ntpd with will use
any of its refclocks to feed data to chrony and thus get all of the ntp
support into chrony. (ntp runs but does nothing but feed refclock
readings to chrony)



>Radioclock idea was for when no dialup or lan was
>available but suffers same problem for mobile use that
>ntpd doesn't converge fast enough to be useful when
>several seconds off when started. It would be handy if
>refclock drivers had a step option but I can't see
>anything like that documented.

Again, chrony does, and yes it does work.



>Having said that I don't have the need for millisecond
>accuracies when there's no network but have had one
>major disaster when running a cleanup script and clock
>had at some time been badly off so masses of the wrong
>files were deleted :-(


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

Re: [ntp:questions] ntpd: time reset problem

[Unruh]

Frank Elsner  writes:

>> him sooner from whatever destroyed his time. Note that he is running a vm 
>> and the time on
>  ^^

>Hä? Source for this please :-)

>It's a Fedora box, running 24/7.

Sorry, must have been remembering another thread. 

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

Re: [ntp:questions] ntpd: time reset problem

[David Lord]

Frank Elsner wrote:
> David Lord wrote:
>> Frank Elsner wrote:
>>> David Lord wrote:
 Frank Elsner wrote:
> Steve Kostecke wrote:
>>>
>>>   [ ... ]
>>>
>> Do you have a driftfile line?
>
> Yes, this one:
>  116.833

 ?

 I'll guess that's content of your drift file rather than
 location specified in ntp.conf.
>>>
>>> ntp.conf:   driftfile /var/lib/ntp/drift
>>> /var/lib/ntp/drift: 116.803
>>
>> I know you can now have above this but I've always tried
>> to adjust the kernel in some way to get below 10ppm. My
>> experience has been that ntpd doesn't behave well with
>> drifts > 50ppm and also large drifts take a long while
>> for offset to converge.
>>
>> I didn't post after I'd seen you were useing a vm, but
>> now I see you confirmed you're not :-)
> 
> I wonder where this "useing a vm" comes from. Your not the first :-)

I couldn't see vm mentioned in your message.

but it was mentioned in Unruh's message.

! Subject: Re: ntpd: time reset problem
! References: <7guq0ff2rnrt...@mid.dfncis.de> 
 
<7h6e51f2qu9e...@mid.dfncis.de> 

! Message-ID: 
! Date: Mon, 14 Sep 2009 16:04:47 GMT

One other way I've seen clock shoot off by very large amount
when under load is with too high a Hz kernel setting. If you
have it set to 1000Hz it may be worth trying 100Hz. Doing
that may degrade network performance though.

David

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

Re: [ntp:questions] ntpd: time reset problem

[David J Taylor]

"Frank Elsner" <> wrote in message news:7h9c1lf2sgcf...@mid.dfncis.de...
[]
> I wonder where this "useing a vm" comes from. Your not the first :-)
> 
> 
> --Frank Elsner

Romain Kang mentioned it on Sep 09.

David 

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

Re: [ntp:questions] ntpd: time reset problem

[David J Taylor]

"David Lord" <> wrote in message 
news:7h961mf2rgla...@mid.individual.net...
[]
> Having said that I don't have the need for millisecond
> accuracies when there's no network but have had one
> major disaster when running a cleanup script and clock
> had at some time been badly off so masses of the wrong
> files were deleted :-(
>
> David

I try and write my scripts so that they work even if the PC is a few 
minutes off (for those scripts which run every 30 minutes), and I allow up 
to an hour error for those which run daily (so that changing to and from 
summer-time doesn't affect them).  Thankfully, with NTP, I have never been 
that far off.

Cheers,
David 

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

Re: [ntp:questions] ntpd: time reset problem

[Frank Elsner]

David Lord wrote:
> Frank Elsner wrote:
>> David Lord wrote:
>>> Frank Elsner wrote:
 Steve Kostecke wrote:
>>
>>   [ ... ]
>>
> Do you have a driftfile line?

 Yes, this one:
  116.833
>>>
>>> ?
>>>
>>> I'll guess that's content of your drift file rather than
>>> location specified in ntp.conf.
>>
>> ntp.conf:   driftfile /var/lib/ntp/drift
>> /var/lib/ntp/drift: 116.803
> 
> I know you can now have above this but I've always tried
> to adjust the kernel in some way to get below 10ppm. My
> experience has been that ntpd doesn't behave well with
> drifts > 50ppm and also large drifts take a long while
> for offset to converge.
> 
> I didn't post after I'd seen you were useing a vm, but
> now I see you confirmed you're not :-)

I wonder where this "useing a vm" comes from. Your not the first :-)


--Frank Elsner

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

Re: [ntp:questions] ntpd: time reset problem

[David Lord]

Frank Elsner wrote:
> David Lord wrote:
>> Frank Elsner wrote:
>>> Steve Kostecke wrote:
> 
>   [ ... ]
> 
 Do you have a driftfile line?
>>>
>>> Yes, this one:
>>>  116.833
>>
>> ?
>>
>> I'll guess that's content of your drift file rather than
>> location specified in ntp.conf.
> 
> ntp.conf:   driftfile /var/lib/ntp/drift
> /var/lib/ntp/drift: 116.803

I know you can now have above this but I've always tried
to adjust the kernel in some way to get below 10ppm. My
experience has been that ntpd doesn't behave well with
drifts > 50ppm and also large drifts take a long while
for offset to converge.

I didn't post after I'd seen you were useing a vm, but
now I see you confirmed you're not :-)

David

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

Re: [ntp:questions] ntpd: time reset problem

[Hal Murray]

>> IF the latency is known to be symmetric ( which it is
>>  on an interplanetary system) then large latency is no
>>  problem.
>
>I don't see how they are likely to have symmetric latency.
>
> e.g.
>  The earths orbital velocity is something like 67k mph?
>   mars orbital velocity is something like 54k mph?
>
>  If you were to send a message, and wait for a response,
>   the planets would by significantly closer or farther
>   apart when the response was sent?
>
>   {Then again I know almost nothing about astrophysics.}

It's close to symmetric because there aren't any queueing
delays.

Your point is valid.  It can be corrected for.

If you are really serious, you have to correct for relativity.
There is a blue shift from Mars to Earth since Earth is deeper
in the Sun's gravity well.  (Or something like that.)

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

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

Re: [ntp:questions] ntpd: time reset problem

[David Lord]

Unruh wrote:
> David Lord  writes:
> 
>> Unruh wrote:
>>> Steve Kostecke  writes:
>>>
 On 2009-09-14, David Lord  wrote:
> Steve Kostecke wrote:
>
>> On 2009-09-14, David Lord  wrote:
>>
>>> Frank Elsner wrote:
>>>
>>> OT you also have rather a lot of sources specified and if just for a
>>> single box it seems a bit excessive and could be trimmed to four or
>>> five (I'd also guess some of those eight get same refid).
>> Red Herring.
> No, you missed the OT.
 ???
>>> I've just been trying mobile broadband on a high latency connection
 [snip]
>>> Then this weekend after reconfigured to use "burst" in server lines
>> The use of "burst" against other peoples' time servers is generally
>> considered to be abuse unless you have received permission to do so.
 [snip]
> Anyway "burst" works and I now give myself permission to use
> "burst" to set time from my own ntp servers which is as good
> a compromise as any :-)
 Great.
> Can you then suggest how it's at all possible for ntpd to be
> of any use on a mobile connection with such high latency?
 Add to that the effects of aggressive power saving.
> I just need to get something working that's significantly
> better than wristwatch time.
 Perhaps you need to choose a different tool.
>>> You could try chrony if you are running Linux or BSD. It might work
>>> better under your conditions. Your horrible latencies are worrysome, and
>>> make it hard to imagine how anything could work well. 
> 
>> Seems to be a feature of the Vodafone system here. Punch a hole
>> through their network and latency will come down, that's why
>> 'burst' works, just as explained in the documentation. Vodafone
>> have port and nat translation but users aren't assigned a single
>> ip address for a session so make several connections and it's
>> possible several ip addresses will be used.
> 
>> Chrony gave a quicker convergence but doesn't seem to have
>> equivalent to 'ntpd -q' and I'm converging from many seconds
>> and even with the chrony equivalent of burst it takes too
>> long compared to using 'ntpd -q' to set time reasonably close.
> 
> Put
> initstepslew 10 client1 client3 client6
> 
> Which will use the three clients to determine the initial offset and if
> greater than 10 sec will step rather than slew. 
> ( change 10 to what you want).
> 
> Ie, it is like ntp with burst and -q only more configurable.

I have 'initstepslew' but it doesn't actually appear to do
the job that's needed and I've also tried 'burst n/m' and
that's not seemed to help. John Hasler's makestep
suggestion might be what's needed but using 'ntpd -q' to
set the clock first does give required result, at least
from last nights session.

>> On Ubuntu I can't get both chrony and ntpd to coexist from
>> package manager (conflicting packages).
> 
> You certainly do not want them both running at the same time. They will
> battle each other. I do not know what other stuff could conflict.
> chrony gives you the programs chronyd and chronyc and various docs and
> init files. 

I've had chrony installed along with ntpd on various
systems for a long while and never considered having
both running at once :-)

On Ubuntu it's made more difficult than it needs be as
both default to running from startup. I've been trying
to get radioclocks to work so need ntpd installed for
those.  Anyway I'll try getting chrony installed
standalone.

Radioclock idea was for when no dialup or lan was
available but suffers same problem for mobile use that
ntpd doesn't converge fast enough to be useful when
several seconds off when started. It would be handy if
refclock drivers had a step option but I can't see
anything like that documented.

Having said that I don't have the need for millisecond
accuracies when there's no network but have had one
major disaster when running a cleanup script and clock
had at some time been badly off so masses of the wrong
files were deleted :-(


David

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

Re: [ntp:questions] ntpd: time reset problem

[Frank Elsner]

David Lord wrote:
> Frank Elsner wrote:
>> Steve Kostecke wrote:

   [ ... ]

>>> Do you have a driftfile line?
>>
>> Yes, this one:
>>  116.833
> 
> ?
> 
> I'll guess that's content of your drift file rather than
> location specified in ntp.conf.

ntp.conf:   driftfile /var/lib/ntp/drift
/var/lib/ntp/drift: 116.803


--Frank Elsner

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

Re: [ntp:questions] ntpd: time reset problem

[Frank Elsner]

Unruh wrote:
> Steve Kostecke  writes:
> 
>> On 2009-09-14, Frank Elsner  wrote:
> 
>>> The relevant lines read:
>>>
>>> server times.tubit.tu-berlin.de   minpoll 6 maxpoll 8
>>> server ntps1-0.cs.tu-berlin.deminpoll 6 maxpoll 8
>>> server ntps1-1.cs.tu-berlin.deminpoll 6 maxpoll 8
>>> server zeit.fu-berlin.de  minpoll 6 maxpoll 8
>>> server ntp1.ptb.deminpoll 6 maxpoll 8
>>> server ntp2.ptb.deminpoll 6 maxpoll 8
>>> server ntp1.rz.uni-konstanz.deminpoll 6 maxpoll 8
>>> server rustime01.rus.uni-stuttgart.de minpoll 6 maxpoll 8
> 
>> Why are you changing the minpoll / maxpoll ?
> 
>> Please try again without the minpoll / maxpoll modifiers.
> 
> That has absolutely nothing to do with his problem. In fact having a smaller 
> maxpoll saved
> him sooner from whatever destroyed his time. Note that he is running a vm and 
> the time on
  ^^

Hä? Source for this please :-)

It's a Fedora box, running 24/7.


--Frank Elsner

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

Re: [ntp:questions] ntpd: time reset problem

[Unruh]

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

>Unruh wrote:
>> BlackLists writes:
>>> David Lord wrote:
 Can you then suggest how it's at all possible for ntpd
  to be of any use on a mobile connection with such high
  latency?
>>
>>> Interplanetary Timekeeping ?
>>> 
>>
>> IF the latency is known to be symmetric ( which it is
>>  on an interplanetary system) then large latency is no
>>  problem.

>I don't see how they are likely to have symmetric latency.

> e.g.
>  The earths orbital velocity is something like 67k mph?
>   mars orbital velocity is something like 54k mph?

>  If you were to send a message, and wait for a response,
>   the planets would by significantly closer or farther
>   apart when the response was sent?

The constant velocity does not matter. (Relativity). Only the
acceleration matters, and the accelerations are small. 
I am on mars. I can regard mars as at rest ( and in fact the time on
mars demands that I do so. I send a message to earth. It returns it
after much less than a second. The difference in distance in that time
is tiny (eg in a msec the relative motion of the earth is much less than
a Km, which means that the difference in travel time is less than
10usec.)

>   {Then again I know almost nothing about astrophysics.}


>> If it is not known to be symmetric and worse, both in
>>  and out latencies are variable, then it is pretty well
>>  impossible.
>>
>> Note that despite this, ntp is probably the best you
>>  can do. Ie, there are no other procedures which will
>>  give you better time with those kind of latencies.

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

Re: [ntp:questions] ntpd: time reset problem

[Unruh]

David Lord  writes:

>Unruh wrote:
>> Steve Kostecke  writes:
>> 
>>> On 2009-09-14, David Lord  wrote:
>> 
 Steve Kostecke wrote:

> On 2009-09-14, David Lord  wrote:
>
>> Frank Elsner wrote:
>>
>> OT you also have rather a lot of sources specified and if just for a
>> single box it seems a bit excessive and could be trimmed to four or
>> five (I'd also guess some of those eight get same refid).
> Red Herring.
 No, you missed the OT.
>> 
>>> ???
>> 
>> I've just been trying mobile broadband on a high latency connection
>> 
>>> [snip]
>> 
>> Then this weekend after reconfigured to use "burst" in server lines
> The use of "burst" against other peoples' time servers is generally
> considered to be abuse unless you have received permission to do so.
>> 
>>> [snip]
>> 
 Anyway "burst" works and I now give myself permission to use
 "burst" to set time from my own ntp servers which is as good
 a compromise as any :-)
>> 
>>> Great.
>> 
 Can you then suggest how it's at all possible for ntpd to be
 of any use on a mobile connection with such high latency?
>> 
>>> Add to that the effects of aggressive power saving.
>> 
 I just need to get something working that's significantly
 better than wristwatch time.
>> 
>>> Perhaps you need to choose a different tool.
>> 
>> You could try chrony if you are running Linux or BSD. It might work
>> better under your conditions. Your horrible latencies are worrysome, and
>> make it hard to imagine how anything could work well. 

>Seems to be a feature of the Vodafone system here. Punch a hole
>through their network and latency will come down, that's why
>'burst' works, just as explained in the documentation. Vodafone
>have port and nat translation but users aren't assigned a single
>ip address for a session so make several connections and it's
>possible several ip addresses will be used.

>Chrony gave a quicker convergence but doesn't seem to have
>equivalent to 'ntpd -q' and I'm converging from many seconds
>and even with the chrony equivalent of burst it takes too
>long compared to using 'ntpd -q' to set time reasonably close.

Put
initstepslew 10 client1 client3 client6

Which will use the three clients to determine the initial offset and if
greater than 10 sec will step rather than slew. 
( change 10 to what you want).

Ie, it is like ntp with burst and -q only more configurable.







>On Ubuntu I can't get both chrony and ntpd to coexist from
>package manager (conflicting packages).

You certainly do not want them both running at the same time. They will
battle each other. I do not know what other stuff could conflict.
chrony gives you the programs chronyd and chronyc and various docs and
init files. 




>Anyway method I'm using seems ok for now.


>cheers

>David

>> 
>> 
>> 

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

Re: [ntp:questions] ntpd: time reset problem

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

Unruh wrote:
> BlackLists writes:
>> David Lord wrote:
>>> Can you then suggest how it's at all possible for ntpd
>>>  to be of any use on a mobile connection with such high
>>>  latency?
>
>> Interplanetary Timekeeping ?
>> 
>
> IF the latency is known to be symmetric ( which it is
>  on an interplanetary system) then large latency is no
>  problem.

I don't see how they are likely to have symmetric latency.

 e.g.
  The earths orbital velocity is something like 67k mph?
   mars orbital velocity is something like 54k mph?

  If you were to send a message, and wait for a response,
   the planets would by significantly closer or farther
   apart when the response was sent?

   {Then again I know almost nothing about astrophysics.}


> If it is not known to be symmetric and worse, both in
>  and out latencies are variable, then it is pretty well
>  impossible.
>
> Note that despite this, ntp is probably the best you
>  can do. Ie, there are no other procedures which will
>  give you better time with those kind of latencies.

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

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

Re: [ntp:questions] ntpd: time reset problem

[David Lord]

John Hasler wrote:
> David writes:
>> Chrony gave a quicker convergence but doesn't seem to have equivalent
>> to 'ntpd -q' and I'm converging from many seconds and even with the
>> chrony equivalent of burst it takes too long compared to using 'ntpd
>> -q' to set time reasonably close.
> 
> Use the chronyc "makestep" command to jump the time (makestep is only
> available on Linux).
> 
>> On Ubuntu I can't get both chrony and ntpd to coexist from package
>> manager (conflicting packages).
> 
> Use "aptitude download packagename" to download the deb to the current
> directory and then use "dpkg --force-conflicts -i filename" to install.
> Don't run both daemons at the same time.

Thanks, I'll give those suggestions a try.

cheers

David

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

Re: [ntp:questions] ntpd: time reset problem

[John Hasler]

David writes:
> Chrony gave a quicker convergence but doesn't seem to have equivalent
> to 'ntpd -q' and I'm converging from many seconds and even with the
> chrony equivalent of burst it takes too long compared to using 'ntpd
> -q' to set time reasonably close.

Use the chronyc "makestep" command to jump the time (makestep is only
available on Linux).

> On Ubuntu I can't get both chrony and ntpd to coexist from package
> manager (conflicting packages).

Use "aptitude download packagename" to download the deb to the current
directory and then use "dpkg --force-conflicts -i filename" to install.
Don't run both daemons at the same time.
-- 
John Hasler 
jhas...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

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

Re: [ntp:questions] ntpd: time reset problem

[David Lord]

Unruh wrote:
> Steve Kostecke  writes:
> 
>> On 2009-09-14, David Lord  wrote:
> 
>>> Steve Kostecke wrote:
>>>
 On 2009-09-14, David Lord  wrote:

> Frank Elsner wrote:
>
> OT you also have rather a lot of sources specified and if just for a
> single box it seems a bit excessive and could be trimmed to four or
> five (I'd also guess some of those eight get same refid).
 Red Herring.
>>> No, you missed the OT.
> 
>> ???
> 
> I've just been trying mobile broadband on a high latency connection
> 
>> [snip]
> 
> Then this weekend after reconfigured to use "burst" in server lines
 The use of "burst" against other peoples' time servers is generally
 considered to be abuse unless you have received permission to do so.
> 
>> [snip]
> 
>>> Anyway "burst" works and I now give myself permission to use
>>> "burst" to set time from my own ntp servers which is as good
>>> a compromise as any :-)
> 
>> Great.
> 
>>> Can you then suggest how it's at all possible for ntpd to be
>>> of any use on a mobile connection with such high latency?
> 
>> Add to that the effects of aggressive power saving.
> 
>>> I just need to get something working that's significantly
>>> better than wristwatch time.
> 
>> Perhaps you need to choose a different tool.
> 
> You could try chrony if you are running Linux or BSD. It might work
> better under your conditions. Your horrible latencies are worrysome, and
> make it hard to imagine how anything could work well. 

Seems to be a feature of the Vodafone system here. Punch a hole
through their network and latency will come down, that's why
'burst' works, just as explained in the documentation. Vodafone
have port and nat translation but users aren't assigned a single
ip address for a session so make several connections and it's
possible several ip addresses will be used.

Chrony gave a quicker convergence but doesn't seem to have
equivalent to 'ntpd -q' and I'm converging from many seconds
and even with the chrony equivalent of burst it takes too
long compared to using 'ntpd -q' to set time reasonably close.

On Ubuntu I can't get both chrony and ntpd to coexist from
package manager (conflicting packages).

Anyway method I'm using seems ok for now.


cheers

David

> 
> 
> 

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

Re: [ntp:questions] ntpd: time reset problem

[David Lord]

Steve Kostecke wrote:
> On 2009-09-14, David Lord  wrote:
> 
>> Steve Kostecke wrote:
>>
>>> On 2009-09-14, David Lord  wrote:
>>>
 Frank Elsner wrote:

 OT you also have rather a lot of sources specified and if just for a
 single box it seems a bit excessive and could be trimmed to four or
 five (I'd also guess some of those eight get same refid).
>>> Red Herring.
>> No, you missed the OT.

sorry I meant 'Off Topic' :-)

.

>> Anyway "burst" works and I now give myself permission to use
>> "burst" to set time from my own ntp servers which is as good
>> a compromise as any :-)
> 
> Great.
> 
>> Can you then suggest how it's at all possible for ntpd to be
>> of any use on a mobile connection with such high latency?
> 
> Add to that the effects of aggressive power saving.
> 
>> I just need to get something working that's significantly
>> better than wristwatch time.
> 
> Perhaps you need to choose a different tool.

"ntpd -q" with two pool servers and "burst" specified just for
my own servers has just got me a >4 second correction with step
to within a few ms. That's looking good enough for ntpd to then
keep the netbook within a few ms as existing drift doesn't seem
too bad when powered up (frequency after being connected to lan
was just over 4ppm). Resulting few ms out is ok for me. My own
servers are mostly <5ms (average about 500us).

David

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

Re: [ntp:questions] ntpd: time reset problem

[Unruh]

Steve Kostecke  writes:

>On 2009-09-14, David Lord  wrote:

>> Steve Kostecke wrote:
>>
>>> On 2009-09-14, David Lord  wrote:
>>>
 Frank Elsner wrote:

 OT you also have rather a lot of sources specified and if just for a
 single box it seems a bit excessive and could be trimmed to four or
 five (I'd also guess some of those eight get same refid).
>>>
>>> Red Herring.
>>
>> No, you missed the OT.

>???

 I've just been trying mobile broadband on a high latency connection

>[snip]

 Then this weekend after reconfigured to use "burst" in server lines
>>> 
>>> The use of "burst" against other peoples' time servers is generally
>>> considered to be abuse unless you have received permission to do so.

>[snip]

>> Anyway "burst" works and I now give myself permission to use
>> "burst" to set time from my own ntp servers which is as good
>> a compromise as any :-)

>Great.

>> Can you then suggest how it's at all possible for ntpd to be
>> of any use on a mobile connection with such high latency?

>Add to that the effects of aggressive power saving.

>> I just need to get something working that's significantly
>> better than wristwatch time.

>Perhaps you need to choose a different tool.

You could try chrony if you are running Linux or BSD. It might work
better under your conditions. Your horrible latencies are worrysome, and
make it hard to imagine how anything could work well. 



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

Re: [ntp:questions] ntpd: time reset problem

[Unruh]

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

>David Lord wrote:
>> Can you then suggest how it's at all possible for ntpd
>>  to be of any use on a mobile connection with such high
>>  latency?

>Interplanetary Timekeeping ?
>


IF the latency is known to be symmetric ( which it is on an
interplanetary system) then large latency is no problem. If it is not
known to be symmetric and worse, both in and out latencies are variable,
then it is pretty well impossible.
Note that despite this, ntp is probably the best you can do. Ie, there
are no other procedures which will give you better time with those kind
of latencies.

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

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

Re: [ntp:questions] ntpd: time reset problem

[Richard B. Gilbert]

David Lord wrote:
> Steve Kostecke wrote:
>> On 2009-09-14, David Lord  wrote:
>>
>>> Frank Elsner wrote:
>>>
>>> OT you also have rather a lot of sources specified and if just for a
>>> single box it seems a bit excessive and could be trimmed to four or
>>> five (I'd also guess some of those eight get same refid).
>>
>> Red Herring.
> 
> No, you missed the OT.
> 
>>
>>> I've just been trying mobile broadband on a high latency connection
>>> and it was too much for ntpd at 1-2 sec average and 150ms best to 10
>>> sec/timeout at worst :-)
>>>
>>> Then this weekend after reconfigured to use "burst" in server lines
>>
>> "burst" is an 8x multiplier that is applied to each poll.
>>
>> The use of "burst" against other peoples' time servers is generally
>> considered to be abuse unless you have received permission to do so.
> 
> Can you then suggest how it's at all possible for ntpd to be
> of any use on a mobile connection with such high latency?
> 
> Minpoll was also set to 8 which doesn't exactly compensate
> but does mitigate to some extent.
> 
> Probably from that quick test where time was set to within
> 20 ms rather than still 2 sec out after 30 min the poll
> interval could have been reduced further, however I'm pretty
> sure using other than "burst" would not have synced the time
> before system had to be shutdown.
> 
> I just need to get something working that's significantly
> better than wristwatch time.

NTPD was designed for the long haul.  It does not work very well on 
equipment that is not operated 24 hours per day.  If you want to power 
up at 8:30 AM and power down at 5:00 PM, NTPD cannot give you the 
accuracy that it is capable of when operated as designed.

When it is cold started, NTPD needs up to ten hours to discipline your 
clock with the accuracy it is capable of.  Once synchronized, your clock 
should be correct until you power off.

Wrist watch time can be very good indeed.  Walmart offers a "radio 
controlled" watch that synchronizes with the VLF timing signal provided 
by NIST on radio station WWVB for $40 or $50 US

You would do better to specify an error less than X milliseconds or X 
microseconds.

If you want to spend some money you can probably discipline your clock 
within an envelope of fifty or one hundred microseconds!

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

Re: [ntp:questions] ntpd: time reset problem

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

David Lord wrote:
> Can you then suggest how it's at all possible for ntpd
>  to be of any use on a mobile connection with such high
>  latency?

Interplanetary Timekeeping ?



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

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

Re: [ntp:questions] ntpd: time reset problem

[Steve Kostecke]

On 2009-09-14, David Lord  wrote:

> Steve Kostecke wrote:
>
>> On 2009-09-14, David Lord  wrote:
>>
>>> Frank Elsner wrote:
>>>
>>> OT you also have rather a lot of sources specified and if just for a
>>> single box it seems a bit excessive and could be trimmed to four or
>>> five (I'd also guess some of those eight get same refid).
>>
>> Red Herring.
>
> No, you missed the OT.

???

>>> I've just been trying mobile broadband on a high latency connection

[snip]

>>> Then this weekend after reconfigured to use "burst" in server lines
>> 
>> The use of "burst" against other peoples' time servers is generally
>> considered to be abuse unless you have received permission to do so.

[snip]

> Anyway "burst" works and I now give myself permission to use
> "burst" to set time from my own ntp servers which is as good
> a compromise as any :-)

Great.

> Can you then suggest how it's at all possible for ntpd to be
> of any use on a mobile connection with such high latency?

Add to that the effects of aggressive power saving.

> I just need to get something working that's significantly
> better than wristwatch time.

Perhaps you need to choose a different tool.

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

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

Re: [ntp:questions] ntpd: time reset problem

[Steve Kostecke]

On 2009-09-14, Unruh  wrote:

> Steve Kostecke  writes:
>
>>Why are you changing the minpoll / maxpoll ?
>
>>Please try again without the minpoll / maxpoll modifiers.
>
> That has absolutely nothing to do with his problem. In fact having a
> smaller maxpoll saved him sooner from whatever destroyed his time.

If his clock is that unstable I doubt that he ever reached maxpoll.

> Note that he is running a vm

I can't find the article that states this fact.

> and the time on a vm is terrible.

You're preaching to the choir. ... 

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

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

Re: [ntp:questions] ntpd: time reset problem

[David Lord]

Steve Kostecke wrote:
> On 2009-09-14, David Lord  wrote:
> 
>> Frank Elsner wrote:
>>
>> OT you also have rather a lot of sources specified and if just for a
>> single box it seems a bit excessive and could be trimmed to four or
>> five (I'd also guess some of those eight get same refid).
> 
> Red Herring.

No, you missed the OT.

> 
>> I've just been trying mobile broadband on a high latency connection
>> and it was too much for ntpd at 1-2 sec average and 150ms best to 10
>> sec/timeout at worst :-)
>>
>> Then this weekend after reconfigured to use "burst" in server lines
> 
> "burst" is an 8x multiplier that is applied to each poll.
> 
> The use of "burst" against other peoples' time servers is generally
> considered to be abuse unless you have received permission to do so.

Can you then suggest how it's at all possible for ntpd to be
of any use on a mobile connection with such high latency?

Minpoll was also set to 8 which doesn't exactly compensate
but does mitigate to some extent.

Probably from that quick test where time was set to within
20 ms rather than still 2 sec out after 30 min the poll
interval could have been reduced further, however I'm pretty
sure using other than "burst" would not have synced the time
before system had to be shutdown.

I just need to get something working that's significantly
better than wristwatch time.

Anyway "burst" works and I now give myself permission to use
"burst" to set time from my own ntp servers which is as good
a compromise as any :-)

They are on public facing servers but I probably don't have
sufficient usage allowance to offer them as pool servers.


David

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

Re: [ntp:questions] ntpd: time reset problem

[Steve Kostecke]

On 2009-09-14, David Lord  wrote:

> Frank Elsner wrote:
>
> OT you also have rather a lot of sources specified and if just for a
> single box it seems a bit excessive and could be trimmed to four or
> five (I'd also guess some of those eight get same refid).

Red Herring.

> I've just been trying mobile broadband on a high latency connection
> and it was too much for ntpd at 1-2 sec average and 150ms best to 10
> sec/timeout at worst :-)
>
> Then this weekend after reconfigured to use "burst" in server lines

"burst" is an 8x multiplier that is applied to each poll.

The use of "burst" against other peoples' time servers is generally
considered to be abuse unless you have received permission to do so.

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

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

Re: [ntp:questions] ntpd: time reset problem

[Unruh]

Steve Kostecke  writes:

>On 2009-09-14, Frank Elsner  wrote:

>> The relevant lines read:
>>
>> server times.tubit.tu-berlin.de   minpoll 6 maxpoll 8
>> server ntps1-0.cs.tu-berlin.deminpoll 6 maxpoll 8
>> server ntps1-1.cs.tu-berlin.deminpoll 6 maxpoll 8
>> server zeit.fu-berlin.de  minpoll 6 maxpoll 8
>> server ntp1.ptb.deminpoll 6 maxpoll 8
>> server ntp2.ptb.deminpoll 6 maxpoll 8
>> server ntp1.rz.uni-konstanz.deminpoll 6 maxpoll 8
>> server rustime01.rus.uni-stuttgart.de minpoll 6 maxpoll 8

>Why are you changing the minpoll / maxpoll ?

>Please try again without the minpoll / maxpoll modifiers.

That has absolutely nothing to do with his problem. In fact having a smaller 
maxpoll saved
him sooner from whatever destroyed his time. Note that he is running a vm and 
the time on
a vm is terrible. To have this number of sources and then to run on a vm is a 
bit of
insanity but it won't hurt, just as his non-efault maxpoll also will not hurt 
him (it may
increase the load on the servers a bit)


>> # Undisciplined Local Clock. This is a fake driver intended for backup
>> # and when no outside source of synchronized time is available.
>> server  127.127.1.0 # local clock
>> fudge   127.127.1.0 stratum 10

>The Undisciplined Local Clock is only needed if this ntpd must be able
>to serve time to others when no real time sources are available. It
>should not be considered a backup for a "leaf-node" system.

Agreed. That like is not needed.


>Do you have a driftfile line?

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

Re: [ntp:questions] ntpd: time reset problem

[David Lord]

Frank Elsner wrote:
> Steve Kostecke wrote:
>> On 2009-09-14, Frank Elsner  wrote:
>>
>>> The relevant lines read:
>>>
>>> server times.tubit.tu-berlin.de   minpoll 6 maxpoll 8
>>> server ntps1-0.cs.tu-berlin.deminpoll 6 maxpoll 8
>>> server ntps1-1.cs.tu-berlin.deminpoll 6 maxpoll 8
>>> server zeit.fu-berlin.de  minpoll 6 maxpoll 8
>>> server ntp1.ptb.deminpoll 6 maxpoll 8
>>> server ntp2.ptb.deminpoll 6 maxpoll 8
>>> server ntp1.rz.uni-konstanz.deminpoll 6 maxpoll 8
>>> server rustime01.rus.uni-stuttgart.de minpoll 6 maxpoll 8
>>
>> Why are you changing the minpoll / maxpoll ?
> 
> Copied from some example.
> 
>> Please try again without the minpoll / maxpoll modifiers.
> 
> Ok, I will remove the minpoll / maxpoll modifiers.
> 
>>> # Undisciplined Local Clock. This is a fake driver intended for backup
>>> # and when no outside source of synchronized time is available.
>>> server  127.127.1.0 # local clock
>>> fudge   127.127.1.0 stratum 10
>>
>> The Undisciplined Local Clock is only needed if this ntpd must be able
>> to serve time to others when no real time sources are available. It
>> should not be considered a backup for a "leaf-node" system.
>>
>> Do you have a driftfile line?
> 
> Yes, this one:
>  116.833

?

I'll guess that's content of your drift file rather than
location specified in ntp.conf.

OT you also have rather a lot of sources specified and if
just for a single box it seems a bit excessive and could
be trimmed to four or five (I'd also guess some of those
eight get same refid).

What's output from commands "ntpq -c lpeers" and
"ntpdc -c loopinfo"?

I've just been trying mobile broadband on a high latency
connection and it was too much for ntpd at 1-2 sec average
and 150ms best to 10 sec/timeout at worst :-)

Then this weekend after reconfigured to use "burst" in server
lines and initial ntpd -q, it's synced in a few minutes but
pinging various sites now shows the very high latency has gone
away (all < 300ms), still not very good but good enough.

David

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

Re: [ntp:questions] ntpd: time reset problem

[Steve Kostecke]

On 2009-09-14, Frank Elsner  wrote:

> The relevant lines read:
>
> server times.tubit.tu-berlin.de   minpoll 6 maxpoll 8
> server ntps1-0.cs.tu-berlin.deminpoll 6 maxpoll 8
> server ntps1-1.cs.tu-berlin.deminpoll 6 maxpoll 8
> server zeit.fu-berlin.de  minpoll 6 maxpoll 8
> server ntp1.ptb.deminpoll 6 maxpoll 8
> server ntp2.ptb.deminpoll 6 maxpoll 8
> server ntp1.rz.uni-konstanz.deminpoll 6 maxpoll 8
> server rustime01.rus.uni-stuttgart.de minpoll 6 maxpoll 8

Why are you changing the minpoll / maxpoll ?

Please try again without the minpoll / maxpoll modifiers.

> # Undisciplined Local Clock. This is a fake driver intended for backup
> # and when no outside source of synchronized time is available.
> server  127.127.1.0 # local clock
> fudge   127.127.1.0 stratum 10

The Undisciplined Local Clock is only needed if this ntpd must be able
to serve time to others when no real time sources are available. It
should not be considered a backup for a "leaf-node" system.

Do you have a driftfile line?

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

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

Re: [ntp:questions] ntpd: time reset problem

[Frank Elsner]

Steve Kostecke wrote:
> On 2009-09-14, Frank Elsner  wrote:
> 
>> The relevant lines read:
>>
>> server times.tubit.tu-berlin.de   minpoll 6 maxpoll 8
>> server ntps1-0.cs.tu-berlin.deminpoll 6 maxpoll 8
>> server ntps1-1.cs.tu-berlin.deminpoll 6 maxpoll 8
>> server zeit.fu-berlin.de  minpoll 6 maxpoll 8
>> server ntp1.ptb.deminpoll 6 maxpoll 8
>> server ntp2.ptb.deminpoll 6 maxpoll 8
>> server ntp1.rz.uni-konstanz.deminpoll 6 maxpoll 8
>> server rustime01.rus.uni-stuttgart.de minpoll 6 maxpoll 8
> 
> Why are you changing the minpoll / maxpoll ?

Copied from some example.

> Please try again without the minpoll / maxpoll modifiers.

Ok, I will remove the minpoll / maxpoll modifiers.

>> # Undisciplined Local Clock. This is a fake driver intended for backup
>> # and when no outside source of synchronized time is available.
>> server  127.127.1.0 # local clock
>> fudge   127.127.1.0 stratum 10
> 
> The Undisciplined Local Clock is only needed if this ntpd must be able
> to serve time to others when no real time sources are available. It
> should not be considered a backup for a "leaf-node" system.
> 
> Do you have a driftfile line?

Yes, this one:
  116.833


--Frank Elsner

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

Re: [ntp:questions] ntpd: time reset problem

[Brian Utterback]

Hmm. It's interesting that the value is almost exactly 1/10th the 
value in the thread. But it doesn't seem to be that a single rogue 
return from gettimeofday could have caused this. The system clock does 
end up 434 seconds behind, relative to the server, so it doesn't seem 
like a transient error could cause this.

It would be interesting to know what OS the OP is running.

Todd Glassey wrote:
> Brian Utterback wrote:
>> Richard B. Gilbert wrote:
>>
>>   
> You may find this interesting.  http://lkml.org/lkml/2007/8/23/96
 Sep 10 20:58:07 seymour ntpd[9104]: synchronized to 134.34.3.18, 
 stratum 1
 Sep 10 21:21:02 seymour dovecot: dovecot: Fatal: Time just moved 
 backwards by 434 seconds. [ ... ]
 Sep 10 21:26:36 seymour ntpd[9104]: no servers reachable
 Sep 10 21:42:56 seymour ntpd[9104]: synchronized to 192.53.103.104, 
 stratum 1
 Sep 10 21:50:55 seymour ntpd[9104]: time reset +434.824810 s
   
>>
>>  
>>> Your clock got yanked around by at least one rogue server!  This sort 
>>> of thing is the reason for configuring four, five, or seven servers.
>>>
>>> It might be helpful if you post your ntp.conf file.
>>> 
>>
>> No, it wasn't yanked by a rogue server. It wasn't yanked by NTP at 
>> all. If NTP set the clock backwards, there would be a message that 
>> says so. Instead, dovecot notices, and then sometime later NTP notices 
>> and puts it back to where it is supposed to be. This isn't an NTP 
>> issue at all, it was something external to NTP that yanked the clock.
>>
>> Brian Utterback
>>
>> ___
>> questions mailing list
>> questions@lists.ntp.org
>> https://lists.ntp.org/mailman/listinfo/questions
>> 
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 
>> 270.13.94/2367 - Release Date: 09/13/09 05:50:00
>>
>>   
> 

-- 
blu

It's bad civic hygiene to build technologies that could someday be
used to facilitate a police state. - Bruce Schneier
--
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] ntpd: time reset problem

[Frank Elsner]

Richard B. Gilbert wrote:

   [ ... ]

> It might be helpful if you post your ntp.conf file.

The relevant lines read:

server times.tubit.tu-berlin.de   minpoll 6 maxpoll 8
server ntps1-0.cs.tu-berlin.deminpoll 6 maxpoll 8
server ntps1-1.cs.tu-berlin.deminpoll 6 maxpoll 8
server zeit.fu-berlin.de  minpoll 6 maxpoll 8
server ntp1.ptb.deminpoll 6 maxpoll 8
server ntp2.ptb.deminpoll 6 maxpoll 8
server ntp1.rz.uni-konstanz.deminpoll 6 maxpoll 8
server rustime01.rus.uni-stuttgart.de minpoll 6 maxpoll 8

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
server  127.127.1.0 # local clock
fudge   127.127.1.0 stratum 10


HTH, Frank Elsner

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

Re: [ntp:questions] ntpd: time reset problem

[Richard B. Gilbert]

Brian Utterback wrote:
> Richard B. Gilbert wrote:
> 
>>> Sep 10 20:58:07 seymour ntpd[9104]: synchronized to 134.34.3.18, 
>>> stratum 1
>>> Sep 10 21:21:02 seymour dovecot: dovecot: Fatal: Time just moved 
>>> backwards by 434 seconds. [ ... ]
>>> Sep 10 21:26:36 seymour ntpd[9104]: no servers reachable
>>> Sep 10 21:42:56 seymour ntpd[9104]: synchronized to 192.53.103.104, 
>>> stratum 1
>>> Sep 10 21:50:55 seymour ntpd[9104]: time reset +434.824810 s
> 
>>
>> Your clock got yanked around by at least one rogue server!  This sort 
>> of thing is the reason for configuring four, five, or seven servers.
>>
>> It might be helpful if you post your ntp.conf file.
> 
> No, it wasn't yanked by a rogue server. It wasn't yanked by NTP at all. 
> If NTP set the clock backwards, there would be a message that says so. 
> Instead, dovecot notices, and then sometime later NTP notices and puts 
> it back to where it is supposed to be. This isn't an NTP issue at all, 
> it was something external to NTP that yanked the clock.
> 
> Brian Utterback

Okay!  Something jerked the time around and dovecot, whatever that is, 
noticed it and complained.  Twenty-nine minutes later NTPD stepped the 
time to reverse the previous step.

Do you suppose this is another case of someone stepping the time to 
"test" ntpd?


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

Re: [ntp:questions] ntpd: time reset problem

[Brian Utterback]

Richard B. Gilbert wrote:

>> Sep 10 20:58:07 seymour ntpd[9104]: synchronized to 134.34.3.18, 
>> stratum 1
>> Sep 10 21:21:02 seymour dovecot: dovecot: Fatal: Time just moved 
>> backwards by 434 seconds. [ ... ]
>> Sep 10 21:26:36 seymour ntpd[9104]: no servers reachable
>> Sep 10 21:42:56 seymour ntpd[9104]: synchronized to 192.53.103.104, 
>> stratum 1
>> Sep 10 21:50:55 seymour ntpd[9104]: time reset +434.824810 s

> 
> Your clock got yanked around by at least one rogue server!  This sort of 
> thing is the reason for configuring four, five, or seven servers.
> 
> It might be helpful if you post your ntp.conf file.

No, it wasn't yanked by a rogue server. It wasn't yanked by NTP at 
all. If NTP set the clock backwards, there would be a message that 
says so. Instead, dovecot notices, and then sometime later NTP notices 
and puts it back to where it is supposed to be. This isn't an NTP 
issue at all, it was something external to NTP that yanked the clock.

Brian Utterback

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

Re: [ntp:questions] ntpd: time reset problem

[Phil . Newlon]

> Is not in the software distribution from here. Apparently, your version
of ntpd has been modified.

David -

Dovecot is the same application I use to POP3 mail from my SMTP gateway to
my portal.  All it is doing is squawking about the problem because it
remembers what time it was the last time it checked the mail, then when it
checks again it raises a warning flag.

Phil
Notice: This e-mail message and its 
attachments are the property of Wendy's/Arby's Group Inc. 
or one of its subsidiaries and may contain 
confidential or legally privileged information intended
solely for the use of the addressee(s). If you 
are not an intended recipient, then any use, copying or
distribution of this message or its 
attachments is strictly prohibited. If you received this message in
error, please notify the sender and delete 
this message entirely from your system.

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

Re: [ntp:questions] ntpd: time reset problem

[David Mills]

Frank,

The message

Sep 10 21:21:02 seymour dovecot: dovecot: Fatal: Time just moved backwards by 
434 seconds. [ ... ]

Is not in the software distribution from here. Apparently, your version of ntpd 
has been modified. Even so, the probably cause is a defective server your 
protostats file should have more detailed information.

Dave

Frank Elsner wrote:

>Hello *,
>
>strange happening yesterday. See this logfile lines:
>
>Sep 10 20:45:52 seymour ntpd[9104]: synchronized to 192.53.103.108, stratum 1
>Sep 10 20:58:07 seymour ntpd[9104]: synchronized to 134.34.3.18, stratum 1
>Sep 10 21:21:02 seymour dovecot: dovecot: Fatal: Time just moved backwards by 
>434 seconds. [ ... ]
>Sep 10 21:26:36 seymour ntpd[9104]: no servers reachable
>Sep 10 21:42:56 seymour ntpd[9104]: synchronized to 192.53.103.104, stratum 1
>Sep 10 21:50:55 seymour ntpd[9104]: time reset +434.824810 s
>Sep 10 21:54:09 seymour ntpd[9104]: synchronized to 130.149.7.71, stratum 2
>Sep 10 21:55:07 seymour ntpd[9104]: synchronized to 129.69.1.153, stratum 1
>
>
>What happened to the clock between 20:58:07 and 21:42:56?
>I guess ntpd should never set the time the hard way.
>The software is ntp-4.2.4p2-1.fc6. Yes, I know it's old.
>
>The dovecot issue is not a topic, it just triggered my attention :-)
>
>
>
>--Frank Elsner
>
>___
>questions mailing list
>questions@lists.ntp.org
>https://lists.ntp.org/mailman/listinfo/questions
>  
>

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

Re: [ntp:questions] ntpd: time reset problem

[Steve Kostecke]

On 2009-09-11, Frank Elsner  wrote:

> strange happening yesterday. See this logfile lines:

Is this a VM?

> Sep 10 20:45:52 seymour ntpd[9104]: synchronized to 192.53.103.108, stratum 1
> Sep 10 20:58:07 seymour ntpd[9104]: synchronized to 134.34.3.18, stratum 1
> Sep 10 21:21:02 seymour dovecot: dovecot: Fatal: Time just moved backwards by 
> 434 seconds. [ ... ]

That's 7.25 minutes. Note that the last message from ntpd was ~23
minutes prior to the message from dovecot.

> Sep 10 21:26:36 seymour ntpd[9104]: no servers reachable
> Sep 10 21:42:56 seymour ntpd[9104]: synchronized to 192.53.103.104, stratum 1
> Sep 10 21:50:55 seymour ntpd[9104]: time reset +434.824810 s

This is where ntpd realized the the time was off.

> Sep 10 21:54:09 seymour ntpd[9104]: synchronized to 130.149.7.71, stratum 2
> Sep 10 21:55:07 seymour ntpd[9104]: synchronized to 129.69.1.153, stratum 1
>
> What happened to the clock between 20:58:07 and 21:42:56?

I'd be more concerned about what happened between the ntpd log entry at
Sep 10 20:58:07 and the dovecot error message at Sep 10 21:21:02. That's
the period where something pushed the clock back by ~7.25 minutes.

> I guess ntpd should never set the time the hard way.

It only did so because the clock was pushed so far off in such a short
time.

> The software is ntp-4.2.4p2-1.fc6. Yes, I know it's old.

It's a little old. But not ancient.

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

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

Re: [ntp:questions] ntpd: time reset problem

[Richard B. Gilbert]

Frank Elsner wrote:
> Hello *,
> 
> strange happening yesterday. See this logfile lines:
> 
> Sep 10 20:45:52 seymour ntpd[9104]: synchronized to 192.53.103.108, 
> stratum 1
> Sep 10 20:58:07 seymour ntpd[9104]: synchronized to 134.34.3.18, stratum 1
> Sep 10 21:21:02 seymour dovecot: dovecot: Fatal: Time just moved 
> backwards by 434 seconds. [ ... ]
> Sep 10 21:26:36 seymour ntpd[9104]: no servers reachable
> Sep 10 21:42:56 seymour ntpd[9104]: synchronized to 192.53.103.104, 
> stratum 1
> Sep 10 21:50:55 seymour ntpd[9104]: time reset +434.824810 s
> Sep 10 21:54:09 seymour ntpd[9104]: synchronized to 130.149.7.71, stratum 2
> Sep 10 21:55:07 seymour ntpd[9104]: synchronized to 129.69.1.153, stratum 1
> 
> 
> What happened to the clock between 20:58:07 and 21:42:56?
> I guess ntpd should never set the time the hard way.
> The software is ntp-4.2.4p2-1.fc6. Yes, I know it's old.
> 
> The dovecot issue is not a topic, it just triggered my attention :-)
> 
> 
> 
> --Frank Elsner

Your clock got yanked around by at least one rogue server!  This sort of 
thing is the reason for configuring four, five, or seven servers.

It might be helpful if you post your ntp.conf file.

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

[ntp:questions] ntpd: time reset problem

[Frank Elsner]

Hello *,

strange happening yesterday. See this logfile lines:

Sep 10 20:45:52 seymour ntpd[9104]: synchronized to 192.53.103.108, stratum 1
Sep 10 20:58:07 seymour ntpd[9104]: synchronized to 134.34.3.18, stratum 1
Sep 10 21:21:02 seymour dovecot: dovecot: Fatal: Time just moved backwards by 
434 seconds. [ ... ]
Sep 10 21:26:36 seymour ntpd[9104]: no servers reachable
Sep 10 21:42:56 seymour ntpd[9104]: synchronized to 192.53.103.104, stratum 1
Sep 10 21:50:55 seymour ntpd[9104]: time reset +434.824810 s
Sep 10 21:54:09 seymour ntpd[9104]: synchronized to 130.149.7.71, stratum 2
Sep 10 21:55:07 seymour ntpd[9104]: synchronized to 129.69.1.153, stratum 1


What happened to the clock between 20:58:07 and 21:42:56?
I guess ntpd should never set the time the hard way.
The software is ntp-4.2.4p2-1.fc6. Yes, I know it's old.

The dovecot issue is not a topic, it just triggered my attention :-)



--Frank Elsner

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