From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A69FD3B29D for ; Mon, 1 Apr 2024 20:30:05 -0400 (EDT) Received: by mail-pl1-x629.google.com with SMTP id d9443c01a7336-1e0ae065d24so37922035ad.1 for ; Mon, 01 Apr 2024 17:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712017804; x=1712622604; darn=lists.bufferbloat.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tbJu3zaTBAvFb4QvAmo3fOz9O9XibhBHgccgOQ5CQdI=; b=dHkN1ctVjDLwt0LT0op9GuJd6T4x3XfLTrbbOOLDnaEu+LXMpGpQixRdhjHY6DBTGN iiDKeRlRtsjvmPIp5LHO4nEoYgUW/HpKKfwmkycFmncLQPMcIX1zXyQYtZSik/foCBVw GnpnCaGTEd3kjXHWYRlv7jhwVi+CsIMXzDKvma5yaVTDmwwmkcxzcHCYeQLxI1k2b6dG BZlqgiLBScxp73WomnWBYa64zkmHVNNJVXEXMmv+I5wi8y3YWiyhCKkYjfqF7TWTd7xA eiX35PatsfAC1pRghmLudm9ojPCVL+ijych9EhhyVILkkT7vAkflQX700J79uPU1FF+0 oK3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712017804; x=1712622604; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tbJu3zaTBAvFb4QvAmo3fOz9O9XibhBHgccgOQ5CQdI=; b=TJh3dQdmIlF/S9xbjRpsR/XQd/DbWObGszgLfzAauo7hh8/CkO1Ms4lONRaNagXIZh vI8OqUQjwW3i9pD4AIKOD0KXxGUN7KsocPYUJ3kLD3/vMLFT1dg3HS+yENqkA2yL7v0v z/5Z0ycuw+qIx1e9owW/UaH4+HvhlY29cLXeRpSfKZYXEPvovv6sMHJm1q2q1FgCb8NN iydYHQ61ac1BqGE0lms2r1vd+QdFCBfdpZENnm2k8TFIkDkcZJYyBIxs+VRD7eVepJ+q CNn6qDcdH3HUPNg+eXlxmjN+EM3hCdFi1CP58z2XcrVcqkTwclN3oQeLRaqH4Vs4SNJy gADA== X-Forwarded-Encrypted: i=1; AJvYcCWc1dIINhbsKanOph4GdoU/y6sHDrg6FczKRz14jBCXUkSf3/4M/Nq92ZocQ11Hfwaa6gWYYzhOF0R3sqDJcTnpmUBkN5HY/yMRRGSBLkM= X-Gm-Message-State: AOJu0YyEZkmm/cvoJWWUd8BIX5HgfjbOapI1ZRtAlzccHthutsqjefbn 3vBrPS2DF8nvqBaO3atUUNBhmIxZf2eZr2zt4mtjvKduk98Wr1fUidyD9dLddwHMuqGhnkA07A1 91A780qSPs0KNRryU82VvcWdFqWM= X-Google-Smtp-Source: AGHT+IEtJt1BAzVuS8sE9AeCBMm65LXnY9q7RgxRAp96N+lTHwbqc5SjUXVBkIhJ96dvQVCx6wghMlh6z0e+/l8DcgY= X-Received: by 2002:a17:902:b18a:b0:1e0:2a5f:d1d6 with SMTP id s10-20020a170902b18a00b001e02a5fd1d6mr9941485plr.63.1712017804002; Mon, 01 Apr 2024 17:30:04 -0700 (PDT) MIME-Version: 1.0 References: <1C8781A0-8AFF-4118-B410-D1DB66000F18@vdr.net> <79F8B638-D4B0-4052-AE1C-FC8F4BD75D4D@gmx.de> In-Reply-To: <79F8B638-D4B0-4052-AE1C-FC8F4BD75D4D@gmx.de> From: Hesham ElBakoury Date: Mon, 1 Apr 2024 17:29:53 -0700 Message-ID: To: Sebastian Moeller Cc: Christian von der Ropp , Hesham ElBakoury via Starlink Content-Type: multipart/alternative; boundary="0000000000000e8ecf0615123554" Subject: Re: [Starlink] Time Synchronization in Satellite Networks X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2024 00:30:05 -0000 --0000000000000e8ecf0615123554 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Time from GPS is a one way transmission from the satellites down. The relative motion must be accounted for. It is called the Sagnac effect. On Mon, Apr 1, 2024, 3:22 PM Sebastian Moeller wrote: > Hi Hesham, > > > > On 2. Apr 2024, at 00:04, Hesham ElBakoury wrote= : > > > > Hi Christian, > > The problems is that Satellites move, therefore, the delay between the > different directions is different which violates the condition to run NTP > and PTP. > > But GPS Satellites themselves are not in geostationary oprbit, and still > we can get precision time from them... so I would argue that must be a > solved problem, no? > > Regards > Sebastian > > > > > Hesham > > > > On Sat, Mar 2, 2024, 8:19 AM Christian von der Ropp > wrote: > > Hi Hesham, > > > > You do not acquire the time from a LEO satellite but directly from the > GPS satellites which carry an atomic clock on board. > > I'd not be aware of any LEO providing a GNSS signal but Xona plan such > system (although not carrying proper atomic clocks but probably chip-size= d > atomic clocks that require frequent syncing with proper atomic clocks): > > https://twitter.com/Megaconstellati/status/1708091536439673323 > > > > There are efforts to build trapped-ion quantum clocks that are expected > to become significantly smaller and cheaper than traditional atomic clock= s > while as accurate which would make it viable to put an atomic > clock-equivalent on small LEO satellites. Once that happens you would hav= e > an independent alternative to the big GNSS birds in MEO but with stronger > signals. I'm told that we are 5-10 years away from such trapped-ion quant= um > clocks. > > > > But for NTP clients, the described method (running a local NTP server i= n > the satellite terminal synced to GPS) should be good enough. > > > > Christian > > > > > > Am 2. M=C3=A4rz 2024 18:02:47 OEZ schrieb Hesham ElBakoury < > helbakoury@gmail.com>: > > Hi Christian, > > How you synchronize the time of the satellites in the network? Are you > saying each satellite has a master clock? > > > > Hesham > > > > On Sat, Mar 2, 2024, 7:38 AM Christian von der Ropp > wrote: > > Why not acquire the time directly from by the satellite terminal and ru= n > local NTP servers instead of syncing via the Internet? LEO satellite > terminals always have onboard GNSS antennas for geolocation which is > necessary to find the satellites, so integrating a local GNSS-disciplined > Stratum-1 NTP server seems trivial to me. > > > > > > Am 2. M=C3=A4rz 2024 17:25:59 OEZ schrieb Hesham ElBakoury via Starlink= < > starlink@lists.bufferbloat.net>: > > Hi Sebastian, > > Can we still use PTP and NTP for time synchronization in Satellite > networks or we need new protocols? If we need new protocols, do such > protocols exist? > > > > Thanks > > Hesham > > > > On Sat, Mar 2, 2024, 7:18 AM Sebastian Moeller wrote: > > Hi Hesham > > > > > On 2. Mar 2024, at 16:03, Hesham ElBakoury via Starlink < > starlink@lists.bufferbloat.net> wrote: > > > > > > Time synchronization, for satellite networks, faces several challenge= s: > > > 1. Signal Propagation Delays: Unlike terrestrial networks where > signals travel through cables at the speed of light, > > > > [SM] The speed of light in your typical glas fibers (and accidentally > the information propagation speed in metallic conductors) comes in roughl= y > at 2/3 of the speed of light in vacuum, while the speed of light in air a= t > see level is a mere 90 KM/s slower than in vacuum. > > > > > satellite communication involves signals traveling vast distances > through space. This creates significant delays. > > > > [SM] Sure distances might be larger, but propagation speed is around > 100000Km/s faster... my main point is speed of light is a) dependent on t= he > medium b) not the things that differentiates space from the earth's surfa= ce > here, but mere geometry and larger distances on larger spheres... > > > > > 2. Clock Drift: Even highly precise atomic clocks, used in satellites= , > are susceptible to "drift" - gradually losing or gaining time. This drift= , > caused by factors like temperature variations, radiation exposure, and > power fluctuations, can lead to inconsistencies in timekeeping across the > network. > > > 3. Signal Degradation: As signals travel through space, they can > degrade due to factors like atmospheric interference, ionospheric > disturbances, and solar activity. This degradation can introduce noise an= d > errors, impacting the accuracy of time synchronization messages. > > > 4. Limited Resources: Satellites have limited power and processing > capabilities. Implementing complex synchronization protocols can be > resource-intensive, requiring careful optimization to minimize their impa= ct > on other functionalities. > > > 5. Evolving Technologies: As satellite technologies and applications > continue to evolve, new challenges related to synchronization might emerg= e. > For example, the integration of constellations with thousands of satellit= es > poses unique synchronization challenges due to the sheer scale and > complexity of the network. > > > These challenges necessitate the development of robust and efficient > time synchronization protocols for satellite networks and an integrated > satellite and terrestrial networks > > > Are you aware of such time synchronization protocols? > > > I would think that using Satellite simulators is the most viable way > to develop and test these protocols given that using satellites is not th= at > easy. > > > Thanks > > > Hesham > > > > > > > > > > > > _______________________________________________ > > > Starlink mailing list > > > Starlink@lists.bufferbloat.net > > > https://lists.bufferbloat.net/listinfo/starlink > > > > -- > > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > gesendet. > > -- > > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > gesendet. > > --0000000000000e8ecf0615123554 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Time from GPS is a one way transmission from the satellit= es down. The relative motion must be accounted for. It is called the Sagnac= effect.

