It’s not really oversold bandwidth. It’s just that the turnaround time for a bolus of data is too long for two-way video conferencing to be smooth or reliable. It’s like video conferencing using post cards :)
-mel > On Apr 21, 2020, at 11:36 AM, Brian J. Murrell <br...@interlinx.bc.ca> wrote: > > On Tue, 2020-04-21 at 11:11 -0700, Sabri Berisha wrote: >> Hi, > > Hi, > >> Where I worked, phy transmissions are scheduled based on tokens. A UT >> must have a token to transmit data. If there is no congestion, a >> token will be available and the UT or ground station may transmit. >> Congestion does not need to exist in the ground network or even the >> transponder. It can even be in the spectrum of that geographical >> area. > > Interesting. So basically as Mel said, over-sold network. :-( > >> To overcome the latency, > > Latency (AFAIU) is not really his primary issue. it's the lack of > consistency in bandwidth. Periods of a second or two even where there > is no transmission of anything at all followed by a second or two of > transmission bursting even beyond his subscribed "rate". This effects > his subscribed rate but in a really bad way for real-time traffic such > as live/two-way video. He'd much, much more rather get a consistent > pipe at his prescribed rate rather than an average of it over longer > periods of time because then the codec would not have be encoding for > those super bad periods of time where there are 1-2 seconds of no > bandwidth at all. > >> Satellite is obviously not the optimal medium for video conferencing, > > Indeed. > >> but I would recommend that your friend tries to ratelimit their >> transmissions. > > He doesn't need to. The over-congested network is doing that for him. > :-( In any case, I don't know that he has any way to put a rate limit > on the tools he is using. > >> The reason why your latency is higher than you expect, > > It actually isn't. It's nowhere near as high as I had come to > (anecdotally -- I'd never had reason to do the math on the latency > before now) believe it would be. > > Fortunately he might be a candidate for Xplornet (or others') WISP > services. Hopefully they are a bit more stable. > > Cheers, > b. >