From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id BA4F03CB37 for ; Sat, 2 Mar 2024 11:19:28 -0500 (EST) ARC-Seal: i=1; a=rsa-sha256; t=1709396367; cv=none; d=strato.com; s=strato-dkim-0002; b=O3aP1Wc71x4Pl9MT+NmqEkwX+0DL88/qn3qHc5A/co2aiHkj3WeD2mdh9V+Opiyg+A kx6WQtaSCuNoHYv5HzTtz1TlvUSxJKkf2vwFQmSiDEpHahm5b6ev/rmdaS71bkBl9/N0 yvX+VFNjnJoW78GUJrIldf3dxEuO6/SUhC8/pyCvrgmbycO2wcfchcgEMe4jI6OBi482 ZaUa5fMY8W3VW2jx8cGzIvKXMxZgUX/Ft9LLTBOxx1+CNGQO5M9H8EgGMrYjJGIS2j41 vIGkkX9itcSxy/U26nfIO8zDNz/WgVJLHaDYiBDwwpYP0VaY+nqoeAbFusFS+f/7/TWs R/qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1709396367; s=strato-dkim-0002; d=strato.com; h=Message-ID:References:In-Reply-To:Subject:CC:To:From:Date:Cc:Date: From:Subject:Sender; bh=OY3JJVm4PuTkwCIFWd/hJzdIJZuwZXD0iJeufpkjqQw=; b=QtVr9EugakRrHPamQ8xFqgNjfxGjTWrduVOcNp4GZSXg3YK0W6tc9tUnFUgGjQfx+M HuhAwvAsy1ToNv1WE0Bsi+3AYhJnwlpLvv/df7lCCev1rhTgaNM6o0awAFKVx+B0l6E+ ILiRbzJQcq1EiwnEPzqj8bIpQ35mFKOciEl5nflyliePQuLHZ3QZO1woygYn4nSUXSsA FBpWRG0YLYMn4iW7dpbGDfEosJPwBfY//6F0eCRjqXpu31XPi+Nv0Z1zMK9PBuQJS3o0 3wQrqLJAmGebRKRUpByL6j+IsWyfvX+X7hGbBZpQUXg/Ml2y1RFk8zv7uSrZXiYazUnd IFqw== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1709396367; s=strato-dkim-0002; d=vdr.net; h=Message-ID:References:In-Reply-To:Subject:CC:To:From:Date:Cc:Date: From:Subject:Sender; bh=OY3JJVm4PuTkwCIFWd/hJzdIJZuwZXD0iJeufpkjqQw=; b=Fl2tbXkE9LAaxOOS6P0nk/FI/HW6K/l2zxyi6mwW1Ho+AGTWKecKpcTwagC6u9WjBj 8ENGxhn/nvEM1bxBX9oJRGgVMFBaH8G2pMObRZIFtlzUMrf1MdMt0hm8U5xKVaqWP2Cw wrZu3EcJHm7ZDEgXNH5ea9d/t/+uFcjFjUjKu1exiFNnjDlQi4uT57qVxzHRse/GrSPl grMbniZjHQErDEhJXOqu8TGCzVh38h9o8pUBVj30IrNKzG5YBzS4fDG19DQy/iD7XKeI /7S/8y1OhN2IxsaJ211hfCZfX5CKUWbXyBogc0cl4oEUy5/a62jX2ssXjlVAxZ7JKqxE 4bUw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1709396367; s=strato-dkim-0003; d=vdr.net; h=Message-ID:References:In-Reply-To:Subject:CC:To:From:Date:Cc:Date: From:Subject:Sender; bh=OY3JJVm4PuTkwCIFWd/hJzdIJZuwZXD0iJeufpkjqQw=; b=6W9+mkWGd5o7MrlZ4KgJoAnZc/5aLVfvdjAkE1J0wPk+19bkooBP0Uhy5VBYXbcY+N Y3GAzZ17UrH/3BFtBzDQ== X-RZG-AUTH: ":L3oAZ2C+f+0rWOBO0o0FCt0K/NLKyHz9AX0t9Z6ZpYP726Y0erZDHmmLmSs=" Received: from [127.0.0.1] by smtp.strato.de (RZmta 50.2.0 DYNA|AUTH) with ESMTPSA id Q628ee022GJQCpa (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Sat, 2 Mar 2024 17:19:26 +0100 (CET) Date: Sat, 02 Mar 2024 18:19:24 +0200 From: Christian von der Ropp To: Hesham ElBakoury CC: Hesham ElBakoury via Starlink , Sebastian Moeller User-Agent: K-9 Mail for Android In-Reply-To: References: Message-ID: <1C8781A0-8AFF-4118-B410-D1DB66000F18@vdr.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=----F5319KKWPOW5ZUKO8159LUM0X8UJ8E Content-Transfer-Encoding: 7bit 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: Sat, 02 Mar 2024 16:19:29 -0000 ------F5319KKWPOW5ZUKO8159LUM0X8UJ8E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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=2E I'd not be aware of any LEO providing a GNSS signal but Xona plan such sys= tem (although not carrying proper atomic clocks but probably chip-sized ato= mic clocks that require frequent syncing with proper atomic clocks): https://twitter=2Ecom/Megaconstellati/status/1708091536439673323 There are efforts to build trapped-ion quantum clocks that are expected to= become significantly smaller and cheaper than traditional atomic clocks wh= ile as accurate which would make it viable to put an atomic clock-equivalen= t on small LEO satellites=2E Once that happens you would have an independen= t alternative to the big GNSS birds in MEO but with stronger signals=2E I'm= told that we are 5-10 years away from such trapped-ion quantum clocks=2E But for NTP clients, the described method (running a local NTP server in t= he satellite terminal synced to GPS) should be good enough=2E Christian Am 2=2E M=C3=A4rz 2024 18:02:47 OEZ schrieb Hesham ElBakoury : >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 wrot= e: > >> 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=2E >> >> >> Am 2=2E M=C3=A4rz 2024 17:25:59 OEZ schrieb Hesham ElBakoury via Starli= nk < >> starlink@lists=2Ebufferbloat=2Enet>: >> >>> 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 wro= te: >>> >>>> Hi Hesham >>>> >>>> > On 2=2E Mar 2024, at 16:03, Hesham ElBakoury via Starlink < >>>> starlink@lists=2Ebufferbloat=2Enet> wrote: >>>> > >>>> > Time synchronization, for satellite networks, faces several challen= ges: >>>> > 1=2E 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=2E >>>> >>>> > satellite communication involves signals traveling vast distances >>>> through space=2E This creates significant delays=2E >>>> >>>> [SM] Sure distances might be larger, but propagation speed is around >>>> 100000Km/s faster=2E=2E=2E my main point is speed of light is a) depe= ndent 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=2E=2E= =2E >>>> >>>> > 2=2E Clock Drift: Even highly precise atomic clocks, used in satell= ites, >>>> are susceptible to "drift" - gradually losing or gaining time=2E This= drift, >>>> caused by factors like temperature variations, radiation exposure, an= d >>>> power fluctuations, can lead to inconsistencies in timekeeping across= the >>>> network=2E >>>> > 3=2E Signal Degradation: As signals travel through space, they can >>>> degrade due to factors like atmospheric interference, ionospheric >>>> disturbances, and solar activity=2E This degradation can introduce no= ise and >>>> errors, impacting the accuracy of time synchronization messages=2E >>>> > 4=2E Limited Resources: Satellites have limited power and processin= g >>>> capabilities=2E Implementing complex synchronization protocols can be >>>> resource-intensive, requiring careful optimization to minimize their = impact >>>> on other functionalities=2E >>>> > 5=2E Evolving Technologies: As satellite technologies and applicati= ons >>>> continue to evolve, new challenges related to synchronization might e= merge=2E >>>> 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=2E >>>> > 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=2E >>>> > Thanks >>>> > Hesham >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > Starlink mailing list >>>> > Starlink@lists=2Ebufferbloat=2Enet >>>> > https://lists=2Ebufferbloat=2Enet/listinfo/starlink >>>> >>>> -- >> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail >> gesendet=2E >> --=20 Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesende= t=2E ------F5319KKWPOW5ZUKO8159LUM0X8UJ8E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Hesham,

