* Re: [LibreQoS] [Starlink] tarana strikes back
[not found] ` <CAKJdXWCWxEFbZJ6u-=09UND5HwbZ=U3yXdQ4qjwU2Hp4XL8aXQ@mail.gmail.com>
@ 2023-09-24 20:37 ` Dave Taht
2023-09-25 8:11 ` David Lang
0 siblings, 1 reply; 5+ messages in thread
From: Dave Taht @ 2023-09-24 20:37 UTC (permalink / raw)
To: Luis A. Cornejo, libreqos; +Cc: Dave Taht via Starlink
That particular wisp so broadcasting their activities is deploying
"preseem" over tarana to manage their bufferbloat issues with great
success... although it would be nice if the tarana cpe uplink radio
had it more under control with a smaller fixed size buffer, at least,
and less retries in the mac. The right place to manage uplink
bufferbloat is at the uplink, not the central controller.
Everytime that wisp posts their tarana speedtest number, they show
300ms + buffering on the uplink side, which, while dramatically better
than 5g or starlink is still 10x too much.... and I pester them about
it. Sometimes they repost with the post-preseem number, sometimes not.
(preseem uses fq_codel).
The principal complaints about tarana are it is really, really
expensive, it uses up a lot of spectrum, and they have a lot more hype
than I would like. Because the barrier to entry is so high, many
other alternatives may well be more cost-effective. I would certainly
like to see, touch, and test a setup myself! I like NLOS (non-line of
sight) technologies for incredibly difficult shots...
But:
My purpose in asking the list here was to ask if the analysis of cell
size was correct and reasonable (it certainly looked so to me), and
the economic argument that falls out of the resulting information
density seems compelling for designing hybrid fiber and wireless
networks of all sorts, not as an endorsement of tarana.
On Sun, Sep 24, 2023 at 1:19 PM Luis A. Cornejo
<luis.a.cornejo@gmail.com> wrote:
>
> Dave,
>
> Have you actually seen it in person? How is the bufferbloat situation? From the videos I've seen from WISPs and stuff Tarana shares on twitter it seems to be under control, but they seem very bandwidth oriented. A WISP (NextLink) seems to be deploying them, but it seems that is not near where I am. I inquired and they said I wasn't LOS to the tower. I responded back as to when they will deploy Tarana radios in my area and I got crickets.
>
> -Luis
>
> -Luis
>
> On Sat, Sep 23, 2023 at 9:34 PM Dave Taht via Starlink <starlink@lists.bufferbloat.net> wrote:
>>
>> Tarana, which is indeed, delivering one of the most amazing NLOS WISP
>> experiences I have ever seen,
>> just put out this white paper:
>>
>> https://www.taranawireless.com/a-comparison-of-next-generation-fwa-vs-leo-satellite/
>>
>> Can anyone question these Starlink numbers for cell size, etc?
>>
>> --
>> Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
>> Dave Täht CSO, LibreQos
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
--
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [LibreQoS] [Starlink] tarana strikes back
2023-09-24 20:37 ` [LibreQoS] [Starlink] tarana strikes back Dave Taht
@ 2023-09-25 8:11 ` David Lang
2023-09-26 18:37 ` [LibreQoS] [Starlink] Starlink cell capacity (was; tarana strikes back) Jim Forster
0 siblings, 1 reply; 5+ messages in thread
From: David Lang @ 2023-09-25 8:11 UTC (permalink / raw)
To: Dave Taht; +Cc: Luis A. Cornejo, libreqos, Dave Taht via Starlink
On Sun, 24 Sep 2023, Dave Taht via Starlink wrote:
> My purpose in asking the list here was to ask if the analysis of cell
> size was correct and reasonable (it certainly looked so to me), and
> the economic argument that falls out of the resulting information
> density seems compelling for designing hybrid fiber and wireless
> networks of all sorts, not as an endorsement of tarana.
>
>>> https://www.taranawireless.com/a-comparison-of-next-generation-fwa-vs-leo-satellite/
>>>
>>> Can anyone question these Starlink numbers for cell size, etc?
I think they have the cell size reasonably accuarate (for now), But if the cell
sizes were of fixed size and unable to be re-used, once there were enough
satellites to provide global coverage, adding more would not provide any value.
But even their first phase includes many times the number they needed to provide
global coverage, so the assumptions around the capacity being fixed by the
initial cell size and a single satellite covering it cannot be correct.
I question the assumption that there will only be a single satellite serving the
cell at a time. With directional antennas (including phased arrays) you can aim
both your uplink and downlink.
Even without having multiple satellites covering a single cell, you can shrink
the cells by having the ground stations further from the center of the cell aim
at different parts of the sky.
Lower altitude satellites will have smaller cells with the same antennas,
reducing the altitude from ~560km to ~340km reduces the spot size by ~2.5 so you
get somewhere around 7 spots in the same footprint (and need less power, so you
generate less interference to other cellss, so you can re-use the same
frequency in closer proximity, a virtue cycle), it also reduces the latency.
Larger satellites allow for physically bigger antennas, which increase the
ability to focus, use less power on both ends, and be more immune to signals
from the wrong direction, very similar to what the lower altitude gives you
(without the decreased latency that the lower altitude provides)
So in the big picture, they are correct with the basic idea that WISPs can
outperform Starlink, the real questions are around where the crossover point is,
and if WISPs are going to build out in enough areas. It doesn't matter if a WISP
could outperform Starlink if they don't build it, or don't run sufficient
capacity of wired Internet to the tower.
WISP endpoint equipment could be cheaper than Starlink dishes (it's far simpler,
but Starlink now has economies of scale kicking in that have reduced their
production costs by 5x or better, even in the face of inflation, the early
dishies were reported to cost ~$3k each to build, now with them selling for $600
(less in some places, don't know the average selling price) they are no longer
losing money on each dishy sold. That's getting down into the price for the WISP
endpoint equipment costs. and the WISP has to pay installers to setup that
equipment as well as covering the hardware costs.
This doesn't mean that Starlink will outperform WISPs in raw speed, but they may
be cheaper in many areas, pushing the crossover point to denser population areas
before it becomes congested enough for people to prefer the WISP
David Lang
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [LibreQoS] [Starlink] Starlink cell capacity (was; tarana strikes back)
2023-09-25 8:11 ` David Lang
@ 2023-09-26 18:37 ` Jim Forster
2023-09-26 19:00 ` David Lang
0 siblings, 1 reply; 5+ messages in thread
From: Jim Forster @ 2023-09-26 18:37 UTC (permalink / raw)
To: David Lang; +Cc: Dave Taht, Dave Taht via Starlink, Luis A. Cornejo, libreqos
[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]
> On Sep 25, 2023, at 4:11 AM, David Lang via LibreQoS <libreqos@lists.bufferbloat.net> wrote:
>
>>>>
>>>> https://www.taranawireless.com/a-comparison-of-next-generation-fwa-vs-leo-satellite/ <https://www.taranawireless.com/a-comparison-of-next-generation-fwa-vs-leo-satellite/>
>>>>
>>>> Can anyone question these Starlink numbers for cell size, etc?
>
> I think they have the cell size reasonably accuarate (for now), But if the cell sizes were of fixed size and unable to be re-used, once there were enough satellites to provide global coverage, adding more would not provide any value. But even their first phase includes many times the number they needed to provide global coverage, so the assumptions around the capacity being fixed by the initial cell size and a single satellite covering it cannot be correct.
>
> I question the assumption that there will only be a single satellite serving the cell at a time. With directional antennas (including phased arrays) you can aim both your uplink and downlink.
>
> Even without having multiple satellites covering a single cell, you can shrink the cells by having the ground stations further from the center of the cell aim at different parts of the sky.
This is all true (as much as I understand), Worth noting as well, is that with LEOs if one satellite is maxed out serving a cell, then getting a second satellite to help with that cell mean adding *lots* more satellites. If adjacent cells had very different loads then I guess nearby unloaeded satellites could help out their busy neighbors. But areas with busy cells close together would mean doubling the number of satellites and therefore platform Capex. Whereas terrestrial towers can be densified in busy areas.
— Jim
[-- Attachment #2: Type: text/html, Size: 5693 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [LibreQoS] [Starlink] Starlink cell capacity (was; tarana strikes back)
2023-09-26 18:37 ` [LibreQoS] [Starlink] Starlink cell capacity (was; tarana strikes back) Jim Forster
@ 2023-09-26 19:00 ` David Lang
2023-09-26 23:05 ` dan
0 siblings, 1 reply; 5+ messages in thread
From: David Lang @ 2023-09-26 19:00 UTC (permalink / raw)
To: Jim Forster
Cc: David Lang, Dave Taht, Dave Taht via Starlink, Luis A. Cornejo, libreqos
On Tue, 26 Sep 2023, Jim Forster wrote:
> This is all true (as much as I understand), Worth noting as well, is that with
> LEOs if one satellite is maxed out serving a cell, then getting a second
> satellite to help with that cell mean adding *lots* more satellites. If
> adjacent cells had very different loads then I guess nearby unloaeded
> satellites could help out their busy neighbors. But areas with busy cells
> close together would mean doubling the number of satellites and therefore
> platform Capex. Whereas terrestrial towers can be densified in busy areas.
In 2021 when SpaceX had launched 1800 satellites they said that once all of them
reached operational altitude they would be able to provide global coverage.
They now have >4k satellites in operation and (if fully approved) are aiming at
~10x that number eventually. That leaves a lot of additional satellites to
provide additional coverage for busy cells or smaller cells.
I agree terrestrial towers can be densified more easily in a specific area.
I'm saying that the crossover point where the density favors terrestrial towers
is significantly denser than the original author was stating. (and as more sats
are launched, will move further)
There's also the fact that satellite densification covers all areas, where
terrestrial tower densification only covers that area. So around the already
dense areas, you will have tower densification happening, pushing out,
leveraging the nearby wired infrastructure. But you may see a different
situation in areas where small communities are growing and you have to setup the
tower and wired infrastructure from scratch.
scenario:
a village that is a 30 min drive from the next community and doesn't
have much fiber run to it. As it grows, you can't just put in towers without
also running tens of miles of fiber to the area, so densification of towers in
the area is significantly harder than seeing the suburbs of a large city grow
where fiber is just a couple miles away.
David Lang
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [LibreQoS] [Starlink] Starlink cell capacity (was; tarana strikes back)
2023-09-26 19:00 ` David Lang
@ 2023-09-26 23:05 ` dan
0 siblings, 0 replies; 5+ messages in thread
From: dan @ 2023-09-26 23:05 UTC (permalink / raw)
To: David Lang; +Cc: Jim Forster, Dave Taht via Starlink, libreqos, Luis A. Cornejo
[-- Attachment #1: Type: text/plain, Size: 5839 bytes --]
I'd like to question those numbers as stated by Tarana.
Firstly, no provider can possibly get 100% utilization based on average
use. If average use is 10M and you have 2200Mbps on an AP, you can only
possibly serve 220 users that have 10Mbps plans. If you have 100Mbps
plans you cannot have 220 users though as there has to be a substantial
reserve to accommodate their bursty traffic up to plan speed. From our
networks, I would say this is approximately 1 maximum plan speed reserved
every 25 subscribers. I am of course just picking on a single AP, Tarana
has pitched a 4 APs per tower all using the same frequency (which is a
really nice trick) aka 'reuse of 1' so you can multiple any numbers I say
here by 4 to accommodate a full tower and you could potentially double that
and have 8 Tarana APs on a tower and then triple that when 6Ghz is
available and so on.
So 100 subscribers with 100M plans needs a ~400Mbps reserve. This is well
supported in our statistics and lots of operators will land at a somewhat
similar number when looking at their oversells.
Of Tarana's 2200M stated speeds (which are more like 1400 per operators
I've talked to but I digress...) 400Mbps per 100 subs needs to be scraped
off the top and you need 1000M for average use, so that's fine at 1400M
needed to 2200M claimed (but again, many operators will say 1400M available
so..... about a 100x100M subscribers on this math). however, 200 subs is
2Gbps use but needs an 800Mbps reserve so that's well oversold and the AP
will certainly see congestion during peak hours. 2800M needed on 2200M
*or* 2800M needed on 1400M... Likely nightly congestion that could be 50%
of sold capacity.
Now, in support of Tarana's claims. LEO satellites have a much more
limited geometry to work with, with a service cone of not more than about
15% of the satellites' view being of earth, the rest being of space....
which. means the antenna has to handle far more in far less. Terrestrial
towers however have up to 360 degrees and up to about 50 degrees in
elevation, only blocked by obstructions and tarana's tech overcomes a good
part of that. At the borders of that service area, build another tower.
LEO can try to put more satellites up, but these satellites are
broadcasting down and even with really advanced beamforming each one
creates more noise at the ground stations. They also need to have at least
about 20 degrees separation for the ground stations to effectively utilize
beamforming and nulling to avoid the noise. ie, it's not so simple to
just add more LEO birds and get linear results, however it is relatively
easy to add more towers and get a linear increase in capacity because
client radios tend to be facing away from all towers except the one they
are aimed at.
There are definitely use cases for both techs, but if we're talking about
capacity in any given area with enough population to support terrestrial
towers, there really is no competition, terrestrial can out perform LEO by
an order of magnitude because geometry says so. however, LEO gear like
starlink is a godsend for people that are outside of that footprint.
I can rant all day about the inherent limitations to LEO based purely on
physics as well as the absolute requirement for dedicated spectrum that is
much better handled with terrestrial towers but I'll save you all's eyes.
On Tue, Sep 26, 2023 at 1:00 PM David Lang via LibreQoS <
libreqos@lists.bufferbloat.net> wrote:
> On Tue, 26 Sep 2023, Jim Forster wrote:
>
> > This is all true (as much as I understand), Worth noting as well, is
> that with
> > LEOs if one satellite is maxed out serving a cell, then getting a second
> > satellite to help with that cell mean adding *lots* more satellites. If
> > adjacent cells had very different loads then I guess nearby unloaeded
> > satellites could help out their busy neighbors. But areas with busy
> cells
> > close together would mean doubling the number of satellites and
> therefore
> > platform Capex. Whereas terrestrial towers can be densified in busy
> areas.
>
> In 2021 when SpaceX had launched 1800 satellites they said that once all
> of them
> reached operational altitude they would be able to provide global coverage.
>
> They now have >4k satellites in operation and (if fully approved) are
> aiming at
> ~10x that number eventually. That leaves a lot of additional satellites to
> provide additional coverage for busy cells or smaller cells.
>
> I agree terrestrial towers can be densified more easily in a specific area.
>
> I'm saying that the crossover point where the density favors terrestrial
> towers
> is significantly denser than the original author was stating. (and as more
> sats
> are launched, will move further)
>
> There's also the fact that satellite densification covers all areas, where
> terrestrial tower densification only covers that area. So around the
> already
> dense areas, you will have tower densification happening, pushing out,
> leveraging the nearby wired infrastructure. But you may see a different
> situation in areas where small communities are growing and you have to
> setup the
> tower and wired infrastructure from scratch.
>
> scenario:
>
> a village that is a 30 min drive from the next community and doesn't
> have much fiber run to it. As it grows, you can't just put in towers
> without
> also running tens of miles of fiber to the area, so densification of
> towers in
> the area is significantly harder than seeing the suburbs of a large city
> grow
> where fiber is just a couple miles away.
>
> David Lang
> _______________________________________________
> LibreQoS mailing list
> LibreQoS@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/libreqos
>
[-- Attachment #2: Type: text/html, Size: 6461 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-09-26 23:06 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CAA93jw56+8qi_F6325rQeB8Lr-GivvvCB0hkR2019FXdbHw7Uw@mail.gmail.com>
[not found] ` <CAKJdXWCWxEFbZJ6u-=09UND5HwbZ=U3yXdQ4qjwU2Hp4XL8aXQ@mail.gmail.com>
2023-09-24 20:37 ` [LibreQoS] [Starlink] tarana strikes back Dave Taht
2023-09-25 8:11 ` David Lang
2023-09-26 18:37 ` [LibreQoS] [Starlink] Starlink cell capacity (was; tarana strikes back) Jim Forster
2023-09-26 19:00 ` David Lang
2023-09-26 23:05 ` dan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox