Ben erg benieuwd naar _recente_ voorbeelden. Dit was anno 2004 een ding omdat op dat moment clients ook DFS-certification moesten krijgen. Dat was onzin want alle DFS-handelingen zitten op AP en het is ergens rond 2008 teruggedraaid. Heb geen concreet voorbeeld op apparatuur gezien van recenter dan 2010.
Wat wel een ding is: apparaten in verkeerde regulatory domain die denken dat ze in de VS of elders zitten en dus op verkeerde kanalen kijken. Dat is gewoon een device configuration error die zo aan het licht komt, en op het device opgelost moet worden. Dan nog: ook met meuk dat je zelf importeert uit andere werelddelen vrij ongebruikelijk (meeste passen zich aan aan regulatory domain van AP's die ze zien), en als je zelf afwijkende zooi van elders binnen haalt hoor je rekening te houden met dit soort ding.
- Roamen wat trager gaat omdat er eerst DFS scans gedaan moeten worden
Nee, DFS CAC it iets wat de AP's doen. Clients verbinden gewoon met AP's die dat al gedaan hebben. Nul impact op keuze voor of snelheid van roamen.
- DFS kanalen die omspringen omdat het systeem denkt dat er een radar signaal is (false positive)
Dit is wel een ding, en een van de redenen dat ik echt vind dat reviewers steken laten vallen bij WiFi.
Maarja dit zijn zaken die _kunnen_ voorkomen maar het kan ook prima werken. Ik denk dat dit de reden is echter dat je bij consumentenspul geen DFS support tegenkomt. Het kan potentieel gedoe opleveren.
Nee hoor, veel simpelere reden: DFS certificering kost ~EUR 25k per devicetype. Als je iets in kleinere oplage produceert voor een markt waar deze certificering totaal niet meegenomen wordt in consumentenkeuze, is dat een significante kost voor nagenoeg geen commercieel voordeel - dus wordt het niet gedaan. Dat is trouwens niet alleen mijn analyse, ik heb het ook letterlijk zo uitgelegd gekregen van de Europese sales director van een van de grote spelers op de consumentenmarkt. Als hij in eerste instantie hooguit 10k apparaten in EU verwacht te verkopen is dat meerdere EUR per apparaat.
Dat verklaart gelijk waarom providers het steevast wel doen: als je een miljoen apparaten van een type aanschaft gaat het om 2.5c per apparaat. Dat is peanuts. Bovendien: providers krijgen de shit van klanten over zich heen als de boel instabiel en/of traag is.
Tegelijk gaat 5ghz bijzonder slecht door muren, dus de vraag is ook hoe erg is het dat apparaten op hetzelfde kanaal zitten? Ik zit hier bv in de studeerkamer en daar staat 1 deco op 5ghz kanaal 36: -17 RSSI. Het andere ap is niet te ontvangen (woonkamer).
Ga ik naar een slaapkamer toe dan zit ik op een kruispunt. Beide 5ghz accesspoints hebben ongeveer -68 RSSI, dit is verre van ideaal want dan heb je last van elkaar. Echter de high traffic devices staan of in woonkamer of in studeerkamer en op de RF hebben die dus geen last van elkaar.
Het probleem is op de rand, waar je hidden-node problemen krijgt. AP 1 en AP 2 zien elkaar inderdaad niet, maar als je op de rand verbonden bent met AP 1 maar AP 2 (bijna) even sterk ontvangt, kan het makkelijk gebeuren dat als AP 1 iets naar je toe stuurt, tegelijk AP 2 naar een client elders in dat netwerk stuurt. Gevolg: vanuit perspectief van jouw apparaat twee transmissies tegelijkertijd -> transmissie voor jouw client is niet meer te ontcijferen -> frame verloren -> packetloss op hoger protocolniveau.
Maar wat is nu precies het verschil tussen:
- 2 Clients die op hetzelfde accesspoints (en dus hetzelfde kanaal) door elkaar schreeuwen. Die moeten op elkaar wachten
- 2 Clients die op verschillende accesspoints (maar hetzelfde kanaal) Door elkaar schreeuwen. Die moeten ook op elkaar wachten.
Exact niets. Op niveau van Carrier Sense Multiple Access / Collision Avoidance wordt geen onderscheid gemaakt tussen AP's / BSS-en in zelfde kanaal. Je client luistert naar verkeer in het kanaal. Als het een herkenbare header hoort met duration field daarin zet het op basis daarvan z'n Network Allocation Vector (=virtual carrier sense), als de NAV countdown naar nul gedaald is wacht het de verplichte en vervolgens random backoff tijden - en luistert het of de lijn echt nog vrij is, dus geen herkenbare WiFi >-83dBm en geen algemene energie >-63dBm (physical carrier sense), waarna het gaat zenden.
Ik zou verwachten dat er binnen een bssid logica zou plaatsvinden om ervoor te zorgen dat je zo efficient mogelijk na elkaar praat maar in de specs zie ik alleen RF scans terug.
Correct. Overigens is dit een van de dingen dat in WiFi-6 iets anders geregeld is, je hebt dan twee NAV's, eentje voor eigen netwerk, eentje voor andere netwerk, en wordt er iets meer nuance gemaakt tussen signalen van eigen netwerk dichtbij en signalen van ander netwerk verder weg. Of dat in praktijk echt uitmaakt? Geen idee, voordat je dat gaat merken moeten (bijna) alle clients WiFi-6 gebruiken en zo ver zijn we nog lang niet.
Of is dit "airtime fairness" wat ik soms teruglees?
Airtime fairness is iets anders, het is het bewust bevoordelen van transmissies naar clients met hoge link rates ten koste van clients met lage link rates om zo gemiddelde throughput/capaciteit in een BSS te verhogen.
In sommige toepassingen erg nuttig, maar voor thuisgebruik IMHO contraproductief: in een thuisnetwerk is utilization zelden zeer hoog, die tablet in de woonkamer tegenover modemrouter heeft maar een fractie van z'n max bandbreedte nodig om een mooie HD-stream te kijken, terwijl de tablet boven op slaapkamer (uitgaande van geen AP boven) keihard iedere bit nodig heeft om degene daar wel ook een mooie stream te geven. Door in deze situatie meer prio beneden te geven ga je degene die het niet nodig heeft meer geven zonder dat de gebruikservaring beter wordt, terwijl degene die het wel nodig heeft mogelijk hiermee van een bruikbare naar onbruikbare ervaring wegzakt.
Met high density wil je beide niet, dan wil je zoveel mogelijk clients op verschillende accesspoints en kanalen hebben zetten. Maar met een laag gebruik thuissituatie, is het dan echt zo erg? Ik heb vooral last van niet_wifi apparaten die op dezelfde frequentie zitten (zoals babyfoons) want die doen helemaaaal niet aan airtime fairness
Het probleem met alles op zelfde kanaal zit inderdaad meer op vlak van collisions/packetloss aan de randen van BSS-en - maar het gaat hier niet zomaar om zelfde kanaal, maar om veruit drukste kanaal in de 5GHz. Als je enige signalen hebt van je buren, is kans groot dat het uitgerekend hier is.
Ik las ergens terug dat je als er 20db verschil zit tussen de accesspoints dat het minder kwalijk is dat ze op hetzelfde kanaal zitten.
Dat heeft meer met roaming te maken, zolang het verschil scherp is weet je client waar hij op moet zitten en dat het geen knipperlicht wordt tussen de twee AP's. Zolang de signalen >-83dBm zijn moeten devices achter beide AP's op elkaar wachten.
/u/12038/crop5a51514a4dec1_cropped.png?f=community)
:strip_icc():strip_exif()/u/251538/smiley2.jpg?f=community)
Duidelijk dat ik hier nog niet zo in thuis ben.:strip_icc():strip_exif()/u/55250/crop5bfe6e8b5ddb6_cropped.jpeg?f=community)
/u/417613/crop5df91c60a28d2.png?f=community)
:fill(white):strip_exif()/f/image/Iv2mBXJI7x65fEAoqMrELnGr.png?f=user_large)
).:fill(white):strip_exif()/f/image/JPyqXusnhLK0DqKkeJK87BlW.png?f=user_large)