You do not acq= uire the time from a LEO satellite but directly from the GPS satellites whi= ch carry an atomic clock on board=2E
I'd not be aware of any LEO providi= ng a GNSS signal but Xona plan such system (although not carrying proper at= omic clocks but probably chip-sized atomic clocks that require frequent syn= cing with proper atomic clocks):
https://twitter=2Ecom/Megaconstellati= /status/1708091536439673323

There are efforts to build trapped-i= on quantum clocks that are expected to become significantly smaller and che= aper than traditional atomic clocks while as accurate which would make it v= iable to put an atomic clock-equivalent on small LEO satellites=2E Once tha= t happens you would have an independent alternative to the big GNSS birds i= n MEO but with stronger signals=2E I'm told that we are 5-10 years away fro= m such trapped-ion quantum clocks=2E

But for NTP clients, the descri= bed method (running a local NTP server in the satellite terminal synced to = GPS) should be good enough=2E

Christian


Am 2=2E M=C3=A4rz 2024 18:02:47 OEZ schr= ieb Hesham ElBakoury <helbakoury@gmail=2Ecom>:
Hi Christian,
How you synchronize = the time of the satellites in the network? Are you saying each satellite ha= s a master clock?

Hesham=

On Sat, Mar 2, 2024, 7:38 AM Christian von der Ropp <cvdr@vdr=2Enet> 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 always have onboard GNSS antenna= s for geolocation which is necessary to find the satellites, so integrating= a local GNSS-disciplined Stratum-1 NTP server seems trivial to me=2E
=

