Re: [time-nuts] ISS NTP operation problems.

[Lux, Jim]

On 1/9/21 12:30 AM, Bernd Neubig wrote:

Björn,
you are correct. The link you have provided points to the actual and latest document of 
the Wassenaar Arrangement for so-called "Dual-Use" items.
This international agreement is transformed to National laws, which often 
include some amendments.
For the European Union it is  the COUNCIL REGULATION (EC) No 428/2009, which is 
regularly updated, latest on is the
COMMISSION DELEGATED REGULATION (EU) 2020/1749.

BTAW: For time-nuts  the chapter 3.A.1.b is interesting, which covers microwave 
and millimeter wave items.
Under sub-clause 3.A.1.b.10 limitations for phase noise of these items are 
defined as follows:

Oscillators or oscillator assemblies, specified to operate with a single 
sideband (SSB) phase noise, in
dBc/Hz, less (better) than -(126 + 20log10F – 20log10f) anywhere within the 
range of 10 Hz ≤ F≤ 10 kHz;
(F is the offset from the operating frequency in Hz and f is the operating 
frequency in MHz)

 From the technical viewpoint it does not make much sense to specify the phase 
noise limits with a slope of -20 dB/decade, while in practice (and theory) the 
slope close to carrier is -30 dBc/Hz.

Not too seldom, it is not recognized that this rule is limited to microwave and 
millimeter wave oscillators. As the document does not define where "microwave" 
begins, this rule is sometimes applied to crystal oscillators below 200 MHz- which to my 
opinion is wrong, as microwaves are starting above 1 GHz or so.

Regards
Bernd


Based on my somewhat sketchy and unreliable experience interpreting 
export control rules (see digression below) and the knowledge that this 
is the province of export control lawyers, not engineers.


This might be interpreted as "oscillators that would/could be used in 
microwave or millimeter wave equipment", not that the oscillator itself 
is microwave. However, it could also be interpreted as the basic 
oscillator (e.g. the VCO in a PLL) performance.


in numbers, for a 100 MHz oscillator , this is -106 dBc/Hz at 10 Hz 
offset to  -166 dBc/Hz at 10kHz









-Ursprüngliche Nachricht-
Von: time-nuts [mailto:time-nuts-boun...@lists.febo.com] Im Auftrag von Björn
Gesendet: Samstag, 9. Januar 2021 06:04
An: Discussion of precise time and frequency measurement 

Betreff: Re: [time-nuts] ISS NTP operation problems.

Magnus, Warren,

ITAR are US rules for US products. Thus ITAR don’t apply for non US products. 
Has that changed?

The original COCOM rule was “don’t do altitude above 18000m and speed exceeding 
1000 knots. “

COCOM was then replaced by the Wassenaar agreement. I would have expected it 
the current list - but could not find it.

https://www.wassenaar.org/app/uploads/2020/12/Public-Docs-Vol-II-2020-List-of-DU-Goods-and-Technologies-and-Munitions-List-Dec-20-3.pdf

Did I miss it or has it moved somewhere else?


Yes, you're right, it's the Wassenaar *Arrangement*, and more 
technically, the two lists, munitions and dual use.  (The Wassenaar 
Agreement is something about labor laws)



A lot of people (particularly in US) use ITAR (International Traffic in 
Arms Regulations) as a catchall word for export controlled, although the 
*list* is actually the USML (United States Munitions List), and it's 
purely a US thing.  And of course there's also the EAR (Export 
Administration Regulations) which has the CCL (Commerce Control List).  
They're handled by the State Department and Commerce Department 
respectively.


And, as an export control specialist explained when I was first at JPL 
20 years ago and working on an export license and end-user-certificate 
for a TWTA: You are an engineer - the export control regulations were 
not created nor are they "understandable" as engineering specifications 
or requirements. The determination is made (seemingly arbitrarily) by 
someone at State or Commerce. Use the lists as "guidance" but don't try 
to lawyer your way through them to find exceptions.  This is 
particularly true for the EAR/CCL which is often more about trade wars 
than "engines of war".  It's like the recent tariff stuff - ferrite 
cores by themselves, no tariff. Ferrite cores for use in computer power 
supplies, 25% tariff. (I might have that backwards) Same exact core part 
number, just how it's sold.


