[time-nuts] ISS NTP operation problems.

[Magnus Danielson]

Hi Jim,

On 2021-01-08 15:06, Lux, Jim wrote:
> On 1/8/21 12:24 AM, Poul-Henning Kamp wrote:
>> --------
>> Steven Sommars writes:
>>
>>> There is a ~600-700 msec RTT between the ground NTP servers and the
>>> ISS NTP server.
>> How stable is that ?
>>
>> Is there a lot of sample-to-sample jitter ?
>>
>> Have they clamped the poll-rate on the S2 ?
>>
> If the pathway is like the ones to/from ISS that I am familiar with,
> they're using the Ku-band or S-band link through TDRSS. In both cases,
> the signal has to go from White Sands (or Guam) up to TDRSS, which is
> in GEO, and then back down to ISS.  There are also handoffs  between,
> say, TDRSS W  and TDRSS E, where there will be a gap in comms, and
> then it will resume, with a different light time delay.
>
Not a trivial path. Then again, the connection to White Sands or Guam
also comes into the path.
> There will also be some delays in translating the IP packets in and
> out of the data streams, which encapsulate IP datagrams in some other
> packet form (I can't remember if they're using CCSDS AOS or something
> else, but there's a fair amount of encapsulation and segmentation
> going on to put the IP traffic into a virtual channel).  There could
> be delays in the processing at HOSC that change during a pass,
> depending on their buffering strategy.
>
Beyond that, exactly how high priority it has in the scheduling of
buffers as traversing that path, will be very relevant.
> This is a propagation path that I suspect NTP is just not designed to
> deal with.
Well, I wonder if NTP over that path is even the best solution. Taking
time off a GPS/GNSS receiver onboard the ISS would be a significant
improvement. Just having the PPS would help immensly.
>
> And, oh yes, getting diagnostic information or changes is quite the
> tedious process, taking many days, typically.

For good and bad.

Cheers,
Magnus