Am 2=2E M=C3=A4rz 2024= 17:25:59 OEZ schrieb Hesham ElBakoury via Starlink <sta= rlink@lists=2Ebufferbloat=2Enet>:
Hi Sebastian,
Can we still use PTP= and NTP for time synchronization in  Satellite networks or we need ne= w protocols? If we need new protocols, do such protocols exist?

Thanks
Hesha= m

On Sat, Mar 2, 2024, 7:18 AM Sebastian Moeller <moeller0@gmx=2Ede<= /a>> wrote:
Hi Hesham

> On 2=2E Mar 2024, at 16:03, Hesham ElBakoury via Starlink <starlink@lists=2Ebufferbloat=2Enet> wrote:
>
> Time synchronization, for satellite networks, faces several challenge= s:
> 1=2E Signal Propagation Delays: Unlike terrestrial networks where sig= nals 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=2E

> satellite communication involves signals traveling vast distances thr= ough space=2E This creates significant delays=2E

[SM] Sure distances might be larger, but propagation speed is around 10000= 0Km/s faster=2E=2E=2E my main point is speed of light is a) dependent on th= e medium b) not the things that differentiates space from the earth's surfa= ce here, but mere geometry and larger distances on larger spheres=2E=2E=2E<= br>
> 2=2E Clock Drift: Even highly precise atomic clocks, used in satellit= es, are susceptible to "drift" - gradually losing or gaining time=2E This d= rift, caused by factors like temperature variations, radiation exposure, an= d power fluctuations, can lead to inconsistencies in timekeeping across the= network=2E
> 3=2E Signal Degradation: As signals travel through space, they can de= grade due to factors like atmospheric interference, ionospheric disturbance= s, and solar activity=2E This degradation can introduce noise and errors, i= mpacting the accuracy of time synchronization messages=2E
> 4=2E Limited Resources: Satellites have limited power and processing = capabilities=2E Implementing complex synchronization protocols can be resou= rce-intensive, requiring careful optimization to minimize their impact on o= ther functionalities=2E
> 5=2E Evolving Technologies: As satellite technologies and application= s continue to evolve, new challenges related to synchronization might emerg= e=2E 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=2E
> These challenges necessitate the development of robust and efficient = time synchronization protocols for satellite networks and an integrated sat= ellite 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 that= easy=2E
> Thanks
> Hesham
>
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists=2Ebufferbloat=2Enet
> https://lists=2Ebuf= ferbloat=2Enet/listinfo/starlink

--
Diese Nachricht wurde von= meinem Android-Mobiltelefon mit K-9 Mail gesendet=2E
-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesend= et=2E
------F5319KKWPOW5ZUKO8159LUM0X8UJ8E--