Mätdata från Bredbandskollen

Bredbandskollen är ett konsumentverktyg för mätning av bredbandsprestanda som tillhandahålls av .SE. Tjänsten finns i en plattformsoberoende version för webblä- sare samt i skrivande stund för de två mobila operativsystemen iOS och Android. I examensarbetet beaktas uteslutande webbläsarversionen, och det är denna som avses när vi använder namnet Bredbandskollen. Verktyget lanserades officiellt i oktober 2007 och är fritt att använda i hela världen och oavsett operatör, dock under förutsättning att åtkomst inte hindras från operatören själv eller från exem- pelvis myndigheter. Ett test i Bredbandskollen mäter användarens svarstid samt genomströmningshastigheten upp- och nedströms genom en Flash-applikation. För en detaljerad beskrivning av mätförfarandet se bilaga E.1 på sidan 274.

Stommen i det statistiska underlaget för examensarbetet är rådata från samtliga mätningar med Bredbandskollen från maj 2007 till början av januari 2011, to- talt 37,5 miljoner1_{. Storleken på den okomprimerade datamängden är ungefär 16} GB, och drygt det dubbla när informationen har indexerats. Komprimerat med standarderna tar och gzip är storleken strax under 3 GB.

Mot bakgrund av att vi under projekttiden inte har haft tillgång till en så kallad superdator eller ett datorkluster, med förmågan att hålla all information i arbets-

minnet, har vi uppskattat den genomsnittliga tiden för en förfrågan till ungefär 20 minuter2, vilket visade sig stämma väl överens med utfallet i projektets slutskede. Arbetet har således fått planeras noga för att få ut önskvärd information inom rimlig tidsram, och begränsningen i kapacitet har stundtals varit ett hinder för djupgående detaljstudier.

Databasval

Bredbandskollens rådata hanteras i MySQL-form, vilket är en vanlig databas för webbapplikationer. LAMP, som innefattar MySQL, är den mest vedertagna pake- tet av programvarusviter för webbsidor, och har uteslutande öppen källkod (Cow- nie, 2011). MySQL saknar emellertid ett lämpligt API för högnivåprogrammerings- språk, varför vi valde att konvertera hela datamängden till MongoDB, en nyare och i detta sammanhang mer lättarbetad databas. Eftersom arbetet bedrevs på olika plattformar3 _{valdes Java som primärt programmeringsspråk för att aggre-} gera datat (se nästa rubrik). Java är plattformsoberoende och körs på en virtuell maskin, vilket innebär att alla program som skrivits utan problem har kunnat flyttas mellan våra arbetsdatorer.

Det bör noteras att MongoDB saknar applikationer för att utforska data på ett lika enkelt sätt som många existerande MySQL-verktyg. Detta uppvägs emellertid av att den aktuella datamängden på grund av sin storlek ändå inte hade kunnat presenteras på konventionellt sätt, till exempel med hjälp av tabeller.

Aggregeringar av data

För att kunna hantera den stora datamängden har vi varit mer eller mindre tvung- na att utföra olika slags aggregeringar innan datat har analyserats. På detta sätt kunde vi få en överblick av innehållet och hitta intressanta områden för mer djup- gående analyser. Aggregeringar utfördes med avseende på position (longitud/lati- tud), tid (dagar, veckor, månader), hash-nyckel samt val av tjänst.

Eftersom de övergripande analyserna baseras på aggregerade datamängder finns risken att förbise väsentliga detaljer som inte syns på den nivån. För att undvika detta togs också ett stickprov på 10 000 hash-nycklar, nästan jämförbart med unika

2_{En enklare fråga av typen “hur många mätningar utfördes den 24 april med tjänsten 100} Mbit/s fiber?”. Avancerade ingrepp såsom aggregeringar tar betydligt mer tid i anspråk och mäts enklast i dagar.

användare men mer korrekt vore att tala om unika datorer, för vilka genomförda mätningar granskades mer ingående.

ArcGIS och Windows

För att överblicka datat användes programvarusviten ArcGIS, som gav möjlighet att plotta informationen geografiskt. Den version av verktyget som fanns tillgäng- lig kunde bara köras i 32-bitars Windows (XP eller senare). Detta innebar en minnesbegränsning som blev kännbar på grund av de stora datamängderna som hanterades, och eftersom arbetet endast kunde utföras på den fysiska arbetsplat- sen valde vi att minska användningen av verktyget i analytiska syften mot vad som usprungligen hade planerats. Detta har haft som effekt att det tog längre tid att hitta intressanta orter att undersöka, men vi anser inte att kvalitén hos analyserna i sig har påverkats vare sig positivt eller negativt.

Programmet krävde att datat gjordes om till tabbavgränsat textformat för att kunna bearbetas. Det innebar att vi fick exportera från MongoDB till csv-format, och därefter konvertera till Windows-formaterad text (txt) med hjälp av Micro- soft Excel. Den initiala exporten från MongoDB gav upphov till dataförluster om några tusen poster på grund av felaktig fältavgränsning, men eftersom förlusterna aldrig översteg en (1) procent av den aktuella datamängden bedöms dessa inte ha påverkat den geografiska representationens korrekthet. Några mönster bland dataförlusterna har inte kunnat observeras i stickprovet, varför vi förutsätter att bortfallet har varit slumpmässigt.

Kompletterande källor från Bredbandskollen

Utöver rådatat från mätningarna har vi under arbetet haft tillgång till resultaten från en webbaserad undersökning som varit aktiv sedan december 2007. Ungefär en på 50 unika besökare4 _{till Bredbandskollens hemsida har blivit tillfrågad om} deltagande. Någon särskild kontroll av urvalet har således ej varit möjlig, men vi har funnit resultaten användbara för att ge belägg för eller avfärda några av våra antaganden utifrån datat. Uppgifter från undersökningen baseras på 64 802 svar. Frågorna som används i enkäten liksom svarsfrekvens återfinns i bilaga E.2.

Vi har även haft insyn i samtliga ärenden till Bredbandskollens support, som funnits sedan verktyget lanserades. Supporten är uteslutande e-postbaserad och

4_{Att en person har deltagit lagras i en lokal cookie (se avsnitt 1.5). Så länge cookien finns} kvar kan personen inte delta igen med samma dator och webbläsare.

hanterar uppskattningsvis cirka 30 ärenden per vecka. De flesta frågorna kommer från användare som inte är nöjda med sina mätresultat och vill ha hjälp med att förbättra dessa. Liksom resultaten i undersökningen har studier av inkomna ärenden kunnat ge belägg för eller hjälpt oss att avfärda vissa antaganden från vår sida. Detta gäller exempelvis vilka lokala begränsningar som kan finnas hos användare (avsnitt 3.2) eller vilka steg som en användare normalt vidtar vid låga uppmätta prestanda (avsnitt 3.3).