On Mon, Apr 1, 2024, 3:22 PM Sebastian Moeller <moeller0@gmx.de> wrote:
Hi Hesham,


> On 2. Apr 2024, at 00:04, Hesham ElBakoury <helbakoury@gmail.com<= /a>> wrote:
>
> Hi Christian,
> The problems is that Satellites move, therefore,=C2=A0 the delay betwe= en the different directions is different which violates the condition to ru= n NTP and PTP.

But GPS Satellites themselves are not in geostationary oprbit, and still we= can get precision time from them... so I would argue that must be a solved= problem, no?

Regards
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sebastian

>
> Hesham
>
> On Sat, Mar 2, 2024, 8:19 AM Christian von der Ropp <cvdr@vdr.net>= wrote:
> Hi Hesham,
>
> You do not acquire the time from a LEO satellite but directly from the= GPS satellites which carry an atomic clock on board.
> I'd not be aware of any LEO providing a GNSS signal but Xona plan = such system (although not carrying proper atomic clocks but probably chip-s= ized atomic clocks that require frequent syncing with proper atomic clocks)= :
> https://twitter.com/Me= gaconstellati/status/1708091536439673323
>
> There are efforts to build trapped-ion quantum clocks that are expecte= d to become significantly smaller and cheaper than traditional atomic clock= s while as accurate which would make it viable to put an atomic clock-equiv= alent on small LEO satellites. Once that happens you would have an independ= ent alternative to the big GNSS birds in MEO but with stronger signals. I&#= 39;m told that we are 5-10 years away from such trapped-ion quantum clocks.=
>
> But for NTP clients, the described method (running a local NTP server = in the satellite terminal synced to GPS) should be good enough.
>
> Christian
>
>
> Am 2. M=C3=A4rz 2024 18:02:47 OEZ schrieb Hesham ElBakoury <helba= koury@gmail.com>:
> Hi Christian,
> How you synchronize the time of the satellites in the network? Are you= saying each satellite has a master clock?
>
> Hesham
>
> On Sat, Mar 2, 2024, 7:38 AM Christian von der Ropp <cvdr@vdr.net>= wrote:
> Why not acquire the time directly from by the satellite terminal and r= un local NTP servers instead of syncing via the Internet? LEO satellite ter= minals always have onboard GNSS antennas for geolocation which is necessary= to find the satellites, so integrating a local GNSS-disciplined Stratum-1 = NTP server seems trivial to me.
>
>
> Am 2. M=C3=A4rz 2024 17:25:59 OEZ schrieb Hesham ElBakoury via Starlin= k <starlink@lists.bufferbloat.net>:
> Hi Sebastian,
> Can we still use PTP and NTP for time synchronization in=C2=A0 Satelli= te networks or we need new protocols? If we need new protocols, do such pro= tocols exist?
>
> Thanks
> Hesham
>
> On Sat, Mar 2, 2024, 7:18 AM Sebastian Moeller <moeller0@gmx.de>= ; wrote:
> Hi Hesham
>
> > On 2. Mar 2024, at 16:03, Hesham ElBakoury via Starlink <starlink@lists.bufferbloat.net> wrote:
> >
> > Time synchronization, for satellite networks, faces several chall= enges:
> > 1. Signal Propagation Delays: Unlike terrestrial networks where s= ignals travel through cables at the speed of light,
>
> [SM] The speed of light in your typical glas fibers (and accidentally = the information propagation speed in metallic conductors) comes in roughly = at 2/3 of the speed of light in vacuum, while the speed of light in air at = see level is a mere 90 KM/s slower than in vacuum.
>
> > satellite communication involves signals traveling vast distances= through space. This creates significant delays.
>
> [SM] Sure distances might be larger, but propagation speed is around 1= 00000Km/s faster... my main point is speed of light is a) dependent on the = medium b) not the things that differentiates space from the earth's sur= face here, but mere geometry and larger distances on larger spheres...
>
> > 2. Clock Drift: Even highly precise atomic clocks, used in satell= ites, are susceptible to "drift" - gradually losing or gaining ti= me. This drift, caused by factors like temperature variations, radiation ex= posure, and power fluctuations, can lead to inconsistencies in timekeeping = across the network.
> > 3. Signal Degradation: As signals travel through space, they can = degrade due to factors like atmospheric interference, ionospheric disturban= ces, and solar activity. This degradation can introduce noise and errors, i= mpacting the accuracy of time synchronization messages.
> > 4. Limited Resources: Satellites have limited power and processin= g capabilities. Implementing complex synchronization protocols can be resou= rce-intensive, requiring careful optimization to minimize their impact on o= ther functionalities.
> > 5. Evolving Technologies: As satellite technologies and applicati= ons continue to evolve, new challenges related to synchronization might eme= rge. For example, the integration of constellations with thousands of satel= lites poses unique synchronization challenges due to the sheer scale and co= mplexity of the network.
> > These challenges necessitate the development of robust and effici= ent time synchronization protocols for satellite networks and an integrated= satellite and=C2=A0 terrestrial networks
> > Are you aware of such time synchronization protocols?
> > I would think that using Satellite simulators is the most viable = way to develop and test these protocols given that using satellites is not = that easy.
> > Thanks
> > Hesham
> >
> >
> >
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/= listinfo/starlink
>
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail ges= endet.
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail ges= endet.

--0000000000000e8ecf0615123554--