starlink dish does advertise ".SpaceX.API.Device.GetTimeRequest time = 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), p...@uvic.ca, Web.UVic.CA/~pan
On Mon, Apr 1, 2024 at 3:49 PM David Lang via Starlink <starlink@lists.bufferbloat.net> wrote: > > GPS satellites announce their orbit as well. > > But NTP works pretty well in the face of changing path delays. Saying that > Starlink and other LEO internet systems breaks them depends on the accuracy > 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 <helbako...@gmail.com> wrote: > >> > >> 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. > > > > But GPS Satellites themselves are not in geostationary oprbit, and still we > > can get precision time from them... so I would argue that must be a solved > > problem, no? > > > > Regards > > Sebastian > > > >> > >> Hesham > >> > >> On Sat, Mar 2, 2024, 8:19 AM Christian von der Ropp <c...@vdr.net> wrote: > >> 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 expected to > >> 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 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 synced to GPS) should be good enough. > >> > >> Christian > >> > >> > >> Am 2. März 2024 18:02:47 OEZ schrieb Hesham ElBakoury > >> <helbako...@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 <c...@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 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 > >> <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 <moell...@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 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. > >> -- > >> 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
