From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 377B33B29D for ; Mon, 1 Apr 2024 18:04:30 -0400 (EDT) Received: by mail-pj1-x1036.google.com with SMTP id 98e67ed59e1d1-29ddfada0d0so3308626a91.3 for ; Mon, 01 Apr 2024 15:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712009069; x=1712613869; 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=KvPJcOByCwwyGboE+TfTPiTuSvRCGxfRp7oJKs1QS3o=; b=R18elV2NxGSUCjEA+EjCXqQbjQD1glBb/Ent9T9JmjGAhSw6Dzvd1mdLJ/DLP89r29 JFTaRSInoVbSRbjFeEzaVwIUNLtcLZZ2bOO0cMbhv/PLsGmtAeEDdPToi1/JGeObyMA/ cWVcZA55GVdpyFnN9WabC4eZRTzd8XnKKyFfeFref4hJfNaF1Hm4vrnqCcTxkq0gUF9q U/GngxC0M8XE2bTfZ79BMArBHDWrRRT2SX6eiBwcJiNvEb8Gl0qyQBavjcfYJtNIJSwQ 4a7uxQU7IfX+ommMQ85lkcbs6mnyJ9Pgd/uUHA5mxtJBeabN56WVifL9nqBvMvcog6nU Ewvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712009069; x=1712613869; 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=KvPJcOByCwwyGboE+TfTPiTuSvRCGxfRp7oJKs1QS3o=; b=XH2IXCAwy2kpv6xzp7jaw8eVr/IlvehZXg+ZB/omF3S/rtNkdIZ700FmJ8k3yDSjq1 2VWFv51799kD1mjDBUsbZdQ/yZJt1nsu+e9h7/rFFMjTZvKCBNS7liQ0TF58Lbp/RO+T 0nX1I+TKtO39FUHtt/RmH23RVoNKesPS+OUTr9o4EXsj+ydF9uKvCHgZvKgnfhSnCCEN N92mCR7yx927vEY/cNkaK7VvCBZEjokAbf+CHo4KO+1fglUEXBbdBd9eAZzQHSEHU+Tn uohSKgwm9k9glODo7Q0y1kOWRLv4IxWNj8aMFhNRgEjbm5b/PzvPg2EGK+EKYR7E7Zc+ p1Hw== X-Gm-Message-State: AOJu0Yzdh4acekFJvYILXijddrd+mQCvgevCsxMlIjiVgFPthtI1Bl1/ f5BSf7BZMHW9am8jRmUzoehu26tlUbEX8LOep+seTJUr5x5ZAhsYYReteflGl/lfC7qmMcTBvHg iI07JQs7161xuD85HDU3Buglw4jU= X-Google-Smtp-Source: AGHT+IFfseiJnS7IsJk1GD6Z3J4j49ijJCaWX32+eMlcnjJSS01hBwFJFoxinsSPKmjbiXr9loKYnnFQF9sJfMBtzyM= X-Received: by 2002:a17:90a:af93:b0:29b:33eb:1070 with SMTP id w19-20020a17090aaf9300b0029b33eb1070mr9050178pjq.14.1712009069007; Mon, 01 Apr 2024 15:04:29 -0700 (PDT) MIME-Version: 1.0 References: <1C8781A0-8AFF-4118-B410-D1DB66000F18@vdr.net> In-Reply-To: <1C8781A0-8AFF-4118-B410-D1DB66000F18@vdr.net> From: Hesham ElBakoury Date: Mon, 1 Apr 2024 15:04:18 -0700 Message-ID: To: Christian von der Ropp Cc: Hesham ElBakoury via Starlink , Sebastian Moeller Content-Type: multipart/alternative; boundary="000000000000691d190615102cef" 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: Mon, 01 Apr 2024 22:04:30 -0000 --000000000000691d190615102cef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. 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 GP= S > 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 t= o > become significantly smaller and cheaper than traditional atomic clocks > 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 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 < > 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-disciplin= ed >>> 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 >>>>> challenges: >>>>> > 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 ro= ughly >>>>> at 2/3 of the speed of light in vacuum, while the speed of light in a= ir 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 >>>>> 100000Km/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 s= urface >>>>> 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 nois= e and >>>>> 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 = impact >>>>> on other functionalities. >>>>> > 5. Evolving Technologies: As satellite technologies and application= s >>>>> continue to evolve, new challenges related to synchronization might e= merge. >>>>> For example, the integration of constellations with thousands of sate= llites >>>>> poses unique synchronization challenges due to the sheer scale and >>>>> complexity of the network. >>>>> > These challenges necessitate the development of robust and efficien= t >>>>> time synchronization protocols for satellite networks and an integrat= ed >>>>> satellite and terrestrial networks >>>>> > Are you aware of such time synchronization protocols? >>>>> > I would think that using Satellite simulators is the most viable wa= y >>>>> to develop and test these protocols given that using satellites is no= t 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 >>> gesendet. >>> >> -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > gesendet. > --000000000000691d190615102cef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Christian,
The problems is that = Satellites=C2=A0move, therefore,=C2=A0 the delay between the different dire= ctions is different which violates the condition to run NTP and PTP.=C2=A0<= /div>

