On 7/11/2013 3:13 AM, Rob wrote:
karpe...@gmail.com wrote:
Hello,
Clients indeed followed server after 2.5 hours.
This night they managed to come from -15s difference to +2.5s and now it seems
trying to slew another direction. They will probably need another half a day to
stop oscillations an
karpe...@gmail.com wrote:
> Any advices how to make them all behave and be closer to each other?
Better system oscillators (TCXO OCXO) for less drift?
External PPS Rubidium/Cesium/GPS/... Refclock for Servers &/or Clients?
# ntp.conf for ALL your (Clients and/or Servers)
tos cohort 1 orphan 11
r
On Thursday, July 11, 2013 4:51:54 PM UTC+2, David Taylor wrote:
> Igor, could you get away with logging two lots of timestamps - from the
> client system clock and from a true UTC source?
Yes, that's what I am thinking of. Otherwise it all becomes way too complicated
and uncertain. And even mor
On 2013-07-11, Rob wrote:
> karpe...@gmail.com wrote:
>> Hello,
>> Clients indeed followed server after 2.5 hours.
>> This night they managed to come from -15s difference to +2.5s and now it
>> seems trying to slew another direction. They will probably need another half
>> a day to stop oscill
On 11/07/2013 15:32, Igor wrote:
Hi Brian,
15 secs was just a sample, I hope it would be less. The problem is that the system
consists of two parts - mission critical (that shall not depend on anything except
itself, which does not really care about timestamps) and data logging that does care.
Hi Brian,
15 secs was just a sample, I hope it would be less. The problem is that the
system consists of two parts - mission critical (that shall not depend on
anything except itself, which does not really care about timestamps) and data
logging that does care. They share same hardware devices d
On 7/11/2013 7:37 AM, Igor wrote:
yes David, true. was kind of stressed and forgot to update legend and values.
these are seconds on both axis.
X is elapsed time and Y is delta between a "real" NTP time and time of server
and two clients.
I'll re-upload gaph.
The graph shows pretty much what
yes David, true. was kind of stressed and forgot to update legend and values.
these are seconds on both axis.
X is elapsed time and Y is delta between a "real" NTP time and time of server
and two clients.
I'll re-upload gaph.
___
questions mailing list
On 11/07/2013 10:12, karpe...@gmail.com wrote:
Yes I think I understand now a lot better the limits where NTP can be used.
Here is the graph image on dropbox:
http://db.tt/CrqH6oeo
I'm starting now the tests with fastest poll rate. Just to try all possible
ways.
It's a completely meaningles
Yes I think I understand now a lot better the limits where NTP can be used.
Here is the graph image on dropbox:
http://db.tt/CrqH6oeo
I'm starting now the tests with fastest poll rate. Just to try all possible
ways.
___
questions mailing list
questio
karpe...@gmail.com wrote:
> Hello,
> Clients indeed followed server after 2.5 hours.
> This night they managed to come from -15s difference to +2.5s and now it
> seems trying to slew another direction. They will probably need another half
> a day to stop oscillations and finally come to zero. P
On 2013-07-11, karpe...@gmail.com wrote:
> Hello,
> Clients indeed followed server after 2.5 hours.
> This night they managed to come from -15s difference to +2.5s and now it
> seems trying to slew another direction. They will probably need another half
> a day to stop oscillations and finally
Hello,
Clients indeed followed server after 2.5 hours.
This night they managed to come from -15s difference to +2.5s and now it seems
trying to slew another direction. They will probably need another half a day to
stop oscillations and finally come to zero. Pity I can't attach a trend picture
h
Thanks! I will wait then few more hours to see if it recovers.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
karpe...@gmail.com wrote:
> Some news from testing. Setup:
> - server 10.10.52.104, with timeshift 14 sec, config:
> tos maxdist 16
> tinker step 0
> server 10.10.2.101
> server 10.9.2.80
> server 127.127.1.0 iburst minpoll 4
> fudge 127.127.1.0 stratum 12
> driftfile /etc/ntp/ntp.drift
>
> - two
Hello,
Some news from testing. Setup:
- server 10.10.52.104, with timeshift 14 sec, config:
tos maxdist 16
tinker step 0
server 10.10.2.101
server 10.9.2.80
server 127.127.1.0 iburst minpoll 4
fudge 127.127.1.0 stratum 12
driftfile /etc/ntp/ntp.drift
- two clients, config:
tos maxdist 16
tinker
6:48 PM (less than a minute ago)
Hello,
Some news from testing. Setup:
- server 10.10.52.104, with timeshift 14 sec, config:
tos maxdist 16
tinker step 0
server 10.10.2.101
server 10.9.2.80
server 127.127.1.0 iburst minpoll 4
fudge 127.127.1.0 stratum 12
driftfile /etc/ntp/ntp.drift
- two clien
On 2013-07-10, E-Mail Sent to this address will be added to the BlackLists
wrote:
> unruh wrote:
>> That was the model he had.
>> A server which all of the clients were supposed to stay
>> within 50ms of, no matter whether or not that server was
>> connected to a time source or not, and no matt
unruh wrote:
> That was the model he had.
> A server which all of the clients were supposed to stay
> within 50ms of, no matter whether or not that server was
> connected to a time source or not, and no matter if,
> after a long disconnect, that server then reconnected to
> a source and found i
On 2013-07-09, Harlan Stenn wrote:
> unruh writes:
>> On 2013-07-09, David Woolley wrote:
>> > On 09/07/13 09:07, Miroslav Lichvar wrote:
>> >
>> >>
>> >> I think the kernel would have to be recompiled with a smaller
>> >> MAXFREQ_SCALED constant or ntpd recompiled with smaller NTP_MAXFREQ if
>>
unruh writes:
> On 2013-07-09, David Woolley wrote:
> > On 09/07/13 09:07, Miroslav Lichvar wrote:
> >
> >>
> >> I think the kernel would have to be recompiled with a smaller
> >> MAXFREQ_SCALED constant or ntpd recompiled with smaller NTP_MAXFREQ if
> >> the kernel discipline is disabled.
> >>
>
On 2013-07-09, David Woolley wrote:
> On 09/07/13 09:07, Miroslav Lichvar wrote:
>
>>
>> I think the kernel would have to be recompiled with a smaller
>> MAXFREQ_SCALED constant or ntpd recompiled with smaller NTP_MAXFREQ if
>> the kernel discipline is disabled.
>>
>
> The kernel discipline will b
On 09/07/13 09:07, Miroslav Lichvar wrote:
I think the kernel would have to be recompiled with a smaller
MAXFREQ_SCALED constant or ntpd recompiled with smaller NTP_MAXFREQ if
the kernel discipline is disabled.
The kernel discipline will be disabled if he forces slewing.
___
Hello,
Thank you all for the help!
I got the idea now which direction to move. I will make some testing and come
back with results.
Thanks again!
Igor.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
On Mon, Jul 08, 2013 at 08:19:12PM +, unruh wrote:
> Now, If we know that the max difference between the client and server's
> drift rate is say 200PPM, then if one could limit the server to only
> slewing at 300PPM then the client should be able to keep up. But I do
> not know of any way of te
karpe...@gmail.com wrote:
> server 127.127.1.0
> fudge 127.127.1.0 stratum 12
try TOS orphan 11
> ... I see the -3 sec time jump.
> I was expecting that NTPD will slowly start to correct the time,
> but it jumps.
Slewalways? tinker step 0 ?
--
E-Mail Sent to this address
will be added to
On 2013-07-08, John Hasler wrote:
> unruh writes:
>> Do you mean none of the slaves ever have to jump to track it? Since
>> all ntpd does ever is either jump or slew.
>
> I mean so that none ever have to slew at the 500PPM max rate.
The problem is that ntpd will keep increasing the slew rate unti
John Hasler writes:
> I mean so that none ever have to slew at the 500PPM max rate.
This one is interesting - in a group of machines each machine may have a
different natural drift rate. If the clock adjustment algorithm doesn't
have a way to handle adjusting the functional equivalent of 'tick' t
unruh writes:
> Do you mean none of the slaves ever have to jump to track it? Since
> all ntpd does ever is either jump or slew.
I mean so that none ever have to slew at the 500PPM max rate.
--
John Hasler
jhas...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA
__
On 2013-07-08, John Hasler wrote:
> unruh writes:
>> lets say one computer has a natural offset of 200PPM and another is
>> -100PPM. When both are slewing at 500PPM, one is effectively slewing
>> at 300 PPM and the other at 600, which goes out by 50ms in about an
>> hour.
>
> Therefor you should t
unruh writes:
> lets say one computer has a natural offset of 200PPM and another is
> -100PPM. When both are slewing at 500PPM, one is effectively slewing
> at 300 PPM and the other at 600, which goes out by 50ms in about an
> hour.
Therefor you should tinker with the slew rate of the master, limi
On 2013-07-08, Rob wrote:
> karpe...@gmail.com wrote:
>> Hello,
>> Thanks for the answers!
>> The reason of such a configuration is simple. Our equipment is a
>> mission-critical set of devices that shall be running without NTP server
>> available. Some drift away from a true time is tolerable.
karpe...@gmail.com wrote:
> Hello,
> Thanks for the answers!
> The reason of such a configuration is simple. Our equipment is a
> mission-critical set of devices that shall be running without NTP server
> available. Some drift away from a true time is tolerable. However, all
> devices must be s
On 2013-07-08, karpe...@gmail.com wrote:
> Hello,
> Thanks for the answers!
> The reason of such a configuration is simple. Our equipment is a
> mission-critical set of devices that shall be running without NTP server
> available. Some drift away from a true time is tolerable. However, all
> de
karpe...@gmail.com wrote:
Hello,
Thanks for the answers!
The reason of such a configuration is simple. Our equipment is a mission-critical set of devices that shall be running without NTP server available. Some drift away from a true time is tolerable. However, all devices must be synched with ea
On Thursday, July 4, 2013 7:19:40 PM UTC+2, unruh wrote:
> With ntpd's limit of 500PPMM, it would take over 2 hours to slew away a 3
> second time difference.
That's exactly what I want from the system - does not matter how slow (even
days will be fine) but without jumps.
Igor.
__
Hello,
Thanks for the answers!
The reason of such a configuration is simple. Our equipment is a
mission-critical set of devices that shall be running without NTP server
available. Some drift away from a true time is tolerable. However, all devices
must be synched with each other, to a max of 50m
On 04/07/13 12:42, karpe...@gmail.com wrote:
[Excessively long line repaired. ]
System comes up and after a while syncs to itself. After it starts
+ to provide my "fake" time reference (+3sec) to clients downstream, I plug
It only serves the bogus time because you used this line:
> server 12
karpe...@gmail.com wrote:
Hello,
I have a problem with NTP configuration when the client loses uplink connection for some time and then re-establishes it.
ntp.conf:
tos maxdist 4
server 10.9.2.80 iburst
server 10.10.2.101 iburst
server 10.10.52.111 iburst
server 127.127.1.0
fudge 127.127.1.0
On 2013-07-04, karpe...@gmail.com wrote:
> Hello,
> I have a problem with NTP configuration when the client loses uplink
> connection for some time and then re-establishes it.
> ntp.conf:
>
> tos maxdist 4
> server 10.9.2.80 iburst
> server 10.10.2.101 iburst
> server 10.10.52.111 iburst
> ser
Hello,
I have a problem with NTP configuration when the client loses uplink connection
for some time and then re-establishes it.
ntp.conf:
tos maxdist 4
server 10.9.2.80 iburst
server 10.10.2.101 iburst
server 10.10.52.111 iburst
server 127.127.1.0
fudge 127.127.1.0 stratum 12
I do the follo
41 matches
Mail list logo
