[Rpm] [Starlink] [LibreQoS] On FiWi

[Frantisek Borsik]

Late to the party, also not an engineer...but if there's something I have
learned during my time with RF elements:

--- 99% of the vendors out there (and most of the ISPs, I dare to say, as
well) don't know/care/respect thing as "simple", as physics.

--- 2.4GHz was lost because of this, and 5GHz was saved like "5 minutes to
midnight" for ISPs, by RF elements Horns (and UltraHorns, UltraDish,
Asymmetrical Horns later on), basically, that have inspired ("Imitation is
the sincerest form of flattery that mediocrity can pay to greatness." Oscar
Wilde) some other vendors of the antennas to bring their own version of
Horns etc.

--- sure, lot of improvements in order to fight noise, modulate, virtualise
(like Tarana Wireless) were done on the AP (radio) side, but still -
physics is physics and it was overlooked and neglected for such a LONG time.

--- ISPs were told by the vendors to basically BLAST through the noise and
many more BS like this. So they did as they were told, they were blasting
and blasting. Those that were getting smarter, switched to RF elements
Horns, stopped blasting, started to being reasonable with topology ("if
Your customers are 5 miles away from the AP, You will not blast like crazy
for 10 miles, because You will pick up all the noise") and they even
started to cooperate - frequency coordination, colocation - with other ISPs
on the same towers etc (the same co-ordination needs to be done between the
ISP behind the CPEs now - on the Wi-Fi routers of their customers.)

The similar development I was able to see when I got into Wi-Fi (while at
TurrisTech <https://blog.cerowrt.org/post/tango_on_turris/> - secure,
powerful open source Wi-Fi routers). The same story, basically, for vendors
as well as ISPs. No actual respect for the underlying physics, attempts to
blast-over the noise, chasing clouds ("muah WiFi 6, 6E....oh no, here comes
Wi-Fi 7 and this will change EVERYTHING ---> see, it was a lot of "fun" to
see this happening with 5G, and the amount of over-promise and
under-delivery BS was and even still is, staggering.)
The whole Wi-Fi industry is chasing (almost) empty numbers (bandwidth)
instead of focusing on bufferbloat (latency, jitter...).
Thanks to Domos for putting together the Understanding Latency webinar
series. I know that most of You are aware of latency as the most important
metric we should focus on nowadays in order to improve the overall Internet
experience, but still...
About 6 hours watch of watching. And rewatching:
https://www.youtube.com/watch?v=KdTPz5srJ8M
https://www.youtube.com/watch?v=tAVwmUG21OY
https://www.youtube.com/watch?v=MRmcWyIVXvg

Also, there is one more thing to add re Wi-Fi. If You can cable, You should
always cable. Mesh as we know it, would be a way better Wi-Fi enhancement,
if the mesh units would be wired as much as possible. We will reduce the
noice, grow smart and save spectrum.

Thanks for the great discussion.

All the best,

Frank

Frantisek (Frank) Borsik



https://www.linkedin.com/in/frantisekborsik

Signal, Telegram, WhatsApp: +421919416714

iMessage, mobile: +420775230885

Skype: casioa5302ca

frantisek.borsik at gmail.com


On Sun, Mar 19, 2023 at 11:27 AM Michael Richardson via Rpm <
rpm at lists.bufferbloat.net> wrote:

>
> {lots of lists on the CC}
>
> The problem I have with lorawan is that it's too small for anything but the
> smallest sensors.  When it breaks (due to infant death or just vanadalism)
> who is going to notice enough to fix it?  My belief is that people won't
> break things that they like/depend upon.  Or at least, that there will be
> social pressure not to.
>
> Better to have a protected 1Mb/s sensor lan within a 144Mb/s wifi than a
> adjacent lorawan.
>
> --
> Michael Richardson <mcr+IETF at sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
>
>
>
> _______________________________________________
> Rpm mailing list
> Rpm at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/rpm/attachments/20230320/8565b3ea/attachment.html>