Hesham

On Sat, Mar = 2, 2024, 8:19 AM Christian von der Ropp <cvdr@vdr.net> wrote:
<= div dir=3D"auto">Hi Hesham,

You do not acquire the time from a LEO s= atellite but directly from the GPS satellites which carry an atomic clock o= n board.
I'd not be aware of any LEO providing a GNSS signal but Xon= a plan such system (although not carrying proper atomic clocks but probably= chip-sized atomic clocks that require frequent syncing with proper atomic = clocks):
https://twitter.com/Megaco= nstellati/status/1708091536439673323

There are efforts to build = trapped-ion quantum clocks that are expected to become significantly smalle= r and cheaper than traditional atomic clocks while as accurate which would = make it viable to put an atomic clock-equivalent on small LEO satellites. O= nce that happens you would have 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 quantum clocks.

But for NTP clients, the= described method (running a local NTP server in the satellite terminal syn= ced to GPS) should be good enough.

Christian


Am 2. M=C3=A4rz 2024 18:02:47 OEZ sc= hrieb Hesham ElBakoury <helbakoury@gmail.com>:
Hi=C2=A0Christian,
How you synchronize t= he time of the satellites in the network? Are you saying each satellite has= a master clock?

Hesham<= /div>

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 run local = NTP servers instead of syncing via the Internet? LEO satellite terminals al= ways have onboard GNSS antennas for geolocation which is necessary to find = the satellites, so integrating a local GNSS-disciplined Stratum-1 NTP serve= r seems trivial to me.


Am 2. M=C3=A4rz 2024 17:25:59 OEZ schrieb Hesham ElBakoury via Starli= nk <starlink@lists.bufferbloat.net>:
=
Hi=C2=A0Sebastian,
Can we still use PTP = and NTP for time synchronization in=C2=A0 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 <moeller0@g= mx.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 challenges= :
> 1. Signal Propagation Delays: Unlike terrestrial networks where signal= s travel through cables at the speed of light,

[SM] The speed of light in your typical glas fibers (and accidentally the i= nformation 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 l= evel is a mere 90 KM/s slower than in vacuum.

> satellite communication involves signals traveling vast distances thro= ugh space. This creates significant delays.

[SM] Sure distances might be larger, but propagation speed is around 100000= Km/s faster... my main point is speed of light is a) dependent on the mediu= m b) not the things that differentiates space from the earth's surface = 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. T= his drift, caused by factors like temperature variations, radiation exposur= e, and power fluctuations, can lead to inconsistencies in timekeeping acros= s the network.
> 3. Signal Degradation: As signals travel through space, they can degra= de due to factors like atmospheric interference, ionospheric disturbances, = and solar activity. This degradation can introduce noise and errors, impact= ing the accuracy of time synchronization messages.
> 4. Limited Resources: Satellites have limited power and processing cap= abilities. Implementing complex synchronization protocols can be resource-i= ntensive, requiring careful optimization to minimize their impact on other = functionalities.
> 5. Evolving Technologies: As satellite technologies and applications c= ontinue to evolve, new challenges related to synchronization might emerge. = For example, the integration of constellations with thousands of satellites= poses unique synchronization challenges due to the sheer scale and complex= ity of the network.
> These challenges necessitate the development of robust and efficient t= ime synchronization protocols for satellite networks and an integrated sate= llite 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 t= o develop and test these protocols given that using satellites is not that = easy.
> Thanks
> Hesham
>
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net > https://lists.b= ufferbloat.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.
--000000000000691d190615102cef--