Ulrich,
That's what JPL tells me, but I don't think they intend the orbiters and
rovers to cling to the nanosecond, even if the Proximity-1 protocol has
some distinctly awesome timestamping capabilities. Best we could do in
simulation with ephemeris data was 10 ms, but that was mainly due to
C
"David L. Mills" <[EMAIL PROTECTED]> writes:
> Evandro,
>
> We didn't account for gravity and time dilation, as the errors in the
> extrapolated ephemeris data dominated the error budget. I am told accurate
> spacecraft navigation needs time to the nanosecond. In principle, the
Wow! Spacecraft st
Evandro,
We didn't account for gravity and time dilation, as the errors in the
extrapolated ephemeris data dominated the error budget. I am told
accurate spacecraft navigation needs time to the nanosecond. In
principle, the Proximity-I protocol and NTP onwire protocol can do that,
I don't thin
On May 4, 2:37 pm, "David L. Mills" <[EMAIL PROTECTED]> wrote:
>
> On symmetry, etc. There are both gravitational and velocity corrections
> relative to both Earth and solar system barycentric time amounting to
> some 15 ms, but current space missions don't worry much about that. The
> mission time
"Unruh" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> [... Delay] assumed to be symmetric and is already cancelled. The
> ONLY way to really measure if there assymetry is to put a real clock
> on each of the machines (Ie, a clock synchronized to usec accuracy to
> UTC-- eg a GPS PP
Dannt,
There is a short briefing on NTP in space on the project page. The first
use of NTP in space was on an AMSAT satellite in the early 80s. NTP has
been used on Shuttle missions via UHF and TDRSS relay to NASA Goddard
servers. I have Shuttle data that show more problems with the laptop
run
[EMAIL PROTECTED] (Danny Mayer) writes:
>Unruh wrote:
>> [EMAIL PROTECTED] (Danny Mayer) writes:
>>
>>> Unruh wrote:
"David L. Mills" <[EMAIL PROTECTED]> writes:
> Brian,
> The longest delay NTP response was from the Moon, as simulated at JPL.
> Next step is the Mars orbite
Unruh wrote:
> [EMAIL PROTECTED] (Danny Mayer) writes:
>
>> Unruh wrote:
>>> "David L. Mills" <[EMAIL PROTECTED]> writes:
>>>
Brian,
The longest delay NTP response was from the Moon, as simulated at JPL.
Next step is the Mars orbiters and then the rovers. JPL discovered the
m
[EMAIL PROTECTED] (Danny Mayer) writes:
>Unruh wrote:
>> "David L. Mills" <[EMAIL PROTECTED]> writes:
>>
>>> Brian,
>>
>>> The longest delay NTP response was from the Moon, as simulated at JPL.
>>> Next step is the Mars orbiters and then the rovers. JPL discovered the
>>> max distance threshol
Unruh wrote:
> "David L. Mills" <[EMAIL PROTECTED]> writes:
>
>> Brian,
>
>> The longest delay NTP response was from the Moon, as simulated at JPL.
>> Next step is the Mars orbiters and then the rovers. JPL discovered the
>> max distance threshold had to be increased to handle the Moon delay.
>
"David L. Mills" <[EMAIL PROTECTED]> writes:
>Brian,
>The longest delay NTP response was from the Moon, as simulated at JPL.
>Next step is the Mars orbiters and then the rovers. JPL discovered the
>max distance threshold had to be increased to handle the Moon delay.
Thats only a few sec.
And
--
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED]
>> On Behalf Of Brian Utterback
>>Sent: Friday, May 02, 2008 7:38 AM
>>To: questions@lists.ntp.org
>>Subject: Re: [ntp:questions] frequency adjusting only
>>
>>David L. Mills wrote:
>>
>&
Brian,
The longest delay NTP response was from the Moon, as simulated at JPL.
Next step is the Mars orbiters and then the rovers. JPL discovered the
max distance threshold had to be increased to handle the Moon delay.
The longest lived NTP headbanger was when I used ARPAnet IMP 29 back in
the
be made as simple as possible, but no simpler" Albert
Einstein
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> On Behalf Of Brian Utterback
> Sent: Friday, May 02, 2008 7:38 AM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions
David L. Mills wrote:
> Suspecting such could be the case between NTP servers and clients, I
> designed an experiment to detect such things and found small but
> significant LRD effects with lags up to TWO WEEKS! At short lags up to
> several network turns this can be explained by packet length
Richard B. Gilbert wrote:
> A lot may depend on your LAN. A large 10/100 UTP net (300 nodes) in
> which traffic might pass through two or three switches to reach its
> destination is not necessarily well behaved for timing purposes.
The original poster runs a Gigabit Ethernet and a single swit
ough and across
>>network where sync is transferred (mostly for wireless backhaul), I've
>>developed a healthy respect for many of the various sampling and
>>filtering functions in ntp.
>>
>>
>>
>>
>>
>>Greg Dowd
>>gdowd at
u test in a small LAN has very little bearing on the
>>performance possible in various types of real networks of greater
>
> scale..
>
> Agreed.
> But the OP wanted to use it in a small lan.
>
>
>>
>>Greg Dowd
>>gdowd at symmetricom dot com (antispam forma
>>Symmetricom, Inc.
>>www.symmetricom.com
>>"Everything should be made as simple as possible, but no simpler" Albert
>>Einstein
>>
>>-Original Message-
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED] On Behalf
>>Of Bill Unru
Greg Dowd wrote:
>
> So, while NTP and PTP essentially have a like set of timestamps and
> fundamental assumptions, I wouldn't say they do the same thing. The
Note, I think the issue was between NTP and PTP without hardware
support, not between NTP and PTP used as intended, with special hardwa
but no simpler" Albert
Einstein
> -Original Message-
> From: Bill Unruh [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 30, 2008 5:18 PM
> To: Greg Dowd
> Cc: questions@lists.ntp.org
> Subject: RE: [ntp:questions] frequency adjusting only
>
> On Wed, 30 A
possible, but no simpler" Albert
> Einstein
And I think ntp is too simple.
>
> -Original Message-
> From: Bill Unruh [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 30, 2008 3:21 PM
> To: Greg Dowd
> Cc: questions@lists.ntp.org
> Subject: RE: [ntp:qu
D]
Sent: Wednesday, April 30, 2008 3:21 PM
To: Greg Dowd
Cc: questions@lists.ntp.org
Subject: RE: [ntp:questions] frequency adjusting only
On Wed, 30 Apr 2008, Greg Dowd wrote:
> As noted, these are really stability measurements of the difference
> between two clocks. The absolute accurac
uot;Everything should be made as simple as possible, but no simpler" Albert
> Einstein
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Bill Unruh
> Sent: Wednesday, April 30, 2008 1:20 PM
> To: questions@lists.ntp.org
&g
icom.com
"Everything should be made as simple as possible, but no simpler" Albert
Einstein
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Bill Unruh
Sent: Wednesday, April 30, 2008 1:20 PM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] fr
On Wed, Apr 30, 2008 at 6:19 PM, Bill Unruh <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (maxime louvel) writes:
>
> >On Tue, Apr 29, 2008 at 6:27 PM, Unruh <[EMAIL PROTECTED]> wrote:
>
> >> [EMAIL PROTECTED] (maxime louvel) writes:
> >>
> >> >Hi,
> >>
> >> >I have know run a lot of tests.
> >>
[EMAIL PROTECTED] (maxime louvel) writes:
>On Tue, Apr 29, 2008 at 6:27 PM, Unruh <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] (maxime louvel) writes:
>>
>> >Hi,
>>
>> >I have know run a lot of tests.
>> >Just to let you know what I've got so far.
>> >I have tried NTP, and NTP + PTP (Precision
[EMAIL PROTECTED] (maxime louvel) writes:
>On Tue, Apr 29, 2008 at 6:27 PM, Unruh <[EMAIL PROTECTED]> wrote:
>You're right on this point, what I actually get with PTP is delay of 100
>usec, with a variation of 10 usec.
>But I'm only interested in the variation as the 100usec can be removed
>ea
[EMAIL PROTECTED] (maxime louvel) writes:
>On Tue, Apr 29, 2008 at 6:27 PM, Unruh <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] (maxime louvel) writes:
>>
>> >Hi,
>>
>> >I have know run a lot of tests.
>> >Just to let you know what I've got so far.
>> >I have tried NTP, and NTP + PTP (Precision
On Tue, Apr 29, 2008 at 6:27 PM, Unruh <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (maxime louvel) writes:
>
> >Hi,
>
> >I have know run a lot of tests.
> >Just to let you know what I've got so far.
> >I have tried NTP, and NTP + PTP (Precision Time Protocol).
> >I haven't tried Chrony nor TSCl
[EMAIL PROTECTED] (maxime louvel) writes:
>Hi,
>I have know run a lot of tests.
>Just to let you know what I've got so far.
>I have tried NTP, and NTP + PTP (Precision Time Protocol).
>I haven't tried Chrony nor TSClock.
>I have used the software only implementation of PTP (ptpd).
>With NTP only
Hi,
I have know run a lot of tests.
Just to let you know what I've got so far.
I have tried NTP, and NTP + PTP (Precision Time Protocol).
I haven't tried Chrony nor TSClock.
I have used the software only implementation of PTP (ptpd).
With NTP only I have got an accuracy around 1ms,
with one node
On Mon, Apr 28, 2008 at 7:14 PM, Unruh <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Hal Murray) writes:
>
> >>Sorry it's actually difficult for me to precise this topic for
> >>confidentiality reason of course and also because I'm an intern and thus
> >>there for a short period. Hence I don't k
[EMAIL PROTECTED] (Hal Murray) writes:
>>Sorry it's actually difficult for me to precise this topic for
>>confidentiality reason of course and also because I'm an intern and thus
>>there for a short period. Hence I don't know exactly why myself. This is
>>just one of the requirement of my project.
Hal Murray wrote:
>> Sorry it's actually difficult for me to precise this topic for
>> confidentiality reason of course and also because I'm an intern and thus
>> there for a short period. Hence I don't know exactly why myself. This is
>> just one of the requirement of my project.
>
> Keeping a ha
>Sorry it's actually difficult for me to precise this topic for
>confidentiality reason of course and also because I'm an intern and thus
>there for a short period. Hence I don't know exactly why myself. This is
>just one of the requirement of my project.
Keeping a handful of machines synchronized
maxime louvel wrote:
> Sorry it's actually difficult for me to precise this topic for
> confidentiality reason of course and also because I'm an intern and thus
You employer needs to engage a specialist consultant under
non-disclosure agreement.
> there for a short period. Hence I don't know ex
On Sun, Apr 27, 2008 at 4:01 AM, Danny Mayer <[EMAIL PROTECTED]> wrote:
> maxime louvel wrote:
>
> > - 10 usec is of course not for NFS, but I am also using NFS (no other
> > choice) and that was just an example to tell that I need to keep my
> > nodes
> > synchronised to real time, not just betwe
maxime louvel wrote:
> - 10 usec is of course not for NFS, but I am also using NFS (no other
> choice) and that was just an example to tell that I need to keep my nodes
> synchronised to real time, not just between them
>
> - I have no idea if the applications can be fixed, as they are not mine an
[EMAIL PROTECTED] (maxime louvel) writes:
>- 10 usec is of course not for NFS, but I am also using NFS (no other
>choice) and that was just an example to tell that I need to keep my nodes
>synchronised to real time, not just between them
There isnothing within any OS that is sensitive to time on
- 10 usec is of course not for NFS, but I am also using NFS (no other
choice) and that was just an example to tell that I need to keep my nodes
synchronised to real time, not just between them
- I have no idea if the applications can be fixed, as they are not mine and
I'm not in charge of them ;)
>I actually don't really understand why a GPS would improve my
>synchronisation.
If your master server has GPS, its time will be more stable.
That means your clients can sync to a stable clock rather than
trying to track a clock that is wobbling around. (Things
are simpler and work better when t
>- I have to keep my nodes synchronised to real time, for several reason:
>they use NFS, they interact with the outside world.
I think your initial goal was synchronization to 10 microseconds.
Do you really need that for NFS? (Do file times include the fractions
of a second?)
Most interaction
- I am running ntp at max priority (ntpd -N)
- My nodes are real machines, not VM
- I haven't tried chrony yet, but I probably will.
On Fri, Apr 25, 2008 at 3:29 PM, Unruh <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (maxime louvel) writes:
>
> >On Fri, Apr 25, 2008 at 8:14 AM, David Woolley
[EMAIL PROTECTED] (maxime louvel) writes:
>On Fri, Apr 25, 2008 at 8:14 AM, David Woolley
><[EMAIL PROTECTED]> wrote:
>>
>> A node synchronized to GPS *with PPS* will be much more stable than a
>> system that is free-running or synchronised by other typical means.
>>
>Ok , thus I should have a
David Woolley <[EMAIL PROTECTED]> writes:
>maxime louvel wrote:
>> Unless if the GPS allow my server to be more stable and thus I can assume to
>> get a better synchronisation...
>Firstly, I got two threads confused, so some of my comments weren't
>based on your situation. In particular, the u
On Fri, Apr 25, 2008 at 2:35 AM, maxime louvel <[EMAIL PROTECTED]> wrote:
> Ok , thus I should have a better accuracy for the nodes synchronised to
> this server than for the nodes synchronised to server itself synchronised
> through internet to a stratum 2.
> But that still doesn't solve the pr
On Fri, Apr 25, 2008 at 8:14 AM, David Woolley
<[EMAIL PROTECTED]> wrote:
> maxime louvel wrote:
>
> > Unless if the GPS allow my server to be more stable and thus I can assume
> to
> > get a better synchronisation...
>
> Firstly, I got two threads confused, so some of my comments weren't
> based
maxime louvel wrote:
> Unless if the GPS allow my server to be more stable and thus I can assume to
> get a better synchronisation...
Firstly, I got two threads confused, so some of my comments weren't
based on your situation. In particular, the unsynchronised DCF system
relates to the other t
On Thu, Apr 24, 2008 at 11:27 PM, David Woolley
<[EMAIL PROTECTED]> wrote:
> maxime louvel wrote:
> >
> > - I can't use a GPS or other material. I though I wouldn't need any
> because
> > I don't won't a great accuracy with the real time, just between my nodes.
> I
> > also think it would have bee
maxime louvel wrote:
>
> - I can't use a GPS or other material. I though I wouldn't need any because
> I don't won't a great accuracy with the real time, just between my nodes. I
> also think it would have been easier and better to have a common high
> precision time source (GPS)... But I can't af
maxime louvel wrote:
> - The decision of buying a GPS is not mine ...
> So let's say for now that's still not possible, if no other solution is
> found I'll conclude that a GPS has to be bought.
>
> - Danny, you're talking about the delay I got with ntpq -p ?
>
I haven't seen what your delays a
On 2008-04-23, maxime louvel <[EMAIL PROTECTED]> wrote:
> The decision of buying a GPS is not mine ... So let's say for now
> that's still not possible, if no other solution is found I'll conclude
> that a GPS has to be bought.
I find it curious to hear people say that time stability is critical
[EMAIL PROTECTED] (maxime louvel) writes:
>Hi,
>- my network contains only one switch, and all the node are in the same
>room.
>Thus I don't think cabling is a problem. I still have to check the latency
>of the switch.
>- I can't use a GPS or other material. I though I wouldn't need any because
Steve Kostecke <[EMAIL PROTECTED]> writes:
>On 2008-04-23, Unruh <[EMAIL PROTECTED]> wrote:
>> See www.theory.physics/chrony/chrony.html
>That hostname does not resolve for me.
OOps. Fingers faster than brain
www.theory.physics.ubc.ca/chrony/chrony.html
___
[EMAIL PROTECTED] (maxime louvel) writes:
>HI again,
>I am thinking that NTP should behave correctly if the activity on the nodes
>(small temperature, hence frequency variation) and on the network (small
>latency of the switch) are roughly constant.
>But if not it will have some trouble, either t
[EMAIL PROTECTED] (maxime louvel) writes:
>I have checked the roundtrip delay with ntpq -p.
>It seems that I always have 0.147 ms.
>But I haven't monitored it properly, just each time I ran the command I got
>this value
Yes. Mine are around 200us (.2ms)
>On Wed, Apr 23, 2008 at 7:30 AM, maxime
On Tue, Apr 22, 2008 at 9:39 AM, Richard B. Gilbert
<[EMAIL PROTECTED]> wrote:
> That's going to be very difficult to do! Getting the whole herd to the
> point where the difference between any two nodes is less than 50 usec is
> damned near impossible using NTP on a LAN. You might want to conside
- The decision of buying a GPS is not mine ...
So let's say for now that's still not possible, if no other solution is
found I'll conclude that a GPS has to be bought.
- Danny, you're talking about the delay I got with ntpq -p ?
- I have chosen a broadcast configuration for two reasons :
- easi
On 2008-04-23, Unruh <[EMAIL PROTECTED]> wrote:
> Steve Kostecke <[EMAIL PROTECTED]> writes:
>
>>Here's an aggregated plot of the node offsets on my LAN over the
>>last 24 hours. I see +3/-5 milliseconds, not anything near 5-15
>>microseconds.
[snip: URL for plot]
> I agree those are pretty bad.
maxime louvel wrote:
> Thanks,
>
> I am actually using 4 public NTP server, which whom my node-1
> synchronises to.
> Then node-1 broadcasts the time to all the other nodes in the subnet.
>
If you are using broadcast mode then you have two additional issues that
you need to deal with:
1) auth
maxime louvel wrote:
> Hi,
>
> - my network contains only one switch, and all the node are in the same
> room.
> Thus I don't think cabling is a problem. I still have to check the latency
> of the switch.
>
> - I can't use a GPS or other material. I though I wouldn't need any because
> I don't wo
I have checked the roundtrip delay with ntpq -p.
It seems that I always have 0.147 ms.
But I haven't monitored it properly, just each time I ran the command I got
this value
On Wed, Apr 23, 2008 at 7:30 AM, maxime louvel <[EMAIL PROTECTED]> wrote:
> HI again,
>
> I am thinking that NTP should beh
HI again,
I am thinking that NTP should behave correctly if the activity on the nodes
(small temperature, hence frequency variation) and on the network (small
latency of the switch) are roughly constant.
But if not it will have some trouble, either to compensate the frequency
change or to deal wit
Hi,
- my network contains only one switch, and all the node are in the same
room.
Thus I don't think cabling is a problem. I still have to check the latency
of the switch.
- I can't use a GPS or other material. I though I wouldn't need any because
I don't won't a great accuracy with the real time
Steve Kostecke <[EMAIL PROTECTED]> writes:
>On 2008-04-22, Unruh <[EMAIL PROTECTED]> wrote:
>> Steve Kostecke <[EMAIL PROTECTED]> writes:
>>
>> ??? In my experience, on a Lan ntpd shows an internode offset of about
>> 5-15 usec, and on the internet (ADSL) an offset of about 200usec.
>Here's an a
"Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>Unruh wrote:
>> "Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>>
>>> maxime louvel wrote:
On Tue, Apr 22, 2008 at 2:42 PM, Steve Kostecke <[EMAIL PROTECTED]> wrote:
> On 2008-04-22, maxime louvel <[EMAIL PROTECTED]> wrote:
>
>
[EMAIL PROTECTED] (maxime louvel) writes:
>Hi
>thanks every body,
>I am looking at the other solution and see what's the best for me.
>- My switches shouldn't be overloaded but I have to check that.
>Any idea of how ? Network sniffing ? theory ?
Look at the ntp roundtrip times and see how they
[EMAIL PROTECTED] (Hal Murray) writes:
>> If you compensate for cable
>>delays you can probably get to within 50-100 usec.
>Do the arithmetic. Cable delay is interesting for ns, not microseconds.
>The speed of light is 1 ft/ns. That's in vacuum. It's slower in cable.
On 2008-04-22, Unruh <[EMAIL PROTECTED]> wrote:
> Steve Kostecke <[EMAIL PROTECTED]> writes:
>
> ??? In my experience, on a Lan ntpd shows an internode offset of about
> 5-15 usec, and on the internet (ADSL) an offset of about 200usec.
Here's an aggregated plot of the node offsets on my LAN over
Steve Kostecke <[EMAIL PROTECTED]> writes:
>On 2008-04-22, maxime louvel <[EMAIL PROTECTED]> wrote:
>> On Tue, Apr 22, 2008 at 2:42 PM, Steve Kostecke <[EMAIL PROTECTED]> wrote:
>>>
>>> >I don't care if the synchronisation to the public NTP is accurate
>>> >around half a second.
>>>
>>> You're di
maxime louvel wrote:
> My goal is to achieve a synchronisation between the nodes (not with the
> public NTP server) within 50 usec.
I think you can rule out using -x, then. 50 microseconds is pretty
tight timing and basically requires that you use the kernel time
discipline, as well as paying
Unruh wrote:
> "Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>
>> maxime louvel wrote:
>>> On Tue, Apr 22, 2008 at 2:42 PM, Steve Kostecke <[EMAIL PROTECTED]> wrote:
>>>
On 2008-04-22, maxime louvel <[EMAIL PROTECTED]> wrote:
> My goal is to achieve a synchronisation between the n
> If you compensate for cable
>delays you can probably get to within 50-100 usec.
Do the arithmetic. Cable delay is interesting for ns, not microseconds.
The speed of light is 1 ft/ns. That's in vacuum. It's slower in cable.
Inexpensive cable is about 1/2 c. Good cabl
>It is the latency not the speed of the switches that is important.
You can correct for a fixed latency. What's nasty is variable
latency.
--
These are my opinions, not necessarily my employer's. I hate spam.
___
questions mailing list
questions@l
Hi
thanks every body,
I am looking at the other solution and see what's the best for me.
- My switches shouldn't be overloaded but I have to check that.
Any idea of how ? Network sniffing ? theory ?
- I think I have a problem with the temperature, indeed I have let only ntpd
run on the node for
[EMAIL PROTECTED] (maxime louvel) writes:
>On Tue, Apr 22, 2008 at 2:42 PM, Steve Kostecke <[EMAIL PROTECTED]> wrote:
>> On 2008-04-22, maxime louvel <[EMAIL PROTECTED]> wrote:
>>
>> > My goal is to achieve a synchronisation between the nodes (not
>> > with the public NTP server) within 50 usec.
"Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>maxime louvel wrote:
>> On Tue, Apr 22, 2008 at 2:42 PM, Steve Kostecke <[EMAIL PROTECTED]> wrote:
>>
>>> On 2008-04-22, maxime louvel <[EMAIL PROTECTED]> wrote:
>>>
My goal is to achieve a synchronisation between the nodes (not
with the
On 2008-04-22, maxime louvel <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 22, 2008 at 2:42 PM, Steve Kostecke <[EMAIL PROTECTED]> wrote:
>>
>> >I don't care if the synchronisation to the public NTP is accurate
>> >around half a second.
>>
>> You're displaying a common misconception about NTP.
[snip]
[EMAIL PROTECTED] (maxime louvel) writes:
>Thanks,
>I am actually using 4 public NTP server, which whom my node-1 synchronises
>to.
>Then node-1 broadcasts the time to all the other nodes in the subnet.
>My goal is to achieve a synchronisation between the nodes (not with the
>public NTP server)
maxime louvel wrote:
> On Tue, Apr 22, 2008 at 2:42 PM, Steve Kostecke <[EMAIL PROTECTED]> wrote:
>
>> On 2008-04-22, maxime louvel <[EMAIL PROTECTED]> wrote:
>>
>>> My goal is to achieve a synchronisation between the nodes (not
>>> with the public NTP server) within 50 usec.
>> You may want to ex
You might want to take a look at TSCclock developed at the University
of Melbourne:
http://www.cubinlab.ee.unimelb.edu.au/~darryl/Publications/ISPCS07_camera.pdf
Gene
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/list
On Tue, Apr 22, 2008 at 2:42 PM, Steve Kostecke <[EMAIL PROTECTED]> wrote:
> On 2008-04-22, maxime louvel <[EMAIL PROTECTED]> wrote:
>
> > My goal is to achieve a synchronisation between the nodes (not
> > with the public NTP server) within 50 usec.
>
> You may want to explore other synchronizatio
On 2008-04-22, maxime louvel <[EMAIL PROTECTED]> wrote:
> My goal is to achieve a synchronisation between the nodes (not
> with the public NTP server) within 50 usec.
You may want to explore other synchronization options such as IRIG,
distributed PPS, or a distributed 10MHz clock.
>I don't care
Thanks,
I am actually using 4 public NTP server, which whom my node-1 synchronises
to.
Then node-1 broadcasts the time to all the other nodes in the subnet.
My goal is to achieve a synchronisation between the nodes (not with the
public NTP server) within 50 usec.
I don't care if the synchronisati
maxime louvel wrote:
> Thanks for your answer,
>
> I can't have a step on the clock because that would screw up my
> applications.
> However if I keep the load within a certain range I should fine, don't I ?
> I am synchronising one node to several public NTP servers, and the others
> nodes are sy
>>> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (maxime louvel) writes:
maxime> Thanks for your answer, I can't have a step on the clock because
maxime> that would screw up my applications. However if I keep the load
maxime> within a certain range I should fine, don't I ? I am synchronisin
Thanks for your answer,
I can't have a step on the clock because that would screw up my
applications.
However if I keep the load within a certain range I should fine, don't I ?
I am synchronising one node to several public NTP servers, and the others
nodes are synchronised to the first one.
There
Unruh wrote:
> Harlan Stenn <[EMAIL PROTECTED]> writes:
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (maxime louvel) writes:
>
>> maxime> Hi, I would like to know if NTP (and particularly ntpd) is able to
>> maxime> synchronise a clock, only playing with the frequency. I want to
>>
Harlan Stenn <[EMAIL PROTECTED]> writes:
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (maxime louvel) writes:
>maxime> Hi, I would like to know if NTP (and particularly ntpd) is able to
>maxime> synchronise a clock, only playing with the frequency. I want to
>maxime> avoid any step in
>>> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (maxime louvel) writes:
maxime> Hi, I would like to know if NTP (and particularly ntpd) is able to
maxime> synchronise a clock, only playing with the frequency. I want to
maxime> avoid any step in the clock that would probably screw up my netw
Hi,
I would like to know if NTP (and particularly ntpd) is able to synchronise a
clock,
only playing with the frequency.
I want to avoid any step in the clock that would probably screw up my
network appli.
thanks,
Maxime
--
Maxime Louvel
0044 7964 80
43 Allen road
Whitemore reans
WV60AW Wo
92 matches
Mail list logo
