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

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

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

prü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 produ

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

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

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

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

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

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

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

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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 ?

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

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

[time-nuts] ISS NTP operation problems.

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