On 5/21/2012 9:58 AM, Luc Roels wrote:
Hi,
I am an NTP newbie but have been asked to debug a problem in our system. Our software
uses the output of the ntpd -c "rv assid" 127.0.0.1 to determine if the NTP
server is reachable and if it is synced or not by inspecting the filtoffset line.
Chris Albertson wrote:
> > In a nutshell, displaying IPv6 addresses and 80 column formatting
> > simply aren't compatible. An IPv6 address is simply going to
> > consume too much space for that. It may be that we aren't supposed
> > to parse the output of the likes of ntpq -p but still...
> A com
BitMover's ntp.bkbits.net service is no longer operational and we are
pleased to announce our replacement service at bk.ntp.org.
The NTP BitKeeper Repositories are now located at bk.ntp.org; please
configure your BitKeeper client to use this new host-name.
A web interface to the BitKeeper metadat
unruh wrote:
However, the orbit of the sattelite is known exactly. Thus the propagation delay
can be calculated to nanosecond accuracy once the position of the
receiver is known, and that can be done by fitting the signals from
three sattelites. In the network situation, the delay is unkown and
> In a nutshell, displaying IPv6 addresses and 80 column formatting
> simply aren't compatible. An IPv6 address is simply going to consume
> too much space for that. It may be that we aren't supposed to parse the
> output of the likes of ntpq -p but still...
A compromise might be to always write
Dave Hart wrote:
> ntpq -n -c lassoc -c "rv &1 srcadr"
> If you omit the -n, the IP address will be reversed to a hostname if possible.
> http://bugs.ntp.org/show_bug.cgi?id=1763
> has a similar discussion.
In a nutshell, displaying IPv6 addresses and 80 column formatting
simply aren't compati
unruh wrote:
> What is the issue? What do you need help for and why? Is it
> aesthetic? V6 addresses are too long for the V4 space alloted to
> addresses in the output, so they are truncated. But why is this a
> problem?
I cannot speak for the OP, but it would seem that any two NTP servers
who's
I did a very cursory check to see if this was already brought-up but
may have missed it. Folks interested in addressing highly variable
delays in networks and such may find the "codel" AQM interesting. It
seeks to keep the time packets spend in queues down as part of
addressing "buffer bloat."
I
On Mon, May 21, 2012 at 7:31 PM, Atul Gupta wrote:
> I am syncing with ntp server whose ip is :- 2001:5b0:3eff:fffa::310
> But, when i run ntpq program to check the ntp status, i get following out out
> :-
>
> # ntpq -p
> remote refid st t when poll reach delay offset jit
thanks for reply.
Yes, this is my problem that address is allocated for ipv4 address, so
i can't see my complete ipv6 address, and i am not able to know that
what is complete ipv6 address of server i am synced with ( like in
this case, i am synced with server 2001:5b0:3eff:fffa::310 while i see
onl
On 2012-05-22, Dave Hart wrote:
> On Tue, May 22, 2012 at 2:07 PM, Ron Frazier (NTP)
> wrote:
>> The essential problem of time sync is to observe one or more remote time
>> servers, with variable and asymmetric propagation delays between you and
>> them, and choose what the best time to set your c
On 2012-05-21, Atul Gupta wrote:
> Hi,
> I am running my ntpd in ipv6 multicast mode, below is my conf file :-
>
> multicastclient ff05::101
> disable auth
> driftfile /var/log/ntp/drift
> logfile /var/log/ntp/ntp.log
>
> I am syncing with ntp server whose ip is :- 2001:5b0:3eff:fffa::310
> , whi
On Tue, May 22, 2012 at 2:07 PM, Ron Frazier (NTP)
wrote:
> The essential problem of time sync is to observe one or more remote time
> servers, with variable and asymmetric propagation delays between you and
> them, and choose what the best time to set your clock is. Obviously, not
> simple.
>
> H
Hi Dave T, and others,
(I'm cross posting my reply to the NTP questions list since I think they'd be
interested too. The original message was from the Thumbgps-devel mailing list.)
I enjoyed that article. I'll admit to not spending 4 hours studying it, and
sometimes my eyes glazed over, but I e
On Mon, May 21, 2012 at 3:58 PM, Luc Roels wrote:
> I am an NTP newbie but have been asked to debug a problem in our system. Our
> software uses the output of the ntpd -c "rv assid" 127.0.0.1 to determine if
> the NTP server is reachable and if it is synced or not by inspecting the
> filtoffset
Hi,
I am an NTP newbie but have been asked to debug a problem in our system. Our
software uses the output of the ntpd -c "rv assid" 127.0.0.1 to determine if
the NTP server is reachable and if it is synced or not by inspecting the
filtoffset line.
On some machines this command takes up
Hi,
I am running my ntpd in ipv6 multicast mode, below is my conf file :-
multicastclient ff05::101
disable auth
driftfile /var/log/ntp/drift
logfile /var/log/ntp/ntp.log
I am syncing with ntp server whose ip is :- 2001:5b0:3eff:fffa::310
, which i can verify through my ntp logs ( below ) :-
rec
17 matches
Mail list logo