Most (but not all) of the Wassenaar munitions list and USML have the 
"specifically designed for" clause, which helps a lot with dual use 
things like GNSS receivers. Diesel engines designed for submarines - 
restricted; other diesel engines - have at it.


The lists have a pervasive effect beyond the obvious. For example, you 
will find that there are certain "breakpoints" in data sheet performance 
on things like high speed ADCS.  You find a lot of 16 bit ADCs that have 
sample rates of 65 MSPS. What's special about that particular sample 
rate? The part probably runs faster. "3.A.1.a.5.5. A resolution of 16 
bit or more wi

Re: [time-nuts] ISS NTP operation problems.

[Bernd Neubig]

Björn,
you are correct. The link you have provided points to the actual and latest 
document of the Wassenaar Arrangement for so-called "Dual-Use" items.
This international agreement is transformed to National laws, which often 
include some amendments.
For the European Union it is  the COUNCIL REGULATION (EC) No 428/2009, which is 
regularly updated, latest on is the 
COMMISSION DELEGATED REGULATION (EU) 2020/1749.

BTAW: For time-nuts  the chapter 3.A.1.b is interesting, which covers microwave 
and millimeter wave items. 
Under sub-clause 3.A.1.b.10 limitations for phase noise of these items are 
defined as follows:

Oscillators or oscillator assemblies, specified to operate with a single 
sideband (SSB) phase noise, in
dBc/Hz, less (better) than -(126 + 20log10F – 20log10f) anywhere within the 
range of 10 Hz ≤ F≤ 10 kHz;
(F is the offset from the operating frequency in Hz and f is the operating 
frequency in MHz)

From the technical viewpoint it does not make much sense to specify the phase 
noise limits with a slope of -20 dB/decade, while in practice (and theory) the 
slope close to carrier is -30 dBc/Hz. 

Not too seldom, it is not recognized that this rule is limited to microwave and 
millimeter wave oscillators. As the document does not define where "microwave" 
begins, this rule is sometimes applied to crystal oscillators below 200 MHz- 
which to my opinion is wrong, as microwaves are starting above 1 GHz or so. 

Regards
Bernd



-Ursprüngliche Nachricht-
Von: time-nuts [mailto:time-nuts-boun...@lists.febo.com] Im Auftrag von Björn
Gesendet: Samstag, 9. Januar 2021 06:04
An: Discussion of precise time and frequency measurement 

Betreff: Re: [time-nuts] ISS NTP operation problems.

Magnus, Warren,

ITAR are US rules for US products. Thus ITAR don’t apply for non US products. 
Has that changed?  

The original COCOM rule was “don’t do altitude above 18000m and speed exceeding 
1000 knots. “

COCOM was then replaced by the Wassenaar agreement. I would have expected it 
the current list - but could not find it.

https://www.wassenaar.org/app/uploads/2020/12/Public-Docs-Vol-II-2020-List-of-DU-Goods-and-Technologies-and-Munitions-List-Dec-20-3.pdf

Did I miss it or has it moved somewhere else?


Kind regards,

 Björn 

Sent from my iPhone

> On 9 Jan 2021, at 00:13, Magnus Danielson  wrote:
> 
> Warren,
> 
>> On 2021-01-08 23:15, Warren Kumari wrote:
>>> On Fri, Jan 8, 2021 at 11:40 AM Lux, Jim  wrote:
>>>> On 1/8/21 6:59 AM, Magnus Danielson wrote:
>>> 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?
> 
> These receivers do not follow the ITAR rules for sure. Just being 
> beyond
> 18 km is breaking one ITAR rule, being faster than 1 MACH is another 
> (don't recall the exact number for ITAR, but there aboutish).
> 
> But it works.
> 
> A fun special satellite measures the GPS satellite occulation 
> behavior, thus how the signal bends from below the horizon to just 
> above. That is an atmospheric measurement tool. For sure not ITAR compliant.
> 
> Cheers,
> Magnus
> 
> 
> ___
> time-nuts mailing list -- time-nuts@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@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@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] ISS NTP operation problems.

