[time-nuts] ISS NTP operation problems.

[William Dell]

>
> Is this a new problem or has it being happening since day 1?
>

It's unclear how long it has been happening. The team responsible for
managing the NTP Server noticed irregularities with its ability to sync to
ground but we don't know how long it had been going on for. In an effort to
fix it the following changes were made to the ISS NTP Server:

tinker panic 0
tos maxdist 60
tinker step 0.256
tinker stepout 150
server <groundserver> iburst trust minpoll 4 maxpoll 5
peer <2ndISSNTPServer>

After these changes were made my team began noticing sync issues with our
NTP clients. We chased part of this down to high root dispersion from the
NTP server due to the tos maxdist 60 setting. Implementing that setting on
our NTP clients allowed them to sync with the ISS NTP server ~90% of the
time, attempting to chase down the final 10% is what brought me to Steve
(and now here).

With only 2 full days worth of packet captures in October and no data
before the server changes were made (or even what symptoms inspired the
changes -- only that they were noticing "sync issues" with ground), we're
left with the current graphs Steve has made from the captures. The hope is
to get more data on the ISS NTP server after another meeting with this team
in late January. Unfortunately in the meantime this is all we have (which I
know doesn't fully answer your question), sorry about that.


William Dell



On Fri, Jan 8, 2021 at 2:20 PM Jim Palfreyman <jim77742 at gmail.com> wrote:

> Is this a new problem or has it being happening since day 1?
>
> Jim Palfreyman
>
>
> On Fri, 8 Jan 2021 at 5:42 pm, Steven Sommars <stevesommarsntp at gmail.com>
> wrote:
>
> > At the end of November a question
> > <https://lists.ntp.org/pipermail/questions/2020-November/041883.html>was
> > posed to the ntp.org list concerning NTP problems on the International
> > Space Station.
> > With William's permission I'm following up on the time-nuts list.
> >
> > I analyzed NTP/IP packet captures provided by William and reported on
> > external visible behaviors.  The much simplified diagram is
> >         2 x Ground NTP(strat 1)  ---------------   ISS NTP server(strat
> 2)
> > -----(gigastor)------- ISS NTP clients(strat 3)
> > There is a ~600-700 msec RTT between the ground NTP servers and the ISS
> NTP
> > server.
> >
> > As William describes, the clients are having trouble synchronizing with
> the
> > stratum 2 ISS NTP server.
> > This server is not working well.   Here is the UTC time offset seen from
> an
> > external packet capture device (Gigastor)
> > [The Gigastor is only approximately sync'd to UTC, hence the 4 second
> > offset]
> > [image: image.png]
> > The y-axis scale is seconds.
> > Note also that after each step the initial error is about -500 ppm.  When
> > the server is in alarm the error stays at -500ppm.
> > When not in alarm the server's clock frequency is changing in the wrong
> > direction with a resulting error of up to ~ -1500ppm.
> > Could this be an example of the Integral Windup problem mentioned
> recently
> > by PHK and Magnus?
> > Have others seen this behavior in NTP?
> >
> > Getting additional diagnostic information from the ISS is quite
> difficult.
> >  Even simple changes (e.g., remove ntp.drift) require much planning.
> >
> > Steve Sommars
> > _______________________________________________
> > time-nuts mailing list -- time-nuts at lists.febo.com
> > To unsubscribe, go to
> > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> > and follow the instructions there.
> >
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>