* 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