Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: Hesham ElBakoury <helbakoury@gmail.com>
Cc: Dave Taht via Starlink <starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] Time Synchronization in Satellite Networks
Date: Sat, 2 Mar 2024 16:18:14 +0100	[thread overview]
Message-ID: <CBD793C6-D7C6-42BD-B55F-B53C520119B2@gmx.de> (raw)
In-Reply-To: <CAFvDQ9rhgubnSttWwisiAmvLaoykxLhKr+qBPPd7FgQGxn2q9g@mail.gmail.com>

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


  reply	other threads:[~2024-03-02 15:18 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-02 15:03 Hesham ElBakoury
2024-03-02 15:18 ` Sebastian Moeller [this message]
2024-03-02 15:25   ` Hesham ElBakoury
2024-03-02 15:38     ` Christian von der Ropp
2024-03-02 16:02       ` Hesham ElBakoury
2024-03-02 16:19         ` Christian von der Ropp
2024-04-01 22:04           ` Hesham ElBakoury
2024-04-01 22:22             ` Sebastian Moeller
2024-04-01 22:48               ` David Lang
2024-04-01 23:09                 ` J Pan
2024-04-02  0:29               ` Hesham ElBakoury
2024-04-02  0:34                 ` David Lang
2024-04-02  0:59                   ` Vint Cerf
2024-03-02 17:01       ` Alexandre Petrescu
2024-03-02 17:18         ` Alexandre Petrescu
2024-03-02 17:26           ` Hesham ElBakoury
2024-03-02 18:26             ` Alexandre Petrescu
2024-03-02 15:45     ` Sebastian Moeller
2024-03-02 15:53       ` Hesham ElBakoury
2024-03-02 17:08 ` Alexandre Petrescu
2024-03-02 17:09 ` Alexandre Petrescu
2024-04-30  8:46 David Fernández
2024-04-30 17:12 ` J Pan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CBD793C6-D7C6-42BD-B55F-B53C520119B2@gmx.de \
    --to=moeller0@gmx.de \
    --cc=helbakoury@gmail.com \
    --cc=starlink@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox