From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 913243CB37 for ; Sat, 2 Mar 2024 10:54:00 -0500 (EST) Received: by mail-pl1-x62b.google.com with SMTP id d9443c01a7336-1dc09556599so29201405ad.1 for ; Sat, 02 Mar 2024 07:54:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709394839; x=1709999639; 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=XXI9B2FHYCqu4ttgUypMIFyMZQcODVUHbZaUtkiUtRI=; b=B5DsS/LgQ4Ucl2jYR8vdTkMREFbBobc8pStLaLzigxVEexDvFXeow45GKo73eo8d2B 5A95TgyGWS0QMSZo+AlVO3w73cr+VVRO4D7w6sYLwjzVoIiQeW687wC3CfOqe1i/odmm dMoVHimzS4nT0sdtpIl20Ivk/cQNJ5tt8iSX4XU3CPLZCFigwe2qJ+LrXm783mNFO/Bx xiDMGthQD4bU7cP6N/uzRFFasKaY9K+dB/90AqcVGhXgMInjsIf2F9j+MLX0aNBXD4Ko M0VAmYV1SRwtE84X2nlpkK3MMLtFgVg8Rf9z5NgXfi8Z5tYIetXpBOdY4LuBjSX01+4Q yykQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709394839; x=1709999639; 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=XXI9B2FHYCqu4ttgUypMIFyMZQcODVUHbZaUtkiUtRI=; b=wm8DP35zs3+oFf5E9JKd3s2AIJn+ZMfsRYnBIxRGb/4L7Xb7YjDVz+qL4zBXkXPaEs Gk38NDyYT6XnZXXiuDjrmfDOtAXJ79W4ZG5LmttFoLCI+ErWWNq0Np9knjdPlRSz2dnQ 1NtcpEQJaHTxHTWSMdGlR+O/pL38E27pJWmX7ryTSN6DuD2wfkBjBxG9XveWlyZSUwqv J3Rhs1On6i19B9ZuiLalzYm2pTz4n/36fRLvsqeqMJIUKa7gm5oULky5uup8zj5cHoNs 5JLdlqqejWJjQbo8keE3NTnvrx1mptq7UnO+tCzzvWEeTD3estIN7ONosgk01VJg5KEl oGIw== X-Gm-Message-State: AOJu0YyNpYPq4An5nji+c/bqeKVu+I0hO7RihmI2rONepV2dEbR/CqBk PWVtzjcSm5CQRQdBZBcwXcvnwt56/Ooe2gWx1xzEyo5HD7FmtBP0pzfjSs/OTCMm1Rr3b7RugK6 NVx8X/sec4fnZZKoaiP+r77LhAEI= X-Google-Smtp-Source: AGHT+IHGoP4u5ikYINyKmWk76/ttV524EVqruS63yCwn9TtfCZY+/1L2DbTodWYvVjOJx5UjYlc34GWbrpLT/+OuJbk= X-Received: by 2002:a17:902:b28c:b0:1dc:cc01:7488 with SMTP id u12-20020a170902b28c00b001dccc017488mr4982111plr.25.1709394839186; Sat, 02 Mar 2024 07:53:59 -0800 (PST) MIME-Version: 1.0 References: <5A2F0F5F-2E77-4764-9859-D447764077D8@gmx.de> In-Reply-To: <5A2F0F5F-2E77-4764-9859-D447764077D8@gmx.de> From: Hesham ElBakoury Date: Sat, 2 Mar 2024 07:53:45 -0800 Message-ID: To: Sebastian Moeller Cc: Dave Taht via Starlink Content-Type: multipart/alternative; boundary="0000000000002bb5550612af80d5" 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 15:54:00 -0000 --0000000000002bb5550612af80d5 Content-Type: text/plain; charset="UTF-8" Hi Sebastian, I agree with you that NTP and PTP are not suitable. We need new protocols. Thanks Hesham On Sat, Mar 2, 2024, 7:45 AM Sebastian Moeller wrote: > Hi Hesham, > > caveat, this is far from my area of expertise, but I would simply try to > get GPS/Glonass/Galileo antennas into the birds and have each sync their > clock individually from such a source, which would remove the necessity for > time synchronisation protocols. That said, I see neither PTP not NTP as > suited, as both presumably assume that server and clients do not move to > fast in relation to each other, while arbitrary members of a LEO > constellation might have quite large relative speds, no? > > Regards > Sebastian > > > On 2. Mar 2024, at 16:25, Hesham ElBakoury wrote: > > > > 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 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 > 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 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. 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 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 applications > continue 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 > 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 that > easy. > > > Thanks > > > Hesham > > > > > > > > > > > > _______________________________________________ > > > Starlink mailing list > > > Starlink@lists.bufferbloat.net > > > https://lists.bufferbloat.net/listinfo/starlink > > > > --0000000000002bb5550612af80d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Sebastian,
I agree=C2=A0with you= that NTP and PTP are not suitable. We need new protocols.

Thanks
Hesham

On Sat, Mar 2, 2024, 7:45 AM Sebastian Moeller <moeller0@gmx.de> wrote:
Hi Hesham,

caveat, this is far from my area of expertise, but I would simply try to ge= t GPS/Glonass/Galileo antennas into the birds and have each sync their cloc= k individually from such a source, which would remove the necessity for tim= e synchronisation protocols. That said, I see neither PTP not NTP as suited= , as both presumably assume that server and clients do not move to fast in = relation to each other, while arbitrary members of a LEO constellation migh= t have quite large relative speds, no?

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

> On 2. Mar 2024, at 16:25, Hesham ElBakoury <helbakoury@gmail.com<= /a>> wrote:
>
> 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
>

--0000000000002bb5550612af80d5--