[Björn]

Magnus, Warren,

ITAR are US rules for US products. Thus ITAR don’t apply for non US products. 
Has that changed?  

The original COCOM rule was “don’t do altitude above 18000m and speed exceeding 
1000 knots. “

COCOM was then replaced by the Wassenaar agreement. I would have expected it 
the current list - but could not find it.

https://www.wassenaar.org/app/uploads/2020/12/Public-Docs-Vol-II-2020-List-of-DU-Goods-and-Technologies-and-Munitions-List-Dec-20-3.pdf

Did I miss it or has it moved somewhere else?


Kind regards,

 Björn 

Sent from my iPhone

> On 9 Jan 2021, at 00:13, Magnus Danielson  wrote:
> 
> Warren,
> 
>> On 2021-01-08 23:15, Warren Kumari wrote:
>>> On Fri, Jan 8, 2021 at 11:40 AM Lux, Jim  wrote:
 On 1/8/21 6:59 AM, Magnus Danielson wrote:
>>> 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?
> 
> These receivers do not follow the ITAR rules for sure. Just being beyond
> 18 km is breaking one ITAR rule, being faster than 1 MACH is another
> (don't recall the exact number for ITAR, but there aboutish).
> 
> But it works.
> 
> A fun special satellite measures the GPS satellite occulation behavior,
> thus how the signal bends from below the horizon to just above. That is
> an atmospheric measurement tool. For sure not ITAR compliant.
> 
> Cheers,
> Magnus
> 
> 
> ___
> time-nuts mailing list -- time-nuts@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@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] ISS NTP operation problems.

[Steven Sommars]

Responses to several comments.

Opportunities to collect critical NTP debugging data on the ISS will be
limited.
Specific suggestions sent to me off-list would be appreciated.

Earth station to ISS delays: I inferred the 600-700 msec RTT using the
reported root distance
[I've seen much higher delays on some terrestrial NTP paths.  ]
To really understand RTT / RTT stability NTP server diagnostic data is
needed.

GPS/GNSS, PPS distribution: seems like a good idea, but this is outside
the area I'm helping with

NTP (4.2.8) algorithmic changes are probably out of scope for the near
future.
If a real-world PLL problem can be documented, the ntp daemon maintainers
might be motivated to investigate.

So far I haven't been able to reproduce on my home Rpi some key features of
the offset graph I showed.

   - pll error begins at -500 ppm
   - pll error grows to -1000 or even -1500 ppm
   - After step pll error is again -500 ppm
   - Does not self correct within 24 hours

By placing large positive or negative values into the NTP drift file I can
produce offset charts with a series of steps, but eventually the steps stop
and the offset is small.

Thanks for all the replies.
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] ISS NTP operation problems.

[Lux, Jim]

On 1/8/21 2:15 PM, Warren Kumari wrote:

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?




Yes  - these are all flight qualified GNSS receivers specifically 
designed for space use.  JPL has been building receivers for this kind 
of application for decades.



As a practical matter, one can buy standard GPS receivers (like the ever 
popular Novatel OEM 6 and 7 series) that are enabled for space.  Whether 
they survive single event effects or total dose accumulation is another 
issue, but a lot of people fly them and they work pretty well.  I didn't 
have any problems with them on a cube-sat I flew.




___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] ISS NTP operation problems.

[Magnus Danielson]

Warren,

On 2021-01-08 23:15, Warren Kumari wrote:
> On Fri, Jan 8, 2021 at 11:40 AM Lux, Jim  wrote:
>> On 1/8/21 6:59 AM, Magnus Danielson wrote:
>> 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?

These receivers do not follow the ITAR rules for sure. Just being beyond
18 km is breaking one ITAR rule, being faster than 1 MACH is another
(don't recall the exact number for ITAR, but there aboutish).

But it works.

A fun special satellite measures the GPS satellite occulation behavior,
thus how the signal bends from below the horizon to just above. That is
an atmospheric measurement tool. For sure not ITAR compliant.

Cheers,
Magnus


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] ISS NTP operation problems.

[Magnus Danielson]

Jim,

On 2021-01-08 17:31, Lux, Jim wrote:
> On 1/8/21 7:17 AM, Hal Murray wrote:
>> j...@luxfamily.com said:
>>> 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.
>> Is the back down direct or back through TDRSS?
> Through TDRSS both ways.
>>
>> NTP likes symmetric delays.  To first order, it doesn't matter how
>> long it is
>> as long as it is symmetric.  This may not be a first order problem. 
>> There is
>> a cutoff at 1 second total round trip time.
>>
> But the time delay isn't symmetric. The link isn't symmetric (data
> rate wise) and the traffic is different. Think of it as like a cable
> modem - skinny up, fat down, for the most part. Lots of scheduled (in
> a "days ahead" sense) traffic interspersed with "real time" traffic. 
> In usual space comm architecture, the uplink and downlink are totally
> separate systems, operated by different groups of people.
Make sense. The serialization delay scales the prioritation/scheduling
delay differently. Make sense. It's just like a modern microwave link.
Well, it is a modern microwave link, just a bit of different design
parameters.
>
> The actual TDRSS links, by the way, are bent pipe translators - A
> signal is modulated with the data on the ground, sent up through
> TDRSS, and it's demodulated on ISS (or vice versa). So the "light time
> delay" for that part of the system is entirely determined by orbital
> mechanics for a link that's somewhere around 85,000 km +/- several
> thousand km.

Bent pipe is good, not too much delay and delay variations.

So, you have about 1 earth radius in difference then, from when the ISS
turn up on the horizon, to where it is on the same longitude as the
TDRSS and then as it disappears over the horizon. Depending on exactly
where it is for the NTP packet to be sent to the ISS and then the reply
actually gets sent back, this delay will be different, except only when
ISS transition just over the same longitude and you have a bit of luck
in timing.

Makes sense.

Thanks for the many details.

Cheers,
Magnus


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [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  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  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 
> wrote:
>
> > At the end of November a question
> > 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@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@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@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] ISS NTP operation problems.

[Magnus Danielson]

Poul-Henning,

On 2021-01-08 17:10, Poul-Henning Kamp wrote:
> 
> Hal Murray writes:
>
>> There is a huff-puff filter, I think it's optional. 
> I think it is more likely that the median-filter is causing trouble.
>
> If you let the poll-rate ramp all the way up to 1024 seconds, the
> median filter can get "stuck" for almost an hour before it notices
> that something is horribly wrong[1].
>
> These days there are almost no circumstances under which you should not
> clamp your poll-rate to one minute "server bla maxpoll 6"
>
> On a strange path like the ISS, I would clamp it to the minimum
> 16 seconds ('maxpoll 4').
>
> When the backbone of the ARPAnet was 56kbit/s, being able to ramp
> up to 1024 seconds poll rate made sense.  It never makes sense now.
>
> Poul-Henning
>
>
> [1] The median filter should be automatically disabled and the most
> recent sample used, if the samples in the shift register are
> mononotonic or spread too much.  That's another change I never
> managed to "sell" to Dave Mills.

The Allan intercept concept comes out of the analysis of the ACTS system
where model signals was used over the public phone network and the noise
analysis in that context. For it's system view, it's a good analysis and
it allowed to reduce the number of calls, associated with significant
cost, into the ACTS system. Then, this was re-applied over to NTP under
the assumption that the noise models work. *NEWSFLASH* They don't. The
non-zero mean character of network delay variations just play havoc with
the underlying assumption. As one applies knowledge on how to handle
that noise, use min-delay algorithm, play with packet rates etc. you end
up with quite a different solution. Increasing packet-rate for NTP today
is for most scenarios very cheap, so the very fine property of low load
of NTP ends up being not so greatly needed at all times. If we do the
right processing, we can increase the packet rate for the benefit of
better performance.

