Hello,
I'm trying to configure a small network for high precision time.
Recently acquired an Endrun CDMA time server that runs like
a dream, tracking CDMA time to about +/- 5 microseconds.
The clients are a rag-tag assembly of diverse systems including
a Centos 4.5 Linux i686, Linux x86_64, Su
[EMAIL PROTECTED] wrote:
> Hello,
>
> I'm trying to configure a small network for high precision time.
> Recently acquired an Endrun CDMA time server that runs like
> a dream, tracking CDMA time to about +/- 5 microseconds.
>
> The clients are a rag-tag assembly of diverse systems including
>
[EMAIL PROTECTED] writes:
>Hello,
>I'm trying to configure a small network for high precision time.
>Recently acquired an Endrun CDMA time server that runs like
>a dream, tracking CDMA time to about +/- 5 microseconds.
No idea what CDMa time is, but that does not matter.
Do you have peerstats
[EMAIL PROTECTED] wrote:
> The clients are a rag-tag assembly of diverse systems including
> a Centos 4.5 Linux i686, Linux x86_64, Sun Ultra 10, Sun Ultra 80,
> IBM RS/6000 44p, Windows 2003 X64, and a Windows XP laptop.
How are you interpolating the 16ms ticks on the Windows system? How are
"Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>[EMAIL PROTECTED] wrote:
>> Hello,
>>
>> I'm trying to configure a small network for high precision time.
>> Recently acquired an Endrun CDMA time server that runs like
>> a dream, tracking CDMA time to about +/- 5 microseconds.
>>
>> The clien
"Unruh" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> [...] Would I really believe that the CDMA cell phone network
> would care if their time signal were accurate to usec?
I would. Because IIUC, this is the basis on which they divide
timeslots between stations.
Groetjes,
Maarten
David Woolley <[EMAIL PROTECTED]> writes:
>[EMAIL PROTECTED] wrote:
>> The clients are a rag-tag assembly of diverse systems including
>> a Centos 4.5 Linux i686, Linux x86_64, Sun Ultra 10, Sun Ultra 80,
>> IBM RS/6000 44p, Windows 2003 X64, and a Windows XP laptop.
>How are you interpolating
"Unruh" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>> Forcing the poll interval to 16 seconds is not always a good idea!
>> Ntpd will select a poll interval, generally starting at 64 seconds,
>> and ramping up to as long as 1024 s
Unruh wrote:
> "Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>
>
>>[EMAIL PROTECTED] wrote:
>>
>>>Hello,
>>>
>>>I'm trying to configure a small network for high precision time.
>>>Recently acquired an Endrun CDMA time server that runs like
>>>a dream, tracking CDMA time to about +/- 5 micros
Unruh wrote:
> 1 people all polling every 16 sec ( or 1 sec) There is nothing in ntp
> itself that mandates a longer poll interval. In fact a shorter poll
> interval makes ntp much more responsive to changes ( clock drifts, etc)
As I understand it, locking maxpoll low only slightly improves
r
>However once or twice a day, all the systems experience a
>random, uncorrelated time shift of from one to several
>milliseconds.
What does that mean?
I'm guessing that "uncorrelated" means the glitches don't happen
at the same time.
Are all clients seeing occasional problems? Do they match
cro
Unruh wrote:
>>
> I expect that he means the offsets that ntp measures. NTP does NOT correct
I suspect that too.
> random offsets. Ie, if there is noise source which makes the offsets vary
It averages them so as to reduce their effective size.
> by 500usec ntp will not get rid of them. You wil
Maarten Wiltink wrote:
>
> You seem to be missing the point. Once the large errors have been
> corrected, NTP goes on to the small errors. For that, it _needs_ a
> longer poll interval. That this gives the server more air is a
> happy coincidence, but not why it does it.
I don't believe it *needs
On Sun, 30 Mar 2008, [EMAIL PROTECTED] wrote:
> At 04:51 PM 3/30/2008 -0700, Bill Unruh wrote:
>> Are those on the same day?
>
> Yes, same day. Uncorrelated to anything I can identify
> or each other. Same story on all the boxes. Running
> a hefty multi-system compile with heavy NFS and Samba
>
"Maarten Wiltink" <[EMAIL PROTECTED]> writes:
>"Unruh" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]
>> "Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>>> Forcing the poll interval to 16 seconds is not always a good idea!
>>> Ntpd will select a poll interval, generally starting a
Unruh wrote:
>
> I have no idea what this means. ntp simply runs a second order feedback
> network It does not do anything for "large and small" errors.
>
See sections G.4, G.5 and following of RFC 1305 (page 95 and onwards in
the PDF version). A couple of parameters are dynmacially adjusted
Bill Unruh wrote:
> On Sun, 30 Mar 2008, [EMAIL PROTECTED] wrote:
>
You appear to be quoting an off list reply with no indication of
permission, although it is just possible that the email gateway
forwarded it to email subscribers without forwarding it to the usenet
group proper.
Incidentally
On 2008-03-31, David Woolley <[EMAIL PROTECTED]> wrote:
> Bill Unruh wrote:
>
>> On Sun, 30 Mar 2008, [EMAIL PROTECTED] wrote:
>
> You appear to be quoting an off list reply with no indication of
> permission, although it is just possible that the email gateway
> forwarded it to email subscribers
Steve Kostecke wrote:
> On 2008-03-31, David Woolley <[EMAIL PROTECTED]> wrote:
>
>> Bill Unruh wrote:
>>
>>> On Sun, 30 Mar 2008, [EMAIL PROTECTED] wrote:
>> You appear to be quoting an off list reply with no indication of
>> permission, although it is just possible that the email gateway
>> forw
David Woolley schrieb:
> Bill Unruh wrote:
>> On Sun, 30 Mar 2008, [EMAIL PROTECTED] wrote:
>>
>
> You appear to be quoting an off list reply with no indication of
> permission, although it is just possible that the email gateway
> forwarded it to email subscribers without forwarding it to the u
David Woolley <[EMAIL PROTECTED]> writes:
>Bill Unruh wrote:
>> On Sun, 30 Mar 2008, [EMAIL PROTECTED] wrote:
>>
>You appear to be quoting an off list reply with no indication of
>permission, although it is just possible that the email gateway
>forwarded it to email subscribers without forward
Heiko Gerstung wrote:
> time has passed without the signal coming back. This results in the time
> server replying with stratum 12 (for example) after a while and ensures
> that everybody has the same time, although it might be wrong. If a user
> does not want that, they can simply set the loca
David Woolley wrote:
> Heiko Gerstung wrote:
>
>> time has passed without the signal coming back. This results in the
>> time server replying with stratum 12 (for example) after a while and
>> ensures that everybody has the same time, although it might be wrong.
>> If a user does not want that,
Richard B. Gilbert wrote:
> Stratum is taken into account in selecting a time source.
> I can't swear to it but I'd be surprised if three stratum 10 servers
> could out vote one stratum 2 server.
>
At least for RFC1305, stratum is not considered (except in as much as
refid is not checked for str
At 04:51 PM 3/30/2008 -0700, Bill Unruh wrote:
>Are those on the same day?
Yes, same day. Uncorrelated to anything I can identify
or each other. Same story on all the boxes. Running
a hefty multi-system compile with heavy NFS and Samba
traffic does not produce these events, though it disturbs
t
Here are URLs for those two sample graphs:
http://binnacle.cx/file/ntp_hickups_linux.gif
http://binnacle.cx/file/ntp_hickups_win.gif
David Woolley wrote:
>
>> The clients are a rag-tag assembly of diverse systems including
>> a Centos 4.5 Linux i686, Linux x86_64, Sun Ultra 10, Sun Ultra 80,
>>
[EMAIL PROTECTED] writes:
>Here are URLs for those two sample graphs:
>http://binnacle.cx/file/ntp_hickups_linux.gif
>http://binnacle.cx/file/ntp_hickups_win.gif
>David Woolley wrote:
>>
>>> The clients are a rag-tag assembly of diverse systems including
>>> a Centos 4.5 Linux i686, Linux x86_
>>probably have make use of PTP (precision timing protocol).
>
>No idea what that is. If you had wanted super precision you would have put
>a GPS onto each machine, I hope.
>
>From the Wikipedia entry on PTP it looks absolutely no different from ntp.
>I have no idea what the idea is.
The basic
[EMAIL PROTECTED] wrote:
> The generic version of 'ntpd' has some sophisticated code that
>
> handles interpolation. See the source. Power management is
I know that. But the problem is that normal applications just get a
more accurate time for the most recent tick, but still don't see any
Hal Murray wrote:
>>>probably have make use of PTP (precision timing protocol).
>>
>>No idea what that is. If you had wanted super precision you would have put
>>a GPS onto each machine, I hope.
>>
>>From the Wikipedia entry on PTP it looks absolutely no different from ntp.
>>I have no idea what th
On 2008-03-31, David Woolley <[EMAIL PROTECTED]>
wrote:
> Steve Kostecke wrote:
>
>> On 2008-03-31, David Woolley <[EMAIL PROTECTED]> wrote:
>>
>>> Bill Unruh wrote:
>>>
On Sun, 30 Mar 2008, [EMAIL PROTECTED] wrote:
>>>
>>> You appear to be quoting an off list reply with no indication of
>>>
[EMAIL PROTECTED] (Hal Murray) writes:
>>>probably have make use of PTP (precision timing protocol).
>>
>>No idea what that is. If you had wanted super precision you would have put
>>a GPS onto each machine, I hope.
>>
>>From the Wikipedia entry on PTP it looks absolutely no different from ntp.
Martin Burnicki <[EMAIL PROTECTED]> writes:
>Hal Murray wrote:
probably have make use of PTP (precision timing protocol).
>>>
>>>No idea what that is. If you had wanted super precision you would have put
>>>a GPS onto each machine, I hope.
>>>
>>>From the Wikipedia entry on PTP it looks absolu
>>> The basic idea is to do the time stamping in hardware deep in
>>> the network adaper. That avoids lots and lots of jitter.
>
>>Yes, PTP can yield an accuracy better than 100 ns if both the NICs at the
>>clients and the server support hardware timestamping of sent/received PTP
>>packets.
>
>I
>Yes, PTP can yield an accuracy better than 100 ns if both the NICs at the
>clients and the server support hardware timestamping of sent/received PTP
>packets.
>
>On the other hand, also *every* network node between the PTP endpoints has
>to be PTP-aware and compensate the packet delay it introduc
>>The basic idea is to do the time stamping in hardware deep in
>>the network adaper. That avoids lots and lots of jitter.
>
>It avoids some jitter. Does that mean that you have to have special
>hardware (special network cards ...
Yes, and so far they are all expensive.
--
These are my opinion
[EMAIL PROTECTED] (Hal Murray) writes:
The basic idea is to do the time stamping in hardware deep in
the network adaper. That avoids lots and lots of jitter.
>>
>>>Yes, PTP can yield an accuracy better than 100 ns if both the NICs at the
>>>clients and the server support hardware times
[EMAIL PROTECTED] (Hal Murray) writes:
>>Yes, PTP can yield an accuracy better than 100 ns if both the NICs at the
>>clients and the server support hardware timestamping of sent/received PTP
>>packets.
>>
>>On the other hand, also *every* network node between the PTP endpoints has
>>to be PTP-awa
On Mar 30, 8:05 pm, [EMAIL PROTECTED] wrote:
> Might try them later, but I can't belive a high-quality
> SMC switch is causing multi-millisecond delays. Just not
Do you have access to a different (Cisco, Extreme, Foundry, or HP)
switch for testing? If not, try a crossover cable between the NTP
s
Bill,
Unruh wrote:
> Martin Burnicki <[EMAIL PROTECTED]> writes:
>>Yes, PTP can yield an accuracy better than 100 ns if both the NICs at the
>>clients and the server support hardware timestamping of sent/received PTP
>>packets.
>
> I am still confused. To timestamp you have to read the computer's
Unruh wrote:
> [EMAIL PROTECTED] (Hal Murray) writes:
>>You can build a clock into the network adapter and sync it up to the
>>system clock.
>
> And how do you sync it up to the system clock without going through the
> kernel, etc?
Maybe it's better to do it the other way round, i.e. sync the sy
David Woolley schrieb:
> Heiko Gerstung wrote:
>
>> time has passed without the signal coming back. This results in the
>> time server replying with stratum 12 (for example) after a while and
>> ensures that everybody has the same time, although it might be wrong.
>> If a user does not want tha
Hal Murray schrieb:
>> Yes, PTP can yield an accuracy better than 100 ns if both the NICs at the
>> clients and the server support hardware timestamping of sent/received PTP
>> packets.
>>
>> On the other hand, also *every* network node between the PTP endpoints has
>> to be PTP-aware and compensat
David Woolley wrote:
> [EMAIL PROTECTED] wrote:
>> The generic version of 'ntpd' has some sophisticated code that
>>
>> handles interpolation. See the source. Power management is
>
> I know that. But the problem is that normal applications just get a
> more accurate time for the most recent
Original author of the post here. Just stumbled upon this thread (three years
on) as Google has assigned it a relatively high rank.
An update is in order.
Discovered not long after posting the question that the Endrun Praecis Cntp
device has some sort of bug. On occasion the 'ntpd' daemon run
45 matches
Mail list logo
