Hi,
I asked my original question to see if the process could be improved.
For instance, it would be good if there was direct pointers to the
various distributions page where packaging state and availability for
various releases would be shown and updates. This is what can be found
for
Hi,
On 03/23/2017 05:12 PM, Martin Burnicki wrote:
Magnus Danielson schrieb:
Hi Martin,
On 03/23/2017 03:25 PM, Martin Burnicki wrote:
Hi Magnus,
Magnus Danielson wrote:
Hi,
On 03/22/2017 02:27 PM, David Taylor wrote:
NTP 4.2.8p10 released
Windows binaries working on Windows-XP SP3
Hi Martin,
On 03/23/2017 03:25 PM, Martin Burnicki wrote:
Hi Magnus,
Magnus Danielson wrote:
Hi,
On 03/22/2017 02:27 PM, David Taylor wrote:
NTP 4.2.8p10 released
Windows binaries working on Windows-XP SP3 & later - download:
http://www.satsignal.eu/ntp/x86/index.html
Source:
Hi,
On 03/22/2017 02:27 PM, David Taylor wrote:
NTP 4.2.8p10 released
Windows binaries working on Windows-XP SP3 & later - download:
http://www.satsignal.eu/ntp/x86/index.html
Source: http://archive.ntp.org/ntp4/ntp-4.2/ntp-4.2.8p10.tar.gz
Is bugs generated in distros?
Debian for instance.
Harlan,
On 03/06/2015 10:35 AM, Harlan Stenn wrote:
Folks,
A while ago we got a request from the embedded folks asking for a way to
limit the writing of the drift file unless there was a big enough
change in the value to warrant this.
Somebody came up with an interesting way to do this that
Harlan,
On 03/07/2015 12:12 PM, Harlan Stenn wrote:
OK, a fair amount of good stuff is being discussed.
Do we mostly all agree that the purpose of the drift file is to give
ntpd a hint as to the frequency drift at startup?
If so...
The current mechanism is designed to handle the case where
Hi,
On 01/15/2015 03:06 AM, Harlan Stenn wrote:
I'm trying to figure out if anybody is actively using autokey, in a
production deployment.
If you are, please let me know - I have some questions for you.
We use it to pull leap-second info off the NTP servers.
It took some effort to get it
On 07/08/2014 12:11 PM, Jason Rabel wrote:
There are two obvious ways to go for an embedded client.
One way would be to use the sntp code as the base.
The other would be to either use the current NTP codebase and use the
configure options to disable all the refclocks and anything else you
Danny,
On 07/07/2014 04:00 PM, Danny Mayer wrote:
On 7/6/2014 2:42 AM, Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Discussion appreciated.
I think it is best to remove KOD from ntpd.
It does not serve a useful purpose, because precisely the kind of
clients that you want to say goodbye to,
On 07/07/2014 04:10 PM, Danny Mayer wrote:
The experience with blocking has actually being negative and we have
seen traffic actually INCREASE after it is blocked because the client,
not having received a response, tries more often. This has been observed
in the wild.
This might be true for
On 07/07/2014 04:50 PM, Majdi S. Abbas wrote:
On Mon, Jul 07, 2014 at 08:35:25AM +0100, David Taylor wrote:
Seconded.
Why remove KOD when it has to be expressly enabled (via
restrict kod and limited)?
I'd rather see a two tier system, where you can enable
the use of KOD
On 07/06/2014 12:38 PM, Terje Mathisen wrote:
Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Discussion appreciated.
I think it is best to remove KOD from ntpd.
It does not serve a useful purpose, because precisely the kind of
clients that you want to say goodbye to, do not support it.
In
Detha,
On 07/06/2014 03:23 PM, detha wrote:
On Sun, 06 Jul 2014 12:28:09 +, Magnus Danielson wrote:
For cases like that, KOD won't help at all.
All the state table/KOD/filter rules mitigation approaches I have seen so
far are limited to one server. Maybe time to take a look at a DNSBL
Harlan,
On 07/05/2014 11:40 PM, Harlan Stenn wrote:
Folks,
I was chatting with PHK about:
http://support.ntp.org/bin/view/Dev/NtpProtocolResponseMatrix
http://bugs.ntp.org/show_bug.cgi?id=2367
and how we probably want to extend KOD coverage to more than just the
limited case.
I was
Harlan,
On 07/06/2014 02:18 AM, Harlan Stenn wrote:
Magnus,
Yes, we know that if we decide to track finely-grained behavior we'll
need to watch how {IP,port} responds when getting {no,KOD} responses.
Just want to gently remind you.
We might just want a syslog entry for KOD, because it's
On 24/03/14 14:38, Joe Gwinn wrote:
Magnus,
In article 532fa47b.7060...@rubidium.dyndns.org, Magnus Danielson
mag...@rubidium.dyndns.org wrote:
Joe,
On 23/03/14 23:20, Joe Gwinn wrote:
Magnus,
In article 532e45db.5000...@rubidium.dyndns.org, Magnus Danielson
mag...@rubidium.dyndns.org
Joe,
On 23/03/14 23:20, Joe Gwinn wrote:
Magnus,
In article 532e45db.5000...@rubidium.dyndns.org, Magnus Danielson
mag...@rubidium.dyndns.org wrote:
Joe,
On 21/03/14 17:04, Joe Gwinn wrote:
[snip]
It is interesting. I've now read it reasonably closely.
The basic approach is to express
Joe,
On 21/03/14 16:17, Joe Gwinn wrote:
Magnus,
Thus, another fairly severe environment.
I have a personal war story from 1992: At a Air Traffic Control center
in Canada, one 19 cabinet had the green (safety ground) and white
(power neutral) cables transposed. This caused 2.3 Vrms at 180
On 19/03/14 10:43, Martin Burnicki wrote:
Magnus Danielson wrote:
On 18/03/14 10:17, Martin Burnicki wrote:
We have mades some tests and found that NTP can yield the same accuracy
as NTP if also hardware timestamping of NTP packets is supported on all
nodes, similar as for PTP.
In fact
On 19/03/14 10:50, Miroslav Lichvar wrote:
On Tue, Mar 18, 2014 at 10:20:08PM +0100, Magnus Danielson wrote:
No, it's not. NTP is being perceived to be software timestamping
but nothing prohibits you from doing it in hardware. Similarly can
you implement PTP with software time-stamping
On 19/03/14 18:51, E-Mail Sent to this address will be added to the
BlackLists wrote:
Martin Burnicki wrote:
Magnus Danielson wrote:
Indeed. If you read the right article from 1990 you
also know you can do it on L1 C/A only by monitoring
both code and carrier phase, as their ionospheric
Hi Joe,
On 20/03/14 01:53, Joe Gwinn wrote:
In article 5328ad2...@rubidium.dyndns.org, Magnus Danielson
mag...@rubidium.dyndns.org wrote:
On 18/03/14 01:24, Joe Gwinn wrote:
I've used IRIG-B004 DCLS before, for cables two meters long within a
cabinet. Worked well. How well do they handle
Joe,
On 19/03/14 11:55, Joe Gwinn wrote:
In article 5328aaa6.70...@rubidium.dyndns.org, Magnus Danielson
mag...@rubidium.dyndns.org wrote:
On 18/03/14 01:36, Joe Gwinn wrote:
In article 5327757e.5040...@rubidium.dyndns.org, Magnus Danielson
mag...@rubidium.dyndns.org wrote:
Is that formal
On 18/03/14 01:36, Joe Gwinn wrote:
In article 5327757e.5040...@rubidium.dyndns.org, Magnus Danielson
mag...@rubidium.dyndns.org wrote:
Joe,
On 16/03/14 23:16, Joe Gwinn wrote:
I recall seeing something from Dr. Mills saying that a formal proof had
been found showing that no packet-exchange
On 18/03/14 01:24, Joe Gwinn wrote:
In article 532778bf.50...@rubidium.dyndns.org, Magnus Danielson
mag...@rubidium.dyndns.org wrote:
On 17/03/14 13:50, Joe Gwinn wrote:
In article lg61s4$ong$3...@dont-email.me, William Unruh
un...@invalid.ca wrote:
On 2014-03-16, Joe Gwinn joegw
On 18/03/14 02:45, Paul wrote:
On Mon, Mar 17, 2014 at 9:33 PM, Joseph Gwinn joegw...@comcast.net wrote:
Will it do 100 meters or more, in bad neighborhoods?
I'm not the right person to ask but since it is expected to maintain
between 2.5 and 100 nanosecond sync with CPE nodes (cable
On 18/03/14 09:59, Martin Burnicki wrote:
Magnus Danielson wrote:
On 17/03/14 09:48, Martin Burnicki wrote:
You'd need hardware (FPGA?) which can be clocked at 1 GHz, and even in
the hardware signal processing you'd need to account for a number of
signal propagation delays which you can
On 18/03/14 10:17, Martin Burnicki wrote:
Paul wrote:
On Mon, Mar 17, 2014 at 8:07 PM, Joe Gwinn joegw...@comcast.net wrote:
People are also lusting after sub-microsecond sync.
Sure but not optimally in comp.protocols.ntp/questions@lists.ntp.org.
With some help NTP can be quite good but
Joe,
On 16/03/14 23:16, Joe Gwinn wrote:
I recall seeing something from Dr. Mills saying that a formal proof had
been found showing that no packet-exchange protocol (like NTP) could
tell delay asymmetry from clock offset. Can anyone provide a reference
to this proof?
It's relative simple.
On 17/03/14 09:48, Martin Burnicki wrote:
William Unruh wrote:
On 2014-03-16, Joe Gwinn joegw...@comcast.net wrote:
I keep seeing claims that Precision Time Protocol (IEEE 1588-2008) can
achieve sub-microsecond to nanosecond-level synchronization over
ethernet (with the right hardware to be
On 17/03/14 13:50, Joe Gwinn wrote:
In article lg61s4$ong$3...@dont-email.me, William Unruh
un...@invalid.ca wrote:
On 2014-03-16, Joe Gwinn joegw...@comcast.net wrote:
I keep seeing claims that Precision Time Protocol (IEEE 1588-2008) can
achieve sub-microsecond to nanosecond-level
On 02/03/14 19:31, William Unruh wrote:
On 2014-03-02, Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
On 2014-03-01 15:43, boostinbad...@gmail.com wrote:
My NTP server is part of the pool project and appears to be running fine.
Comcast contacted me about a month ago to let me know that
On 12/07/2013 11:39 PM, Harlan Stenn wrote:
Magnus Danielson writes:
The drift-file-accelerated lock-in isn't robust. Current behavior of
response isn't very useful for most people experiencing it.
I'm not sure I'd agree with the word most. It's certainly worked very
well on hundreds
On 12/06/2013 10:53 AM, Harlan Stenn wrote:
mike cook writes:
If you know the drift file is unreliable, you should delete it. ntpd
will then perform a frequency calibration before entering the main
loop. ...
This is what has been recommended for ages but it doesn't completely
fix the issue.
On 12/07/2013 01:17 AM, unruh wrote:
On 2013-12-06, Magnus Danielson mag...@rubidium.dyndns.org wrote:
On 12/06/2013 10:53 AM, Harlan Stenn wrote:
mike cook writes:
If you know the drift file is unreliable, you should delete it. ntpd
will then perform a frequency calibration before entering
Antonio,
On 11/04/2013 06:40 PM, Antonio Marcheselli wrote:
If the oscillator drifts from last drift-file write, outside of +/- 15
ppm if I recall it, it fails to lock in again.
It would be good if it could bail out and do normal frequency
acquisition if that occurs.
That particular feature
On 11/03/2013 12:43 AM, David Woolley wrote:
On 02/11/13 21:48, David Lord wrote:
Ntpd writes to its drift file and also ntp.log. The drift file
is critical and is used and updated at intervals by ntpd.
The drift file is an optimisation. ntpd should work without it, but
will take longer
On 11/03/2013 06:26 PM, Magnus Danielson wrote:
On 11/03/2013 12:43 AM, David Woolley wrote:
On 02/11/13 21:48, David Lord wrote:
Ntpd writes to its drift file and also ntp.log. The drift file
is critical and is used and updated at intervals by ntpd.
The drift file is an optimisation. ntpd
Hi,
On 09/02/2013 12:39 AM, Harlan Stenn wrote:
unruh writes:
In this case ntpd wandered off by hours with no complaint. That is not a
proper behaviour of a professional piece of software.
And I don't remember the config file. If the target platform has a
config file with setting that
On 09/02/2013 02:33 PM, David Lord wrote:
Harlan Stenn wrote:
David Lord writes:
Magnus Danielson wrote:
server ntp1.kth.se iburst maxpoll 7
server ntp2.kth.se iburst maxpoll 7
server ntp3.kth.se iburst maxpoll 7
server ntp1.sp.se iburst maxpoll 7
server ntp2.sp.se iburst maxpoll 7
On 09/02/2013 03:49 AM, unruh wrote:
On 2013-09-01, Magnus Danielson mag...@rubidium.dyndns.org wrote:
server ntp1.kth.se iburst maxpoll 7
server ntp2.kth.se iburst maxpoll 7
server ntp3.kth.se iburst maxpoll 7
server ntp1.sp.se iburst maxpoll 7
server ntp2.sp.se iburst maxpoll 7
# Access
On 09/01/2013 10:42 PM, unruh wrote:
On 2013-09-01, Steve Kostecke koste...@ntp.org wrote:
On 2013-09-01, Rob nom...@example.com wrote:
The NTP Reference Implementation is free software. The copyright
holder (The University of Delaware) makes no representations
about the suitability this
On 08/30/2013 04:17 AM, E-Mail Sent to this address will be added to the
BlackLists wrote:
Magnus Danielson wrote:
We had another incident where a node configured with multiple NTP
sources had an NTPD which when asked with ntpdc have peers, looks like
things are all OK, but with offsets less
Hi,
We had another incident where a node configured with multiple NTP
sources had an NTPD which when asked with ntpdc have peers, looks like
things are all OK, but with offsets less than a second, while the node
in fact was 6 days off the mark. Only on a number of ntpdc querries did
some of the
On 08/18/2013 07:51 AM, David Taylor wrote:
On 17/08/2013 18:31, Magnus Danielson wrote:
[]
What might be useful is to store the corrected 1024 weeks offsets, since
if the NTPD is restarted, those corrections can be applied up-front and
then can these corrected values be used to provide good
On 08/18/2013 12:16 PM, Rob wrote:
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
On 18/08/2013 09:19, Magnus Danielson wrote:
[]
If you want this feature to be disabled by default, you end up with
causing the disruption that the fix is there to avoid. Few will know
that they need
On 08/17/2013 06:02 PM, David Taylor wrote:
On 17/08/2013 09:30, Terje Mathisen wrote:
David Taylor wrote:
[]
Thanks for the pointers to the documents. A pity that they haven't
been
able to find two or three spare bits to reduce the 1024 week ambiguity
to nearer a half-century or even 100
On 08/16/2013 05:44 AM, David Taylor wrote:
On 15/08/2013 21:33, Magnus Danielson wrote:
[]
They completely avoid it by not numbering it that way. They have their
own numbering scheme that fit's the system, and the conversion over to
UTC is an added feature. It's all in ICD-GPS-200
On 08/15/2013 11:02 PM, unruh wrote:
On 2013-08-15, Magnus Danielson mag...@rubidium.dyndns.org wrote:
On 08/15/2013 10:22 AM, David Taylor wrote:
On 15/08/2013 08:34, Rob wrote:
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
On 14/08/2013 17:44, Rob wrote:
[]
How does a good
On 08/16/2013 10:36 AM, David Taylor wrote:
Yes, all my receivers are very simple, consumer-level ones. Sometimes
I see as low as 2m location accuracy on the GPS 60 CSx, more likely
3m when walking.
Thanks for the pointers to the documents. A pity that they haven't
been able to find two
On 08/16/2013 03:34 PM, David Taylor wrote:
On 16/08/2013 13:02, John Hasler wrote:
David Taylor writes:
A pity that they haven't been able to find two or three spare bits to
reduce the 1024 week ambiguity to nearer a half-century or even 100
years.
From the Wikipedia article:
To
On 08/15/2013 07:55 AM, David Taylor wrote:
On 14/08/2013 22:07, Harlan Stenn wrote:
David Malone writes:
Indeed - you need to have a timestamp within about ten years of
correct before you start up, otherwise the problem will be worse. Ntp
has the same problem in figuring out the ntp epoch,
On 08/15/2013 10:22 AM, David Taylor wrote:
On 15/08/2013 08:34, Rob wrote:
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
On 14/08/2013 17:44, Rob wrote:
[]
How does a good receiver know the correct time? Does it rely on
local (backed-up) storage, or is there some way of
Hi,
On 08/14/2013 03:54 PM, unruh wrote:
On 2013-08-14, Mark C. Stephens ma...@non-stop.com.au wrote:
Um Let's see, Datum was bought by Austron, who was bought by ... etc.
For collectors such as myself, having this 'mature' equipment still working
is great.
Looking at Mr Malone's code, he
Hi again,
On 08/11/2013 03:36 PM, Magnus Danielson wrote:
Hi David,
On 08/11/2013 08:44 AM, David Taylor wrote:
Today is the start of a new GPS 1024 week epoch - see:
http://adn.agi.com/GNSSWeb/
Folks with really old GPS units are reporting problems, those of us
with current millennium
On 03/27/2013 10:45 PM, David Woolley wrote:
Robert Scott wrote:
I am confused about the proper usage of pool.ntp.org and NIST.
pool.ntp.org seems to be a collection of private sector time servers
offered for all to use, but with registration expected for regular
The pool system has no
Hi again Robert,
On 03/28/2013 04:22 AM, Robert Scott wrote:
On Thu, 28 Mar 2013 02:50:17 GMT, unruhun...@invalid.ca wrote:
You really should read my posts before responding. No, I do not
intend to hard-code NIST or any other server. I never said I wanted
to. No, the app is not intended for
Hi Tom,
On 01/16/2013 03:36 PM, Thomas Laus wrote:
I have not seen this information posted to this newsgroup. The US
NIST radio station WWVB will be changing it's transmission format. The
information can be found at:
http://www.nist.gov/pml/div688/grp40/wwvb.cfm
The old format is still
58 matches
Mail list logo