Now, if one worked enough with these things, the things I say is really
not dramatic and new, but there is still a bit of history involved where
times have changes significantly.

Cheers,
Magnus


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] ISS NTP operation problems.

[Warren Kumari]

On Fri, Jan 8, 2021 at 11:40 AM Lux, Jim  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 

Re: [time-nuts] ISS NTP operation problems.

[Magnus Danielson]

On 2021-01-08 16:58, Hal Murray wrote:
> p...@phk.freebsd.dk said:
>> If you path is not stable, or you flip between different servers with
>> different delays and/or assymetries, your time will not be stable. 
> Ahh.  Thanks for the reminder.
>
> There is a huff-puff filter, I think it's optional.  It assumes the physical 
> path is stable and that increases in the round trip time are due to queuing 
> delays which are typically asymmetric so it drops answers if the delay is 
> longer than previous samples.  I'd have to look at the code for the details.

Huff-'n-puff is there only to handle packet jitter. The same method is
called min delay algorithm or lucky packet filtering in other
techniques. For the one-way delay estimate, over some window of raw
measurements, you produce the minimum delay one. Then you do the same
for the other direction. Only using these values you then do your
two-way time-transfer calculation.

You should also be cautioned that it works only because the time between
the nodes is stable, and thus the frequency difference between them
being virtually zero, because the assumption made breaks down whenever
there is a phase-drift / frequency error.

The success of this method depends on how large window of measurements
you have. You can get significant gains as you make the window cover
more samples. In the end, the success depends on packet rate, as you end
up having some maximum time between regulations.

This does not really solve problems with asymmetric routes,
route-changes etc.

> But that doesn't match the crazy graph with the drift way off.

I don't recall seeing the graph, did I forget to check it in the
original posting? Yes, lazy me forgot to check that. OK. Will look at it.

Cheers,
Magnus



___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] ISS NTP operation problems.

[Magnus Danielson]

Hal,

On 2021-01-08 16:17, Hal Murray wrote:
> j...@luxfamily.com said:
>> 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.
> Is the back down direct or back through TDRSS?
>
> NTP likes symmetric delays.  To first order, it doesn't matter how long it is 
> as long as it is symmetric.  This may not be a first order problem.  There is 
> a cutoff at 1 second total round trip time.

I only partly agree. NTP likes symmetric delays, but also static delays.
It can to some limited degree handle a bit of jitter, but the basic
two-way time-transfer calculation of NTP, and for that matter other
time-transfer systems, actually assumes that the basic delay is fairly
static. Further, it assumes that the clocks compared is fairly static.

Frequency drift errors will easily convert over to detected time error,
just as asymmetry.

A shift in delay will cause the t1, t2 measure and then t3, t4 measure
to measure over different delays as they are measured at different
times, and thus different delays. As you calculate the TE value you will
have a leakage there because of the time mismatch.

So, there is secondary effects showing up for various reasons. Those are
not a problem normally, but if you take NTP (or other) technology out of
their environment, things like that may cause interesting problems. It
may or may not be a problem, but one should be cautious enough to check
on them. Some can be ignored, some can be compensated.

Oh, and it is not NTP specific, PTP would have the same problem. The big
difference is that PTP provide a delay compensation scheme for
intermediary equipment, and if you know what you do, you can play some
fun tricks.

I have not had to adapt NTP, PTP or the time-transfer system I design on
day-time to these conditions, but I would know where to look if I had
to. The analysis is not that hard.

Cheers,
Magnus


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] ISS NTP operation problems.

[Jim Palfreyman]

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 
wrote:

> At the end of November a question
> 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@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@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] ISS NTP operation problems.

[Lux, Jim]

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.


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 -- 

Re: [time-nuts] ISS NTP operation problems.

[Lux, Jim]

On 1/8/21 7:17 AM, Hal Murray wrote:

j...@luxfamily.com said:

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.

Is the back down direct or back through TDRSS?

