Det här är på gång i Wifi 6 – nästa generations trådlösa nätverk

Det här är på gång i Wifi 6 – nästa generations trådlösa nätverk

Nästa generations trådlösa nätverk börjar sakta men säkert nå marknaden. I denna artikel går Yoshman igenom tekniken och vad den tillför jämfört med tidigare versioner.

Läs hela artikeln här

Ruskigt bra artikel!

Mycket trevlig läsning.

Säkerhet och wpa3 hade varit trevligt att nämna men det skulle kanske vara en bra del 2 till denna artikel då det verkar vara optionellt.

Citat:

OFDMA är också förklaringen till varför Wifi 6 kommer ge lägre latens. Om tio enheter tidigare kommunicerade kunde det gå upp till nio symboler innan data kunde skickas. Med Wifi 6 finns stor möjlighet att enheter med krav på låg latens, men där mängden data är liten, kan kommunicera i varje eller i alla fall de flesta symboltider. Spel är exempel på applikationer som borde kunna dra nytta av detta.

Blir inte matten helt enkelt antal symboltider gånger symboltiden i mikrosekunder? Isåfall borde man ju bara spara in c:a 0.1 ms i exemplet med 10 enheter, eller?

Väntar bara på PCE-AX88

Problemet här är att övergången till att bara ge det ett nummer kommer att "fördumma" konsumenterna så att det bara blir svårare. Var hamnar t.ex. 802.11ad (60 GHz).

Skrivet av EDC:

Mycket trevlig läsning.

Säkerhet och wpa3 hade varit trevligt att nämna men det skulle kanske vara en bra del 2 till denna artikel då det verkar vara optionellt.

Om jag inte missförstått något så är WPA3 rent tekniskt helt separerat från 802.11ax och därmed Wi-Fi 6.

Däremot är WPA3 ett krav om man vill sätta stämpeln "Wi-Fi 6 Certified" på sin produkt.

Om det är korrekt är den nya märkningen inte helt superenkel att hålla ordning på...

As usual, utmärkta och trevliga aetiklar av dig @Yoshman

Skrivet av Yoshman:

Om det är korrekt är den nya märkningen inte helt superenkel att hålla ordning på...

VA?! En teknikmärkning som är RÖRIG?! Det har väl ALDRIG hänt förut?!

Skrivet av Thomas:

Blir inte matten helt enkelt antal symboltider gånger symboltiden i mikrosekunder? Isåfall borde man ju bara spara in c:a 0.1 ms i exemplet med 10 enheter, eller?

Protokollstacken för 802.11 har fler lager än Ethernet. Måste kolla upp exakta detaljer, men stora IP-paket lär behöva delas upp över flera symboltider för att få plats.

Vidare är det primärt inte i fall när väldigt lite kommunikation sker som latensminskningen är störts för Wi-Fi 6, utan det är i fallen när det är väldigt många enheter som vill kommunicera samtidigt vinster märks som mest.

Tiden mellan en viss klient får skicka man då vara riktigt lång när man kör ren round-robin. OFDMA kan utnyttjas på flera sätt för att minska latens/effektivitet, en klient med riktigt hårda latenskrav kan alltid få en viss plats i etern vilket då kan ge klart lägre latens (upp till 60 % enligt detta).

Rent matematiskt stämmer din beräkning för fallet när det är just nio enheter, det är maximala antalet som samtidigt kan skicka om man kör OFDMA. Men går att göra betydligt större vinster i latens om det är väsentligt fler enheter än nio som är inblandade.

Edit: där matematiken inte blir rätt är att från 802.11n (Wi-Fi 4) så packar man typiskt ihop flera paket per sänd-tillfälle för en viss enhet, det för att minska overhead per sänd databit. Det betyder att tiden att gå ett varv med N st enheter är större än N gånger symboltid.

Pingar man från den vänstra klienten till andra AP i denna topologi

kan det se ut så här

1000 packets transmitted, 1000 received, 0% packet loss, time 1374ms rtt min/avg/max/mdev = 1.070/1.304/5.862/0.244 ms, ipg/ewma 1.375/1.264 ms

