[ntp:questions] bad time with a laptop on windows 7

2014-08-01 Thread Greg Hennessy
I have a dell laptop running windows 7 with a trible accutime gold gps that runs my telescope. My timing requirements are rather modest, I'd like to be within 10 milliseconds of the correct time, but since my observatory isn't connected to the internet, I use the trible. My laptop has no temperatur

Re: [ntp:questions] LOCL clock reachability not 377?

2014-08-01 Thread E-Mail Sent to this address will be added to the BlackLists
Rob wrote: > Martin Burnicki wrote: >> In the example above the daemon could also just write >> the sync status to the SHM segment. >> Since the "noselect" keyword is given ntpd would poll >> it but not try to use it as normal refclock. > > Yes but if I remember well the SHM clock does not hav

Re: [ntp:questions] LOCL clock reachability not 377?

2014-08-01 Thread Harlan Stenn
Martin Burnicki writes: > Harlan Stenn wrote: >> And the General Timestamp API (GTSAPI) project from NTF would nicely >> wrap this information into a timestamp for you, directly. >> >>> For cases 2a) and 2b) there is no absolute time available from the >>> PPS source. If a status is available this

Re: [ntp:questions] LOCL clock reachability not 377?

2014-08-01 Thread Miroslav Lichvar
On Fri, Aug 01, 2014 at 12:59:32PM +0200, Martin Burnicki wrote: > Miroslav Lichvar wrote: > >To generalize it a bit more, there could be also a case of a PPS that > >is not locked in phase and a case of a PPS that's not even locked in > >frequency. When only a source with poor short-term stability

Re: [ntp:questions] LOCL clock reachability not 377?

2014-08-01 Thread Rob
Martin Burnicki wrote: > Rob wrote: >> Martin Burnicki wrote: >>> This could basically work with all types of refclock, e.g.: >>> >>> # refclocks with PPS signal and status, but no absolute time >>> server 127.127.8.0 noselect >>> server 127.127.22.0 stat 127.127.8.0 # sync state from parse driv

Re: [ntp:questions] LOCL clock reachability not 377?

2014-08-01 Thread Martin Burnicki
Rob wrote: I think your suggestions are very good. Thanks! Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] LOCL clock reachability not 377?

2014-08-01 Thread Martin Burnicki
Rob wrote: Martin Burnicki wrote: A reboot is a restart and on a restart you need an external source for the seconds. Why? The time is copied to the CMOS clock regularly, and one could expect that during the short reboot the CMOS would not drift away so much that the time could not be synced

Re: [ntp:questions] LOCL clock reachability not 377?

2014-08-01 Thread Martin Burnicki
Rob wrote: Martin Burnicki wrote: This could basically work with all types of refclock, e.g.: # refclocks with PPS signal and status, but no absolute time server 127.127.8.0 noselect server 127.127.22.0 stat 127.127.8.0 # sync state from parse driver server 127.127.28.0 noselect server 127.1

Re: [ntp:questions] LOCL clock reachability not 377?

2014-08-01 Thread Rob
Martin Burnicki wrote: >>> My point is that most of the internal clocks on computers are well able >>> to maintain the time to better than a second for a long time, even if >>> they were freewheeling, and if disciplined by a PPS, they are able to >>> maintain the time forever (well, until the next

Re: [ntp:questions] LOCL clock reachability not 377?

2014-08-01 Thread Rob
Martin Burnicki wrote: > Rob wrote: >> Martin Burnicki wrote: >>> This sounds good. I think we'd have to distinguish some basic cases a >>> few of which immediately come to my mind: >> >> It looks good. >> >> What is important for my box (but maybe only for mine...) is that there >> is some metho

Re: [ntp:questions] LOCL clock reachability not 377?

2014-08-01 Thread Rob
Martin Burnicki wrote: >>> A reboot is a restart and on a restart you need an external source for >>> the seconds. >> >> Why? The time is copied to the CMOS clock regularly, and one could >> expect that during the short reboot the CMOS would not drift away so >> much that the time could not be sy

Re: [ntp:questions] LOCL clock reachability not 377?

2014-08-01 Thread Martin Burnicki
Miroslav Lichvar wrote: On Thu, Jul 31, 2014 at 04:31:08PM +0200, Martin Burnicki wrote: This sounds good. I think we'd have to distinguish some basic cases a few of which immediately come to my mind: 1) A refclock provides absolute time, status, and a PPS signal 1a) The refclock contains a go

Re: [ntp:questions] LOCL clock reachability not 377?

2014-08-01 Thread Miroslav Lichvar
On Thu, Jul 31, 2014 at 10:43:12PM +, Rob wrote: > William Unruh wrote: > > I think you need to read up on the cmos clock. As I said, it reports > > only the seconds, but is settable and "readable" to microseconds. > > The CMOS clock is running off a 32768Hz crystal, so no way it can be > mo

Re: [ntp:questions] LOCL clock reachability not 377?

2014-08-01 Thread Miroslav Lichvar
On Thu, Jul 31, 2014 at 04:31:08PM +0200, Martin Burnicki wrote: > This sounds good. I think we'd have to distinguish some basic cases a few of > which immediately come to my mind: > > 1) A refclock provides absolute time, status, and a PPS signal > > 1a) The refclock contains a good oscillator,

Re: [ntp:questions] LOCL clock reachability not 377?

2014-08-01 Thread Martin Burnicki
Harlan Stenn wrote: Martin Burnicki writes: Miroslav Lichvar wrote: Agreed, it would be useful to have an option to specify the PPS->time source association for each PPS refclock directly. In chrony, this is done with the lock refclock option. It's typically used like this: refclock SHM 0 off

Re: [ntp:questions] LOCL clock reachability not 377?

2014-08-01 Thread Martin Burnicki
Rob wrote: William Unruh wrote: On 2014-07-31, Rob wrote: William Unruh wrote: On 2014-07-31, Martin Burnicki wrote: Unlike otherwise stated in this thread I don't think it's a good idea to leave the 1 PPS signal alone disciplining the time of the NTP server. This can easily yield unfore

Re: [ntp:questions] LOCL clock reachability not 377?

2014-08-01 Thread Martin Burnicki
William Unruh wrote: Yes, not entirely surprizing, especially considering the way ntp is designed right now. This is a combination of bad ntpd design, and restart when an external source is mandatory. I think the design was OK when it was originally invented many years ago. However, as you can

Re: [ntp:questions] LOCL clock reachability not 377?

2014-08-01 Thread Martin Burnicki
Rob wrote: William Unruh wrote: On 2014-07-31, Martin Burnicki wrote: Unlike otherwise stated in this thread I don't think it's a good idea to leave the 1 PPS signal alone disciplining the time of the NTP server. This can easily yield unforeseen problems, similarly as if you use an IRIG time

Re: [ntp:questions] LOCL clock reachability not 377?

2014-08-01 Thread Martin Burnicki
Rob wrote: Martin Burnicki wrote: This sounds good. I think we'd have to distinguish some basic cases a few of which immediately come to my mind: It looks good. What is important for my box (but maybe only for mine...) is that there is some method to feed OK/FAULT status to ntpd without a re

Re: [ntp:questions] LOCL clock reachability not 377?

2014-08-01 Thread mike cook
Le 1 août 2014 à 00:43, Rob a écrit : > William Unruh wrote: >> I think you need to read up on the cmos clock. As I said, it reports >> only the seconds, but is settable and "readable" to microseconds. > > The CMOS clock is running off a 32768Hz crystal, so no way it can be > more accurately s