Through TDRSS both ways.


NTP likes symmetric delays.  To first order, it doesn't matter how long it is
as long as it is symmetric.  This may not be a first order problem.  There is
a cutoff at 1 second total round trip time.

But the time delay isn't symmetric. The link isn't symmetric (data rate 
wise) and the traffic is different. Think of it as like a cable modem - 
skinny up, fat down, for the most part. Lots of scheduled (in a "days 
ahead" sense) traffic interspersed with "real time" traffic.  In usual 
space comm architecture, the uplink and downlink are totally separate 
systems, operated by different groups of people.


The actual TDRSS links, by the way, are bent pipe translators - A signal 
is modulated with the data on the ground, sent up through TDRSS, and 
it's demodulated on ISS (or vice versa). So the "light time delay" for 
that part of the system is entirely determined by orbital mechanics for 
a link that's somewhere around 85,000 km +/- several thousand km.




___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] ISS NTP operation problems.

[Peter Vince]

Using NTP, with long and asymmetric path delays, seems like a recipe for
disaster.  Can they not simply use a GPS receiver?
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] ISS NTP operation problems.

[Poul-Henning Kamp]

Hal Murray writes:

> There is a huff-puff filter, I think it's optional. 

I think it is more likely that the median-filter is causing trouble.

If you let the poll-rate ramp all the way up to 1024 seconds, the
median filter can get "stuck" for almost an hour before it notices
that something is horribly wrong[1].

These days there are almost no circumstances under which you should not
clamp your poll-rate to one minute "server bla maxpoll 6"

On a strange path like the ISS, I would clamp it to the minimum
16 seconds ('maxpoll 4').

When the backbone of the ARPAnet was 56kbit/s, being able to ramp
up to 1024 seconds poll rate made sense.  It never makes sense now.

Poul-Henning


[1] The median filter should be automatically disabled and the most
recent sample used, if the samples in the shift register are
mononotonic or spread too much.  That's another change I never
managed to "sell" to Dave Mills.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] ISS NTP operation problems.

[Hal Murray]

p...@phk.freebsd.dk said:
> If you path is not stable, or you flip between different servers with
> different delays and/or assymetries, your time will not be stable. 

Ahh.  Thanks for the reminder.

There is a huff-puff filter, I think it's optional.  It assumes the physical 
path is stable and that increases in the round trip time are due to queuing 
delays which are typically asymmetric so it drops answers if the delay is 
longer than previous samples.  I'd have to look at the code for the details.

But that doesn't match the crazy graph with the drift way off.
 

-- 
These are my opinions.  I hate spam.




___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] ISS NTP operation problems.

[Poul-Henning Kamp]

Hal Murray writes:

> NTP likes symmetric delays.

That's strictly speaking to true:  NTP *assumes* symmetric delays.

If your path is not symmetric, you can a time offset of half the asymmetry.

If your path is stable you can calibrate that out with a temporary reference
or something.

If you path is not stable, or you flip between different servers with different
delays and/or assymetries, your time will not be stable.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] ISS NTP operation problems.

[Hal Murray]

j...@luxfamily.com said:
> 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.

Is the back down direct or back through TDRSS?

NTP likes symmetric delays.  To first order, it doesn't matter how long it is 
as long as it is symmetric.  This may not be a first order problem.  There is 
a cutoff at 1 second total round trip time.


-- 
These are my opinions.  I hate spam.




___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [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



___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] ISS NTP operation problems.

[Magnus Danielson]

Hi,

On 2021-01-08 09:24, 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 ?
>
Another aspect, how much have delay shifted with how ISS moves around,
and how well the packets match each other and (about) same delay of
transmission. There is a certain assumption about stability of link, but
a systematic modulation of link delay could potentially eat into causing
mismatches that for sure would upset things.

Cheers,
Magnus


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] ISS NTP operation problems.

[Poul-Henning Kamp]

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 ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

___
time-nuts mailing list -- time-nuts@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] ISS NTP operation problems.

[Steven Sommars]

At the end of November a question
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@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.