Samma manöver från vänstra klienten till första AP, d.v.s. enbart Ethernet, kan se ut så här

1000 packets transmitted, 1000 received, 0% packet loss, time 619ms rtt min/avg/max/mdev = 0.520/0.581/0.911/0.031 ms, ipg/ewma 0.620/0.568 ms

Detta pekar nog mot att det är hantering i accesspunkterna som lägger på majoriteten av latensen, inte hantering av Wi-Fi. Ethernet hanteras riktigt effektivt då systemkretsen i RT-AX88U i praktiken hanterar switching delen i dedicerad HW, medan den trådlösa delen involverar CPU+OS

Sitter fyra stycken Cortex A53 @ 1,8 GHz, d.v.s. CPU-mässigt är det en högre klockad RPi3. Dock har systemkretsen i RT-AX88U rätt ordentligt mycket bättre I/O-stöd och framförallt acceleration för I/O på sätt som helt saknas i RPi3

Senast redigerat 2019-06-04 07:22

Bra artikel! Håller med om att även WPA3 hade varit intressant att ha med.

Relaterad sidofråga: är goben att föredra framför Iperf?

Skrivet av backfeed:

Relaterad sidofråga: är goben att föredra framför Iperf?

Finns två stora fördelar med goben över iperf i just detta fall.

Ville köra även goben direkt på routern. Även om ASUS, likt de flesta hemma routers idag, kör en variant av Linux så är det ofta en utmaning att korskompilera applikationer på ett sätt så att de fungerar. Detta problem kommer av att det nästa allt finns dolda beroenden i binären som man måste få till

Men det är bara nästan! Saker som är skrivet i programspråket Go och kompileras med den standardmiljön producerar helt "self-contained" applikationer som inte beror på något annat än s.k. system-call APIet för OS:et.

Iperf3 är ett rätt typiskt C-program (som jag har erfarenhet av att porta till olika CPU-arch och RTOS:es). Full möjligt att få det att fungera på ASUS-routern, men är inte helt trivialt.

Goben är skrivet i Go. Enda jag behöver göra, oavsett om jag bygger på Linux, MacOS eller Windows, är att säga: jag vill ha en version av detta program för ARM 64-bitars + Linux -> ut hoppar en binär som bara är att ladda upp och köra, inga andra beroenden än binären själv!

Ovanpå det kan inte iperf3 använda mer än en CPU-tråd, det även om man kör multipla strömmar (men är självklart möjligt att köra flera instanser av iperf3, då kan man använda flera CPU-trådar). Goben är kapabel till detta, detta då Go:s runtime sprider automatiskt ut olika strömmar över flera CPU-trådar på ett lämpligt sätt.

Fattar fortfarande inte va WiFi 6 betyder, saknar de gamla med b/g/n/ac

Skickades från m.sweclockers.com

*Urspårning och otrevligheter raderat*

Kalla mig gammaldags, men speldatorn och Plex-servern kommer alltid vara hardwired.

Finns det uthållighetstester på nyare enheter? Jag har tidigare haft problem med överhettning i trådlösa enheter, där anslutningen kort kopplas ner och blir instabil ju längre man skyfflar data i hög hastighet. Sånt gör mig avig, även om jag vet att spel generellt genererar väldigt lite data i förhållande till annat.

@Shudnawz: Kabel är alltid kabel, och nu står 2.5G ethernet och väntar på tröskeln för oss vanliga dödliga också. Såklart, kan man köra kabel så bör man ju, helt klart.

Uthållighetstester.. Mja, nu är det ju rätt tunnt med 802.11ax / WIFI6 klientchip änsålänge, men det har då inte varit några problem att hålla upp 8 strömmar på totalt ~700+ mbit under 15min när jag testat med en Galaxy S10+ mot några olika AX-kapabla routrar/ap:s. Inga drops, ingen instabilitet, ingen överdriven värme. Nu ska det ju sägas att när jag testade detta var det på rätt kort avstånd med fri sikt.
Kan göra ett längre sustained test om det är av intresse. Kommer inte nämna vilka routrar/chipsets, kan säga om värmen är ett problem i någon av de som faktiskt finns på marknaden idag (men ser inte så ut vad jag sett hittills), kan uttala mig öppet om hur S10+ beter sig.

Har ax88 hemma och väntar på leverans av killer ax 1650 m.2 kort från amazon.com som vi skall byta ut det gamla killer 1435 i alienware 17r5 laptop. Vi kör mellan våningar med router i trappan så skall bli intressant att se prestandaökningen på tp-test, kanske bättre latens också?

Skickades från m.sweclockers.com

Skrivet av Shudnawz:

Kalla mig gammaldags, men speldatorn och Plex-servern kommer alltid vara hardwired.

Finns det uthållighetstester på nyare enheter? Jag har tidigare haft problem med överhettning i trådlösa enheter, där anslutningen kort kopplas ner och blir instabil ju längre man skyfflar data i hög hastighet. Sånt gör mig avig, även om jag vet att spel generellt genererar väldigt lite data i förhållande till annat.

Kan inte svara för RT-AX88U då jag inte långtidstestat den under hög last, men givet att enheten drar från väggen ~8 W i vila och 12-13 W när man skickar > 1 Gbit/s över luften kombinerat med storleken på enheten håller jag det för rätt osannolikt att det blir värmeproblem.

Knappast ett uthållighetstest, men testade maxad körning i båda riktningarna under 15 min mellan två accesspunkter och fanns inga tecken på överhettning eller instabilitet. Finns dock värre miljöer för Wi-Fi än den jag har hemma och är definitivt stabilitetsproblem i vissa miljöer, i alla fall över 2,4 GHz.

Har kört ComHems standardrouter med 802.11ac stöd (den vita med beteckning CH7486E) under någon dag utan problem. Gjort liknade manöver med en Ubiquiti Unifi AP-AC Lite (placerad i taket, så värmen kan inte enkelt ta sig uppåt). Laddat ner Xbox GamePass spel samt Steam-katalog till nya enheter, vilket i praktiken skyfflat ~100 Mbit/s över Wi-Fi under lång tid.

Jobbar väldigt mot maskiner som bara nås via SSH, det via Wi-Fi på min laptop. Alla former av instabilitet märks då direkt i form av att sessionerna klipps (sessioner som ofta hålls öppna hela arbetsdagen), har i princip aldrig upplevt det som ett problem (men självklart kör man tmux ändå då många saker måste leva åtskilliga dagar, men tmux är det trivialt att återuppta en session som ändå klipps).

Skulle gissa att i 99 fall av 100 så är eventuella värmeproblem något man råkar ut för i klienter, inte i accesspunkterna. Kan mycket väl tänka mig att t.ex. telefoner kommer throttla efter ett tag om man lastar deras Wi-Fi hårt.

Edit: det skrivet, Ethernet kommer självklart alltid ha högre kapacitet, har färre potentiella störningskällor etc.

Senast redigerat 2019-06-04 17:42
Skrivet av crion:

Har ax88 hemma och väntar på leverans av killer ax 1650 m.2 kort från amazon.com som vi skall byta ut det gamla killer 1435 i alienware 17r5 laptop. Vi kör mellan våningar med router i trappan så skall bli intressant att se prestandaökningen på tp-test, kanske bättre latens också?

Skickades från m.sweclockers.com

Latensen bör du helt klart märka skillnad på, samtliga chipsets jag testat har levererat tightare och mindre siffror än sina .11ac-föregångare, speciellt på mid/long range i halvtaskig radiomiljö.
Sure, inga mirakelsiffror, men mätbart helt klart. Vad gäller range så skulle jag säga att de flesta som kör 4x4 på 5ghz drar jämt med äldre generationer, inget direkt ballt på den fronten trots viss antydan från tillverkare. Ja och hastighet.. Eh.. Ja, hittills har jag mest sett ~10% högre throughput, give or take. Så standarden håller ju vad den "lovat". Men, och detta är det största men jag kan utdela: hittills har jag inte sett någon enhet som levererar bra på både OFDMA och MU-MIMO, tror det beror mest på eftersläpande optimering, blir nog bättre med tiden! Hursom är det just till de punkterna jag tycker man ska vända blicken, det är där WiFi6 blir intressant på riktigt.

Skrivet av jeffan97:

Fattar fortfarande inte va WiFi 6 betyder, saknar de gamla med b/g/n/ac

Skickades från m.sweclockers.com

Det betyder väl 802.11ax, mer eller mindre?
Är det inte ganska förvirrande (framförallt från konsumentsynpunkt) att ha standarder med suffixen a, b, c, d, e, f, ... aa, ab, ac, ad ... upp till be än så länge, när bara 7 av dem är "WiFi-versioner"? (802.11be är vad som sannolikt blir Wi-Fi 7 i framtiden.)

Ger man en slumpvalt människa infon att kommandes standarden heter 802.11ax och föregående 802.11ac, tror du de kan gissa att versionen innan det var 802.11n?

Skrivet av Thomas:

Det betyder väl 802.11ax, mer eller mindre?
Är det inte ganska förvirrande (framförallt från konsumentsynpunkt) att ha standarder med suffixen a, b, c, d, e, f, ... aa, ab, ac, ad ... upp till be än så länge, när bara 7 av dem är "WiFi-versioner"? (802.11be är vad som sannolikt blir Wi-Fi 7 i framtiden.)

Ger man en slumpvalt människa infon att kommandes standarden heter 802.11ax och föregående 802.11ac, tror du de kan gissa att versionen innan det var 802.11n?

Kasta in 802.11r, 802.11v och 802.11k i soppan så blire roligt på riktigt.. Jag tror wifi alliance kommer få ta fram en rejäl sil och verkligen reda ut begreppen så det går att prata med varandra oavsett om man jobbar med grejerna eller tänkt köpa dem..

Skickades från m.sweclockers.com

Skrivet av Yoshman:

Finns två stora fördelar med goben över iperf i just detta fall.

Ville köra även goben direkt på routern. Även om ASUS, likt de flesta hemma routers idag, kör en variant av Linux så är det ofta en utmaning att korskompilera applikationer på ett sätt så att de fungerar. Detta problem kommer av att det nästa allt finns dolda beroenden i binären som man måste få till

Men det är bara nästan! Saker som är skrivet i programspråket Go och kompileras med den standardmiljön producerar helt "self-contained" applikationer som inte beror på något annat än s.k. system-call APIet för OS:et.

Iperf3 är ett rätt typiskt C-program (som jag har erfarenhet av att porta till olika CPU-arch och RTOS:es). Full möjligt att få det att fungera på ASUS-routern, men är inte helt trivialt.

Goben är skrivet i Go. Enda jag behöver göra, oavsett om jag bygger på Linux, MacOS eller Windows, är att säga: jag vill ha en version av detta program för ARM 64-bitars + Linux -> ut hoppar en binär som bara är att ladda upp och köra, inga andra beroenden än binären själv!

Ovanpå det kan inte iperf3 använda mer än en CPU-tråd, det även om man kör multipla strömmar (men är självklart möjligt att köra flera instanser av iperf3, då kan man använda flera CPU-trådar). Goben är kapabel till detta, detta då Go:s runtime sprider automatiskt ut olika strömmar över flera CPU-trådar på ett lämpligt sätt.

Tala ur skägget nu Hur kör man goben på en ASUS-router? Ska man skicka upp en binär via busybox på något sätt? Det är ju inte direkt tal om att kompilera kod på den tänker jag så jag fattar att man ska exekvera den men hur och var är frågan

Skrivet av ZaInT:

Tala ur skägget nu Hur kör man goben på en ASUS-router? Ska man skicka upp en binär via busybox på något sätt? Det är ju inte direkt tal om att kompilera kod på den tänker jag så jag fattar att man ska exekvera den men hur och var är frågan

ASUS routers

Ninja-howto är

$ cd <work_dir> $ mkdir go $ export GOPATH=$PWD/go $ git clone https://github.com/udhos/goben $ cd goben $ GOOS=linux GOARCH=arm64 go install ./goben

Efter detta har du nu en ARM64 kompatibel version av goben i $GOPATH/bin/linux_arm64/goben

OBS: GOPATH får inte peka på goben-katalogen som git-clone skapade, ska alltid vara ett "out-of-tree" bygge.

Har ingen Windows-dator tillhands just nu, ovan får justeras på erforderligt sätt för att sätta miljövariablerna GOOS och GOARCH till linux resp arm64 innan "go install ./goben" körs.

Windows x86

Trevliga med go är är att man kan bygga till alla OS/CPU som stöds, oavsett vilken kombination man råkar sitta på för tillfället. Kan bygga för 32-bit Windows på min x86_64 Linux så här

$ GOOS=windows GOARCH=386 go install ./goben

Binären ligger sedan i $GOPATH/bin/windows_386/goben.exe

Windows x86_64

$ GOOS=windows GOARCH=x86_64 go install ./goben

Binären ligger sedan i $GOPATH/bin/windows_386/goben.exe

EdgeOS

För de som har EdgeRouter eller liknande från Ubiquiti så använder dessa en 32-bitars little-endian MIPS CPU. För att bygga för den gör man detta

$ GOOS=linux GOARCH=mipsle go install ./goben

Skrivet av PunKK:

Latensen bör du helt klart märka skillnad på, samtliga chipsets jag testat har levererat tightare och mindre siffror än sina .11ac-föregångare, speciellt på mid/long range i halvtaskig radiomiljö.
Sure, inga mirakelsiffror, men mätbart helt klart. Vad gäller range så skulle jag säga att de flesta som kör 4x4 på 5ghz drar jämt med äldre generationer, inget direkt ballt på den fronten trots viss antydan från tillverkare. Ja och hastighet.. Eh.. Ja, hittills har jag mest sett ~10% högre throughput, give or take. Så standarden håller ju vad den "lovat". Men, och detta är det största men jag kan utdela: hittills har jag inte sett någon enhet som levererar bra på både OFDMA och MU-MIMO, tror det beror mest på eftersläpande optimering, blir nog bättre med tiden! Hursom är det just till de punkterna jag tycker man ska vända blicken, det är där WiFi6 blir intressant på riktigt.

802.11ax / Wi-Fi 6 första vågen stödjer flera klienter m.h.a. OFDMA eller m.h.a MU-MIMO. Båda kommer kunna utnttjas först när produkter som implementerar "andra vågen" anländer.

Det stora lyftet på klientsidan på kort sikt verkar vara stöd för 160 MHz kanalbredd. Hur användbart det är i praktiken beror rätt mycket på om man befinner sig med relativt få andra nätverk i närhet eller inte.

Skrivet av Yoshman:

802.11ax / Wi-Fi 6 första vågen stödjer flera klienter m.h.a. OFDMA eller m.h.a MU-MIMO. Båda kommer kunna utnttjas först när produkter som implementerar "andra vågen" anländer.

Det stora lyftet på klientsidan på kort sikt verkar vara stöd för 160 MHz kanalbredd. Hur användbart det är i praktiken beror rätt mycket på om man befinner sig med relativt få andra nätverk i närhet eller inte.

Inte helt sant, låt mig säga att det finns "första vågen" chipsets från åtminstone två av de större tillverkarna som stödjer såväl MU-MIMO som OFDMA. Du får givetvis säga emot mig, men... Låt mig helt enkelt säga att det är så. Rätt säker då jag själv, hands on, testat detta. Jag har också tagit del av Plugfest-resultat.. Vad jag sade var helt enkelt att dessa chipsets inte, ännu, presterar fullt ut i båda dessa tekniker, och det är med väldigt stor sannolikhet enbart mjukvarurelaterat. Kan inte gå så mycket djupare in på saken än så.

160MHz fatchannel är rätt poänglöst än så länge om man inte råkar typ bo inuti en Faraday-bur.. Det kommer säkerligen också ge bättre resultat i långa loppet när optimeringar på mjukvarusidan kommit ikapp. Men i verkliga livet i en normalsmutsig radiomiljö är det vad jag hittills sett rätt "meh".

