[time-nuts] ISS NTP operation problems.

[Warren Kumari]

On Fri, Jan 8, 2021 at 11:40 AM Lux, Jim <jim at luxfamily.com> wrote:
>
> On 1/8/21 6:59 AM, Magnus Danielson wrote:
> > 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.
>
> I don't know where the ground NTP server is, but if it's at HOSC at
> Marshall Spaceflight Center, there's a fairly high performance dedicated
> link to White Sands and Guam with fairly consistent latency.
>
>
> (HOSC - Huntsville Operations Support Center, also the POIC - Payload
> Operations and Integration Center)
>
>
> >> 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.
>
> Indeed - after all, they also support VoIP and teleconferencing via the
> Ku-band link and there's a whole raft of QoS rules and constraints. The
> scheduling of the Ku-band link is pretty complex, because it needs a
> high gain antenna on a gimbal that's on ISS, and there's a whole host of
> constraints when there are visiting vehicles, etc.
>
>
>
> >> 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.
>
> That is probably harder than it seems.  There's a lot of isolation among
> systems on ISS - partly for safety, partly from history, partly from
> institutional inertia. My payload on ISS (SCaN Testbed) had a
> MIL-STD-1553 connection and a unidirectional Ethernet connection (out of
> payload only). There's multiple GNSS receivers on ISS, but not all are
> visible to an arbitrary payload - their output might get packaged up as
> telemetry and store/forward sent to the ground via episodic
> transmissions on the Ku-band system.  One of the experiments on my
> payload was to actually try to measure the time and position offsets
> between our radio(which had S-band Tx/Rx and GPS receiver) and the
> various time sources on the Station.

I must admit that I'm very surprised that GPS receivers worked and
were able to compute a fix.
The majority of GPS receiver chipsets have altitude and speed limits
built in, both because of assumptions/discarding pathological results,
but also because of ITAR and similar regulations. Were these special /
licensed receivers which didn't have the "Erk, I think I'm on an ICBM"
logic?

W

>
> It is exceedingly unlikely that there is a 1pps signal available for
> distribution on board - it's just not something that someone would have
> written a requirement for. The folks designing Station are not time-nuts
> - the idea of a "house frequency/time standard" would not have occurred
> to them, except perhaps in the context of a limited subsystem.
>
> The best bet is probably hooking into the "Broadcast Ancillary Data"
> (BAD) which does get fed to a lot of subsystems and experiments on
> Station in various forms.  It has current (predicted) position and time
> (Flight Dynamics Facility at GSFC calculates where ISS is going to be,
> that gets uplinked, and then broadcast across Station) with some sort of
> time hacks.
>
> Station (writ large, not just the part in space) is kind of an unusual
> place to work - think of it as a village or small town of several
> thousands of people, each with a specialization and some knowledge of
> what their neighbor does, but very few with details about the whole
> thing. And because it's a thriving, but isolated, community, they speak
> a different language. And the overall architecture was determined in the
> 1970s and has been substantially modified over the years since then, but
> still has a lot of ties back to "the way it was done".    I used to
> liken trying to find out stuff to being dropped on the edge of a small
> town in France, and you don't know French, but you do know some Spanish,
> and you have to find the person you're looking for by asking questions
> and being handed off from one person to the next.  Once you're "in the
> system" you can get stuff done pretty easily, but oh wow, if you are
> new, or trying to do something "different" it can be quite the
> adventure.  I'm glad I did it. I'd rather not do it again.
>
>
>
>
>
>
> _______________________________________________
> 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.



-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra