Simpele firmwarefix krikt snelheid zwaarbelaste wifi-routers op
Onderzoekers van de universiteit van North-Carolina hebben een oplossing gevonden voor inzakkende doorvoersnelheden op zwaarbelaste wifi-netwerken. Met een simpele firmwarefix is de doorvoersnelheid bij grote hoeveelheden gebruikers met 400 tot 700 procent te verbeteren.
Op zwaarbelaste wifi-routers neemt de doorvoersnelheid vaak af, doordat alle gebruikers en de router zelf over hetzelfde kanaal communiceren. Onderzoekers van de North Carolina State University zijn erin geslaagd om de doorsnelheid bij zwaardere belasting te verbeteren. De verbetering is softwarematig en zou daardoor makkelijk kunnen worden doorgevoerd op bestaande routers.
De fix, met de naam WiFox, zou bij 25 gelijktijdige gebruikers voor een 400 procent hogere doorvoersnelheid zorgen en bij 45 gebruikers voor een 700 procent hogere doorvoersnelheid. Gemiddeld zou een WiFox-netwerk vier keer beter presteren dan een 'normaal' netwerk. Preciezere cijfers, bijvoorbeeld de concrete winst in Mbps, worden niet genoemd.
De fix is eenvoudig; hij zorgt ervoor dat als de wifi-router een achterstand opbouwt van gegevens die moeten worden verzonden naar verbonden gebruikers, de gegevens die de router verzendt een hogere prioriteit krijgen. Dat gaat wel ten koste van de snelheid waarmee gebruikers gegevens kunnen verzenden. Welke impact dat heeft, is onduidelijk. Ook is onbekend hoe lang de router hogere prioriteit krijgt om gegevens te verzenden. Het volledige onderzoek wordt pas volgende maand bekendgemaakt, tijdens een conferentie in Frankrijk.
Reacties (32)
Interessante ontwikkelingen. Ik ben benieuwd of dit in de praktijk ook doorgevoerd zal worden op de nieuwe routers die op de markt zullen komen.
Wat nog belangrijker is: Komt er een firmware update voor bestaande routers?
(Kijk bijvoorbeeld naar de slechte firmware support van Sitecom voor mijn WL-309 Gaming Router II)
(Kijk bijvoorbeeld naar de slechte firmware support van Sitecom voor mijn WL-309 Gaming Router II)
[Reactie gewijzigd door fanSte op donderdag 15 november 2012 14:15]
Zolang je geen 25 tot 45 of meer concurrent users hebt op je router heb je er niet zoveel aan.
Lijkt me niet dat er 40 man draadloos op je gaming router zitten.
In de meeste gevallen helemaal niet interessant voor thuis routers behalve als je hem als een publieke hotspot gebruikt en dan zijn 40 man tegelijkertijd nog erg veel om uberhaupt voorelkaar te krijgen
Lijkt me niet dat er 40 man draadloos op je gaming router zitten.
In de meeste gevallen helemaal niet interessant voor thuis routers behalve als je hem als een publieke hotspot gebruikt en dan zijn 40 man tegelijkertijd nog erg veel om uberhaupt voorelkaar te krijgen
En toch zou het voor een gezin geen verkeerde ontwikkeling zijn; twee ouders met twee kinderen, twee - drie laptops, vier smartphones met wifi, een ipad, komt nog wat visite langs die graag wordfeud willen spelen, dan heb je al snel 10 - 15 apparaten op hetzelfde wifi netwerk.
Bij de meeste gezinnen is het zo dat als er gasten langskomen ze niet allemaal hun smartphone pakken om wordfeud te gaan spelen. Of tegelijk op alle devices tegelijk actief internet gaan gebruiken. 4 man betekend verassend vaak niet meer dan 4 heavy users (voor enkel pushmail op de tablets en phones ga je dit echt niet nodig hebben)
Dit is interessant voor wifi op campings.
Maar eigenlijk ook weer niet:
Maar eigenlijk ook weer niet:
van 1 KBps naar 4 tot 7 KBps was mijn eerste gedachte.bij grote hoeveelheden gebruikers met 400 tot 700 procent te verbeteren
Goh, bewijst dit niet meer dit reel negativisme?Preciezere cijfers, bijvoorbeeld de concrete winst in Mbps, worden niet genoemd.
je sarcasme ten spijt, heb je zeker wel een punt hier..
er zijn genoeg publieke hotspots waar deze problemen zich voordoen,
het signaal boosten werkt ook wel (tenkoste van je mede gebruikers), maar als er een betere fix is, zou dat zeker kunnen..
er zijn genoeg publieke hotspots waar deze problemen zich voordoen,
het signaal boosten werkt ook wel (tenkoste van je mede gebruikers), maar als er een betere fix is, zou dat zeker kunnen..
En hoe vaak komt dat voor? Hoe vaak zit iedereen tegelijkertijd met laptop, smartphone en tablet te werken? Ook leuk als er visite komt - nemen die dan ook ieder een laptop, telefoon en tablet mee, om vervolgens allemaal met alles tegelijk aan de slag te gaan? Gezellig! 
Kijk eens verder dan je eigen huis ;-) Er zijn genoeg omgevingen met meer gebruikers. Denk eens aan hotels, starbucks, evenementen en mcdonalds.
als ze door middel van het QoS'en van de upstream de verbinding snelheid weten te verbeteren, wat voor flaw zit er dan in de huidige 'loadbalancer' binnen een tcp/ip sessie.
als ze door middel van het QoS'en van de upstream de verbinding snelheid weten te verbeteren, wat voor flaw zit er dan in de huidige 'loadbalancer' binnen een tcp/ip sessie.
[Reactie gewijzigd door OptimusPrima op vrijdag 16 november 2012 00:33]
Ik gebruik het door Ziggo geleverde Cisco EPC3925 modem-router. De wifi funtionaliteit is weliswaar ondermaats; vandaar dat mijn hele netwerk ook bekabeld is met CAT6 / CAT7 SSTP kabels. al dat gesodemieter met gammele en vooral trage wifi netwerken was ik beu.
Binnen mijn netwerk haal ik snelheden van 35-45 MB per seconde, wat naar mijn mening erg netjes is.
Binnen mijn netwerk haal ik snelheden van 35-45 MB per seconde, wat naar mijn mening erg netjes is.
@ fanSte:
Het betreft ook een firmware fix dus de bedoeling is dat dit middels een firmware update wordt uitgerold.
Het betreft ook een firmware fix dus de bedoeling is dat dit middels een firmware update wordt uitgerold.
Dat is interessant nieuws...
Ben benieuwd hoe dat zich uiteindelijk vertaalt in transfer-speed verlies (Mbps), maar vooral ook latency.
Want als ik het goed begrepen heb, zal throughput (Mbps) naar beneden moeten om te realiseren, maar dan zal latency-getal beïnvloed worden... en dus ook overhead inderdaad
Maar exact hoe zal dan IxChariot tests moeten uitwijzen denk ik
EDIT: denk dat het idd een verdere evolutie is van RTS/CTS of CD/CSMA en/of QoS op ethernetgebied... en dat is lijkt mij idd een software-iets
cirkeltje weer rond haha
(kon het niet laten)
Ben benieuwd hoe dat zich uiteindelijk vertaalt in transfer-speed verlies (Mbps), maar vooral ook latency.
Want als ik het goed begrepen heb, zal throughput (Mbps) naar beneden moeten om te realiseren, maar dan zal latency-getal beïnvloed worden... en dus ook overhead inderdaad
Maar exact hoe zal dan IxChariot tests moeten uitwijzen denk ik
EDIT: denk dat het idd een verdere evolutie is van RTS/CTS of CD/CSMA en/of QoS op ethernetgebied... en dat is lijkt mij idd een software-iets
cirkeltje weer rond haha
(kon het niet laten)[Reactie gewijzigd door mindwarper op donderdag 15 november 2012 14:19]
Dus in andere woorden: ADSW. Dus niet L. Het idee achter ISP's: gebruik de beschikbare bandbreedte om down sneller te maken dan up. WiFi is inderdaad een "ethernet" techniek die door een 50/50 verdeling (of self-governing) van up/downstream half duplex is. Door die half-duplex eigenschap anders in te delen kan ik me dit wel voorstellen eigenlijk.
Als ik dit (lunch, mag even snel wat skimmen) even bekijk is dit een firmware fix die aan de feitelijke mbits niks doet. Waar je nu met een 150mbit router kunt zeggen: zelfs in het meest ideale geval haal je maximaal 75mbit down, kan je dan zeggen: je haalt maximaal 120mbit (maar je kunt slechts 30 uploaden). Erg handig, eigenlijk, zeker als het om publieke internet accesspoints gaat: waarom zou je de total upstream van alle gebruikers hoger maken dan die van de connectie op die plek?
Overigens zou de verdere overhead van WiFi, zoals extensieve error control mechanismes, ook aangepast kunnen worden. 150mbit is zelfs op de router zelf een verlies, niet alleen door het feit dat het half duplex is. Ook vanwege het feit dat draadloos gewoon moeilijker is. Als je dan met signaal verlies gaat spelen kan je rond 12mbit op een afstand na wat muren al eigenlijk niks bruikbaars meer hebben.
Als ik dit (lunch, mag even snel wat skimmen) even bekijk is dit een firmware fix die aan de feitelijke mbits niks doet. Waar je nu met een 150mbit router kunt zeggen: zelfs in het meest ideale geval haal je maximaal 75mbit down, kan je dan zeggen: je haalt maximaal 120mbit (maar je kunt slechts 30 uploaden). Erg handig, eigenlijk, zeker als het om publieke internet accesspoints gaat: waarom zou je de total upstream van alle gebruikers hoger maken dan die van de connectie op die plek?
Overigens zou de verdere overhead van WiFi, zoals extensieve error control mechanismes, ook aangepast kunnen worden. 150mbit is zelfs op de router zelf een verlies, niet alleen door het feit dat het half duplex is. Ook vanwege het feit dat draadloos gewoon moeilijker is. Als je dan met signaal verlies gaat spelen kan je rond 12mbit op een afstand na wat muren al eigenlijk niks bruikbaars meer hebben.
Als ik 't -- ook snel -- goed begrijp is 't niet zozeer het asymmetrisch maken van de verbinding, maar meer het QoS'en van de upstream (aan de kant van het access point.) Bij weinig verkeer kun je nog steeds je volledige upstream (client-kant) volpompen.
in de tekst lees ik 400-700% winst inprestatie.
in de uitleg lees ik vertraging, minder prioriteit en minder bandbreedte.
die 2 dingen lijken mij contradictorisch.
Al bij al geld dat waarschijnlijk enkel bij druk verkeer en valt het beter te vergelijken met blokrijden.
in de uitleg lees ik vertraging, minder prioriteit en minder bandbreedte.
die 2 dingen lijken mij contradictorisch.
Al bij al geld dat waarschijnlijk enkel bij druk verkeer en valt het beter te vergelijken met blokrijden.
In eerste instantie dacht ik dat ook, maar ik denk doordat er dus met overhead en RTS/CTS en/of QoS waardes dynamisch omgesprongen wordt om dat te realiseren.
Als je dan totaal-plaatje voor ogen houdt, zou het zo maar kunnen dat er prestatiewinst gehaald kan worden, omdat gemiddeld per tijdseenheid dan meer gegevens ontvangen/verzonden kunnen worden zij het dan tegen een lagere snelheid.
Dus meer pakketjes verzonden/ontvangen in totaal en daar gaat het uiteindelijk om, is het niet?
Als je dan totaal-plaatje voor ogen houdt, zou het zo maar kunnen dat er prestatiewinst gehaald kan worden, omdat gemiddeld per tijdseenheid dan meer gegevens ontvangen/verzonden kunnen worden zij het dan tegen een lagere snelheid.
Dus meer pakketjes verzonden/ontvangen in totaal en daar gaat het uiteindelijk om, is het niet?
De winstpercentages hebben geen direct verband.
400% winst is bij 25 gebruikers, de 100% is dan de doorvoersnelheid bij DAT aantal gebruikers.
700% winst bij 45 gebruikers, de 100% is dan de doorvoersnelheid bij dat hogere aantal gebruikers.
In de titel van het bericht lees je waarschijnlijk onbewust "absolute snelheid", dit is echter "relatieve snelheid".
400% winst is bij 25 gebruikers, de 100% is dan de doorvoersnelheid bij DAT aantal gebruikers.
700% winst bij 45 gebruikers, de 100% is dan de doorvoersnelheid bij dat hogere aantal gebruikers.
In de titel van het bericht lees je waarschijnlijk onbewust "absolute snelheid", dit is echter "relatieve snelheid".
is dat dan niet wat ik bedoel 
?
idd relatieve snelheid door dynamisch met waardes om te gaan (door firmware) om te voldoen wat er geschetst wordt door het artikel en wat jij hier schrijft?
?idd relatieve snelheid door dynamisch met waardes om te gaan (door firmware) om te voldoen wat er geschetst wordt door het artikel en wat jij hier schrijft?
Ik lees ook winst in snelheid, maar vertraging in het verzenden inderdaad.
Wil dit niet zeggen dat men een hogere ping heeft?
Zoals de artikel het beschrijft, wordt men in een wachtrij gezet (lees: je krijgt hogere ping) om vervolgens je gegevens sneller te krijgen. Dit is dan meer selectief gegevens sneller verzenden heb ik dit goed?
Wil dit niet zeggen dat men een hogere ping heeft?
Zoals de artikel het beschrijft, wordt men in een wachtrij gezet (lees: je krijgt hogere ping) om vervolgens je gegevens sneller te krijgen. Dit is dan meer selectief gegevens sneller verzenden heb ik dit goed?
dat klopt latency dus hoger, wat jij en ik dus ook bedoelen
helemaal correct gedacht, maar ik denk dat prioritisering van datapakketjes (lees o.a. QoS, WMM, etc..) ook een significante rol in zal gaan spelen als ik het stukje tekst goed geïnterpreteerd heb.
alleen afwachten hoe het zich dus vertaalt in de praktijk
helemaal correct gedacht, maar ik denk dat prioritisering van datapakketjes (lees o.a. QoS, WMM, etc..) ook een significante rol in zal gaan spelen als ik het stukje tekst goed geïnterpreteerd heb.
alleen afwachten hoe het zich dus vertaalt in de praktijk
de vraag is of je netto wel zoveel slechter af bent, het artiekel suggereerd immers het tegendeel, ... dat komt omdat bij wifi packet loss en veel grotere invloed heeft dan bandbreedte.
een rekenvoorbeeldje: op een 100packet lijntje, als je 20% packet los hebt op 90% van je bandbreedte cap, dan praat je dus over 18 verloren packets, en dus heb je dus 72packets.
nu ga je op 80% zitten, met maar 5% verlies, kom je op 76 packets.. is al een winst van bijna 5%
een rekenvoorbeeldje: op een 100packet lijntje, als je 20% packet los hebt op 90% van je bandbreedte cap, dan praat je dus over 18 verloren packets, en dus heb je dus 72packets.
nu ga je op 80% zitten, met maar 5% verlies, kom je op 76 packets.. is al een winst van bijna 5%
we hadden toch al de oplossing: IEEE_802.11ac?
dat is idd deel van de oplossing denk ik
Super handig voor scholen dus! Die hebben vaak veel gebruikers op dezelfde AP's en kunnen maar moeilijk in een LAN netwerk voorzien omdat de gebruikers voortdurend verplaatsen.
Grootste probleem is én blijft: te weinig bandbreedte / kanalen op 2.4GHz en teveel mensen die er gebruik van maken met een veel te brede bandbreedte...
dit zou nog best interessant kunnen zijn voor ziggo.
Klinkt als een vreemd idee. Je haalt dus in principe het on-demand idee weg en laat de router dicteren wanneer er wordt verzonden en wanneer er wordt ontvangen, zorgt dit niet voor time-outs als de achterstand dusdanig groot wordt dat de gebruiker niets, tot weinig, meer kan verzenden?
Lijkt mij dat dit onder bepaalde omstandigheden goed kan werken maar het kan volgens mij ook onder andere omstandigheden averechts werken.
Ik ben student Game Technology dus van netwerken weet ik weinig tot niets, dit is enkel mijn blik op deze "fix",
Lijkt mij dat dit onder bepaalde omstandigheden goed kan werken maar het kan volgens mij ook onder andere omstandigheden averechts werken.
Ik ben student Game Technology dus van netwerken weet ik weinig tot niets, dit is enkel mijn blik op deze "fix",
Dat doet 'ie sowieso. Anders zou 't een teringbende worden in de ether.Klinkt als een vreemd idee. Je haalt dus in principe het on-demand idee weg en laat de router dicteren wanneer er wordt verzonden en wanneer er wordt ontvangen
Het netwerk idee van IBM, (ooit eens, vorige eeuw), dat TOKENRING werd genoemd werkte onder hogere belasting altijd al veel beter dan het ethernet CSMA/CD. Maar het was veel duurder. Duurder dan b.v. 10 ethernet segmenten.
Bij meer dan 40% belasting is CSMA/CD niet meer efficiënt. Een algoritme om aan te geven wanneer wie iets mag zeggen is dan een oplossing.
Wat me hier ontgaat is hoe je dat zou kunnen implementeren als een software fix aan de kant vd AP. Volgens mij kan het alleen werken als beide kanten, dus ook de clients zich houden aan het protocol.
Zonder client software update zal dat niet gebeuren.
Ik heb hier ook al eens iets gelezen over full-duplex waar een AP en een client beide tegelijk kunnen zenden, door dat ze hun eigen signaal van het ontvangen signaal aftrekken om zo het signaal van de andere kant over te houden.
Een combi van deze technieken zou idd een flinke performance winst kunnen opleveren.
Maar de leveranciers zullen liever een nieuw kastje verkopen dan een software fix geven.
Bij meer dan 40% belasting is CSMA/CD niet meer efficiënt. Een algoritme om aan te geven wanneer wie iets mag zeggen is dan een oplossing.
Wat me hier ontgaat is hoe je dat zou kunnen implementeren als een software fix aan de kant vd AP. Volgens mij kan het alleen werken als beide kanten, dus ook de clients zich houden aan het protocol.
Zonder client software update zal dat niet gebeuren.
Ik heb hier ook al eens iets gelezen over full-duplex waar een AP en een client beide tegelijk kunnen zenden, door dat ze hun eigen signaal van het ontvangen signaal aftrekken om zo het signaal van de andere kant over te houden.
Een combi van deze technieken zou idd een flinke performance winst kunnen opleveren.
Maar de leveranciers zullen liever een nieuw kastje verkopen dan een software fix geven.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Asus Samsung Mobiele telefoons Laptops Apple Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
