From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 6AE633CB37 for ; Sat, 2 Mar 2024 13:26:27 -0500 (EST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 422IQPtn031377; Sat, 2 Mar 2024 19:26:25 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5EA3120D94A; Sat, 2 Mar 2024 19:26:25 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5305620D948; Sat, 2 Mar 2024 19:26:25 +0100 (CET) Received: from [10.11.240.6] ([10.11.240.6]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 422IQP5N004329; Sat, 2 Mar 2024 19:26:25 +0100 Message-ID: <660ce5c7-c8c6-4e77-bab7-0fd61fa1a1e1@gmail.com> Date: Sat, 2 Mar 2024 19:26:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: fr To: Hesham ElBakoury Cc: Dave Taht via Starlink References: <9a4e1bb4-0591-40f7-b072-8a1abd60f315@gmail.com> <46eccea2-0fbd-46df-b0cc-70691d4a75f4@gmail.com> From: Alexandre Petrescu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CEA-Virus: SOPHOS_SAVI_ERROR_OLD_VIRUS_DATA 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 18:26:27 -0000 Le 02/03/2024 à 18:26, Hesham ElBakoury a écrit : > But how you address the issues I mentioned before such propagation > delay, clock drifting, and signal degradation, ... Propagation delay is what others call 'latency'.  I believe the current latencies in satcom links of many kinds allow for the use of NTP very well.  Clocks will sync with NTP in sats, but it depends of the synchronisation precision needed. Wouldnt you think so? (clock drifting -  if your source of information is an AI tool, then I suggest to find a way to feed back to the AI tool.  If possible, then I suggest to explain to AI tool how clocks work; clocks drift often when they travel very fast, much faster than how current sats travel, we talk about aproaching speed of light, and sats dont; other times clocks drift because of impurities in some of their hardware and stones - the sats have the same hardware as on ground, so they are subject to same drift as computers where current NTP is run; NTP actually _addresses_ that clock drifting; even the fanciest non-stone but Cesium 'atomic' clocks drift at some point, to a certain degree, on Earth - time is relative, time is a concept of humans, there is no time just a 'long now' someone said) (signal degradation - signals dont degrade when they travel in space; they might degrade with distance, but much less so as when they travel a same distance on ground, be it on fiber) (one asked two AI tools whether Beethoven met Liszt and one got contradictory answers). Alex > > Hesham > > On Sat, Mar 2, 2024, 9:18 AM Alexandre Petrescu via Starlink > wrote: > > some of the question is to what level of precision one wants the > time to > be maintained synchronized between entities, and for what > application? > Nano-second precision?  Less?  More is acceptable?  For what kind of > application?  (I will not give examples). > > I think links with hundred ms latency range and NTP can easily > maintain > nano-second synch'ed precision, from experience with ground links. > > > Le 02/03/2024 à 18:01, Alexandre Petrescu via Starlink a écrit : > > > > Le 02/03/2024 à 16:38, Christian von der Ropp via Starlink a écrit : > >> Why not acquire the time directly from by the satellite > terminal and > >> run local NTP servers instead of syncing via the Internet? > > > > Certainly it is possible to run ntpd servers and clients on > satellites > > and maintain synchronized times.  I would be surprised if some > of them > > dont already do that. > > > > The performance characteristics of some links between some > satellites > > are not very different than links here on ground where NTP is run > > routinely. > > > > NTP was designed and tested at a time when ground links had > inferior > > perf. characteristics than many satcom links of recent years. > > > > Alex > > > > > >> 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ärz 2024 17:25:59 OEZ schrieb Hesham ElBakoury via Starlink > >> : > >> > >>     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 > >>         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 > >> > >> -- > >> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > >> gesendet. > >> > >> _______________________________________________ > >> Starlink mailing list > >> Starlink@lists.bufferbloat.net > >> https://lists.bufferbloat.net/listinfo/starlink > > _______________________________________________ > > Starlink mailing list > > Starlink@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/starlink > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink >