Il 03/27/2013 10:24 PM, unruh ha scritto:
You do NOT want to hard code anything into your program. That is
extremely bad form, unless that address is one controlled by you.
Indeed. Robert, please see:
http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse
and in particular:
Robert Scott no-one@notreal.invalid wrote:
To achieve 11 ppm accuracy in frequency I need to have a calibration
time interval that is about 90,000 times as long as the timestamp
uncertainty. If the timestamp uncertainty is, say, 100 msec., the
calibration time period needs to be at least 2.5
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
On 28 Mar 2013 09:57:37 GMT, Rob nom...@example.com wrote:
To achieve an uncertainty below 100ms over connections like that you
will need to do some clever programming where you get multiple time
stamps, measure the roundtriptime on each of them, and discard
outliers before you calculate an
Robert Scott no-one@notreal.invalid wrote:
On 28 Mar 2013 09:57:37 GMT, Rob nom...@example.com wrote:
To achieve an uncertainty below 100ms over connections like that you
will need to do some clever programming where you get multiple time
stamps, measure the roundtriptime on each of them, and
On 28 Mar 2013 13:37:50 GMT, Rob nom...@example.com wrote:
Maybe for your application it would be wise to check the roundtriptime
only to see if it has already fallen from some initial high value,
but not to use it in the calculation of real time (i.e. don't take
a midpoint between request and
On Thu, Mar 28, 2013 at 5:57 AM, Rob nom...@example.com wrote:
so you will need to write an adaptive
algorithm that recognizes what is happening here, and send the queries
quickly enough (I would say at least two per second, maybe 4) to force
the active user algorithm to kick in.
If he sends
Trevor Woerner twoer...@gmail.com wrote:
On Thu, Mar 28, 2013 at 5:57 AM, Rob nom...@example.com wrote:
so you will need to write an adaptive
algorithm that recognizes what is happening here, and send the queries
quickly enough (I would say at least two per second, maybe 4) to force
the
A report on UTC(NIST) - UTC(USNO) can be found at
http://tf.boulder.nist.gov/general/pdf/2663.pdf
On Thu, Mar 28, 2013 at 7:22 AM, Magnus Danielson
mag...@rubidium.dyndns.org wrote:
On 03/27/2013 10:45 PM, David Woolley wrote:
Robert Scott wrote:
I am confused about the proper usage of
On Thu, Mar 28, 2013 at 5:57 AM, Rob nom...@example.com wrote:
so you will need to write an adaptive
algorithm that recognizes what is happening here, and send the queries
quickly enough (I would say at least two per second, maybe 4) to force
the active user algorithm to kick in.
Sending at a
On Thu, 28 Mar 2013 21:21:55 GMT, Harlan Stenn st...@ntp.org wrote:
On Thu, Mar 28, 2013 at 5:57 AM, Rob nom...@example.com wrote:
so you will need to write an adaptive
algorithm that recognizes what is happening here, and send the queries
quickly enough (I would say at least two per second,
Robert Scott wrote:
If I could use a packaged implementation of NTP I would. But I don't
have that option. If I understand correctly, packaged implementations
of NTP are designed specifically for setting the system time. I
The interface to the OS clock is fairly well abstracted for
On 2013-03-28, Robert Scott no-one@notreal.invalid wrote:
On 28 Mar 2013 09:57:37 GMT, Rob nom...@example.com wrote:
To achieve an uncertainty below 100ms over connections like that you
will need to do some clever programming where you get multiple time
stamps, measure the roundtriptime on each
14 matches
Mail list logo
