From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) (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 421EC3B29D for ; Mon, 1 Apr 2024 19:09:45 -0400 (EDT) Received: by mail-yb1-f169.google.com with SMTP id 3f1490d57ef6-dc236729a2bso4213440276.0 for ; Mon, 01 Apr 2024 16:09:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712012984; x=1712617784; h=content-transfer-encoding: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=WHyM+OMwmYqfblYQbcjaWE3xZ5Ukg0HP8rBkTdmiIGM=; b=uVQOdqsteQ/RQJ5pSbEuot8BFMs4SOGkciI9tZQipfejyh9xSa4KjUq0oTUExZRw7Y Le1xtjkw/+F7PlVnXKh+pUuijb6kGCl2STK6TzQI/vtcuWnHojOXMsWMTaU0Rx9j0Jfu X14mY8nyVhWeTyOM7QmL5qicbbJWiQ7QH1uN0Nq9kCs4JxIXCz+b1Phv1nVFh8j8JlMW An146KPV6h7YR2fC7x+9VnqVTpqPLkVLnWTzDyzNzr02uci69GiEbnNLyF5MA6leZOiF IdZn8h2ECrjXwQaNdLxQO61CutmWKgr5z6UukmqEC9i0toySfkuqTakAmgN0NtWRelzz OkTQ== X-Forwarded-Encrypted: i=1; AJvYcCVObbxu41+1MKu0xcptnnsucLmklVc/N8qHjJOEF1XQMCnLHIqFfq6LLk/jXry88zazqRG+neF7mIEItgpUqA8rGMshG7wauvkU2ERuFYg= X-Gm-Message-State: AOJu0YxjjT2B/j9KUAzjsjON+59GgEwrZqnNPYYS0glbxzFzGkxabuNc LzjikrOdIVG6NF2sUXruAVVO9845hb0FrCqQoB5v6nSkz9GReAlFzGBZTx595qrP7oNwnlixVnb CLO37XzFUhtJGDzkaupW1LAFHN5Q= X-Google-Smtp-Source: AGHT+IG8oWmWiIxK32r++zHxmmpZQYcsKkePveS4+M8JhSaHPRcAUtkwHHMAnXzhiP3Aeg/LE+6eMrv/xgbXd/Eq4Jk= X-Received: by 2002:a25:9d88:0:b0:dce:53c9:4d9f with SMTP id v8-20020a259d88000000b00dce53c94d9fmr8851189ybp.58.1712012984522; Mon, 01 Apr 2024 16:09:44 -0700 (PDT) MIME-Version: 1.0 References: <1C8781A0-8AFF-4118-B410-D1DB66000F18@vdr.net> <79F8B638-D4B0-4052-AE1C-FC8F4BD75D4D@gmx.de> <3417np1r-845p-pnnq-nn61-n88sr81143sn@ynat.uz> In-Reply-To: <3417np1r-845p-pnnq-nn61-n88sr81143sn@ynat.uz> From: J Pan Date: Mon, 1 Apr 2024 16:09:33 -0700 Message-ID: To: David Lang Cc: Sebastian Moeller , Hesham ElBakoury via Starlink Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 23:09:45 -0000 starlink dish does advertise ".SpaceX.API.Device.GetTimeRequest time =3D 1037" in its latest grpc interface but "PermissionDenied" now. need to convince starlink to be more open as well -- J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pa= n On Mon, Apr 1, 2024 at 3:49=E2=80=AFPM David Lang via Starlink wrote: > > GPS satellites announce their orbit as well. > > But NTP works pretty well in the face of changing path delays. Saying tha= t > Starlink and other LEO internet systems breaks them depends on the accura= cy that > you are looking for. yes the path length changes over the 15 min that you= are on > a satellite, but how much does it change? > > Now, I really wish that Starlink would have the dish act as a NTP server = based > on it's GPS receiver, that would settle the issue. > > David Lang > > > On Tue, 2 Apr 2024, Sebastian Moeller via Starlink wrote: > > > Hi Hesham, > > > > > >> On 2. Apr 2024, at 00:04, Hesham ElBakoury wrot= e: > >> > >> Hi Christian, > >> The problems is that Satellites move, therefore, the delay between th= e different directions is different which violates the condition to run NTP= and PTP. > > > > But GPS Satellites themselves are not in geostationary oprbit, and stil= l we can get precision time from them... so I would argue that must be a so= lved problem, no? > > > > Regards > > Sebastian > > > >> > >> Hesham > >> > >> On Sat, Mar 2, 2024, 8:19 AM Christian von der Ropp wro= te: > >> 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-sized= 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 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'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 : > >> 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 wro= te: > >> 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 : > >> Hi Sebastian, > >> Can we still use PTP and NTP for time synchronization in Satellite ne= tworks or we need new protocols? If we need new protocols, do such protocol= s 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 challeng= es: > >> > 1. Signal Propagation Delays: Unlike terrestrial networks where sign= als 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 th= rough 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 surface= here, but mere geometry and larger distances on larger spheres... > >> > >> > 2. Clock Drift: Even highly precise atomic clocks, used in satellite= s, are susceptible to "drift" - gradually losing or gaining time. This drif= t, caused by factors like temperature variations, radiation exposure, and p= ower fluctuations, can lead to inconsistencies in timekeeping across the ne= twork. > >> > 3. Signal Degradation: As signals travel through space, they can deg= rade due to factors like atmospheric interference, ionospheric disturbances= , and solar activity. This degradation can introduce noise and errors, impa= cting the accuracy of time synchronization messages. > >> > 4. Limited Resources: Satellites have limited power and processing c= apabilities. Implementing complex synchronization protocols can be resource= -intensive, requiring careful optimization to minimize their impact on othe= r 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 satellit= es poses unique synchronization challenges due to the sheer scale and compl= exity of the network. > >> > These challenges necessitate the development of robust and efficient= time synchronization protocols for satellite networks and an integrated sa= tellite 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 tha= t 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. > > > > _______________________________________________ > > 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