Skrivet av crion:

Har ax88 hemma och väntar på leverans av killer ax 1650 m.2 kort från amazon.com som vi skall byta ut det gamla killer 1435 i alienware 17r5 laptop. Vi kör mellan våningar med router i trappan så skall bli intressant att se prestandaökningen på tp-test, kanske bättre latens också?

Skickades från m.sweclockers.com

Så mina vänner, då kommer härmed tptest ulåtandet från wifi 6 uppgraderingen. router ax88 från trappan, laptop Alienware 17R5 från undervåningen som nu uppgraderats från Killer 1435 (qualcomm) till killer 1650 (intel). Intel defaultinställningar. Bredband är comhem coaxial 600mbit/50mbit.

Ser ut att vara nästan 2ms bättre latency och 200mbit snabbare (upp mot taket på bredbandet på 600mbit) med tp-test. NICE!

7 juni 2019, 11:05 – Stockholm
Com Hem (killer 1650 senaste intel 21.10 driver)
578.70 Mbit/s 50.18 Mbit/s 8.05 ms

7 juni 2019, 10:52 – Stockholm
Com Hem (killer 1650 tidigare intel 21.0x driver)
482.23 Mbit/s 51.46 Mbit/s 8.31 ms

7 juni 2019, 10:26 – Stockholm
Com Hem (killer 1435 (qualcomm))
404.56 Mbit/s 51.84 Mbit/s 9.80 ms

7 juni 2019, 10:25 – Stockholm
Com Hem (killer 1435 (qualcomm)
416.82 Mbit/s 51.05 Mbit/s 9.94 ms

Food for thought.

"Denna guide skapas i samarbete med ASUS Nordic"
"Tack vare sponsorskap och samarbeten kan SweClockers fortsätta erbjuda högkvalitativt innehåll utan kostnad för läsaren."

Höjer lite på ögonbrynet när man läser detta. Utan att gräva ner sig allt för mycket o få på foliehatten och så vidare. Men är man sponsrad av ett företag i artiklarna så tror jag man börjar gå en fin balansgång mellan att säga sanningen och vad man får för sponsorpängar. Även om det inte är så. Hur kan man som läsare veta? Food for thought....

Skrivet av Yoshman:

ASUS routers

Ninja-howto är

$ cd <work_dir> $ mkdir go $ export GOPATH=$PWD/go $ git clone https://github.com/udhos/goben $ cd goben $ GOOS=linux GOARCH=arm64 go install ./goben

Efter detta har du nu en ARM64 kompatibel version av goben i $GOPATH/bin/linux_arm64/goben

OBS: GOPATH får inte peka på goben-katalogen som git-clone skapade, ska alltid vara ett "out-of-tree" bygge.

Har ingen Windows-dator tillhands just nu, ovan får justeras på erforderligt sätt för att sätta miljövariablerna GOOS och GOARCH till linux resp arm64 innan "go install ./goben" körs.

Windows x86

Trevliga med go är är att man kan bygga till alla OS/CPU som stöds, oavsett vilken kombination man råkar sitta på för tillfället. Kan bygga för 32-bit Windows på min x86_64 Linux så här

$ GOOS=windows GOARCH=386 go install ./goben

Binären ligger sedan i $GOPATH/bin/windows_386/goben.exe

Windows x86_64

$ GOOS=windows GOARCH=x86_64 go install ./goben

Binären ligger sedan i $GOPATH/bin/windows_386/goben.exe

EdgeOS

För de som har EdgeRouter eller liknande från Ubiquiti så använder dessa en 32-bitars little-endian MIPS CPU. För att bygga för den gör man detta

$ GOOS=linux GOARCH=mipsle go install ./goben

Tack för den, men du förklarar fortfarande inte hur själva exekveringen går till.

Skrivet av ZaInT:

Tack för den, men du förklarar fortfarande inte hur själva exekveringen går till.

När du kompilerat flyttar du över binärfilen till enheten du vill köra den på och exekverar som vilket annat program som helst.