Kuinka testasimme

Toteamme heti alkuun, ettemme käyttäneet dd-wrt (www.dd-wrt.com) tai muitakaan modauksia näissä reitittimissä. Testausmetodologiaa päätettäessä on aina tehtävä päätöksiä, ja päätimme lopulta että suurin osa käyttäjistä luultavati haluaa takuullisen tuotteen jota käytetään valmistajan suositusten puutteissa. Tämä tarkoitti valmistajan viimeisimmän firmwaren käyttöä testattaessa. Joissain tapauksissa olisimme saaneet nopeampia tuloksia dd-wrt:llä ja ehkäpä siitä saisi mielenkiintoisen tutkimuksen jollekin toiselle päivälle. Tällä kertaa menemme valmistajien rajoituksien sisällä.
Samoista syistä vaadimme valmistajien tarjoavan meille "vastaavan" asiakasadapterin. Emme halunneet saada jälkeenpäin syytöksiä kuten "No meidän reitittimellä on ongelmia adapteri XYZn kanssa" tai muuta vastaavaa. Teoriassa jos valmistaja tarjoaa reitittimen ja vastaanottimen tämän pitäisi tarjota varmaa yhteensopivuutta ja optimointia. Näin siis suunnittelimme testimme. Harmi vain, ettei kaikki aina mene tosielämässä putkeen.

Testasimme kolmessa eri paikassa pohjakerroksen ruokasalissa kaksikerroksiessa vajaan 75 neliömetrin kokoisessa talossa keskellä Oregonin "SiliconForest" -aluetta. Naapureista siis löytyi työntekijöitä Intel, Radisys, Tektronix, IDT, ja monesta muusta teknologiayrityksestä joista nähtävästi kaikki pitivät ainakin yhtä kotiverkkoa. Pitkin viikon pituista testausperiodia ei ollut kertaakaan kun kilpailevia verkkoja yli 60% kuuluvuudella oli alle kymmenen, ja nämä olivat vain ne jotka näimme.
Käytimme kahta kannettavaa testaukseen: HP Compaq nc8000 palvelimena ja Dell Latitude E6400 asiakkaana. Sijainti 1 oli noin kolme metriä palvelimesta, ruokapöydän toisella laidalla. Sijainti 2 oli seinän takana noin 20 metrin päässä. Sijainti 3 oli yläkerrassa useamman esteen takana noin 15 metrin etäisyydellä.

Meillä oli useita huolia testatessamme. Halusimme tiukkoja tuloksia jatkuvalta suoritusteholta TCP:lle ja UDP:lle, joten aloitimme 1GB kansiolla ja mittasimme siirtoajan palvelimmelle ja palvelimelta joka oli Ethernetillä liitetty reitittimeen. Teimme tämän itse asiassa kahdesti, ensin kansiolla jossa oli kasoittain pieniä järjestelmä- ja mediatiedostoja, missä ylimääräistä overheadia jota tulee kansion siirrossa, ja sitten yksittäisellä 1,00GB ZIP-tiedostolla. 1GB kansio on kohtuullisen iso langattomassa skenaariossa, mutta mielestämme jumbokoko oli tärkeää poikkeumien tasoittamiseksi, esimerkiksi naapurin mikron takia. Muunsimme tulokset MB/s lukemiksi.

Seuraavaksi toimme Ruckus Wireless Zap komentorivitestaustyökalun joka on nähty muutamassa Tom's Hardwaren aikaisemmassa artikkelissa, ja käytimme sitä johtaeksemme keskimääräisen suoritustehon TCP ja UDP-datalle. Kuitenkin koska jotkut lukijat kyseenalaistavat Ruckusin valmistaman työkalun käyttöä sen omaan tuotteeseen me kiersimme tämän Advanced Networking Testillä PassMarkin PerformanceTest suitessa mikä on loistava testikokoelma joka ansaitsee enemmän huomiota kuin mitä se saa.

Kaikki reitittimet ja adapterit oli päivitetty viimeisimmällä firmwarella ja ajureilla ennen testausta. Samoin kaikki reitittimet oli asetettu maksimaaliselle kanavanleveydelle.
Kiinnostuneille ohjelmoijille loimme käsintehdyn rutiinin automatisoimaan joidenkin testien ajon, sillä jokainen läpiajo yhdessä paikassa kesti noin neljä tuntia. Tässä on diagrammi jota käytimme luodessamme testisettiä.