Een ware slachtpartij

Hoe verifieert Data TestLab de goede werking van de ProviderMonitor?
Hoe is het mogelijk dat het hardware probleem van de testrobot die Belgacom Skynet ADSL Go in zijn metingen benadeelde, zeven en een halve maand standhield voordat het ontdekt en gecorrigeerd werd? Controleren we de data van onze testrobots dan niet? Natuurlijk doen we dat wel. We hebben op het niveau van de testrobots zelf en op het niveau van de databaseserver die alle meetresultaten vergaart, verwerkt en opslaat, allerlei maatregelen draaien die de vergaarde data controleren en de goede werking van de testrobots en de software die daarop draait probeert te garanderen.
We hebben de mogelijke problemen die kunnen opduiken tijdens de dagdagelijkse werking van de testrobots van de ProviderMonitor zoveel mogelijk proberen te anticiperen en detectie- en correctiemaatregelen daarvoor geprogrammeerd. Als er echter een nieuw en tot dusver niet geanticipeerd probleem opduikt, moet dat natuurlijk handmatig vastgesteld en gecorrigeerd worden. Daarna kan eventueel een automatische bewakingsroutine bijgeprogrammeerd worden.
In dit geval leidde een manuele inspectie van de downloadcijfers van Belgacom Skynet niet tot argwaan: van test tot test, van dag tot dag en van week tot week zagen we immers maar één of twee seconden verschil en dat ligt perfect binnen de veiligheidsmarges van een downloadmeting. Als we na maanden nu terugkijken, valt natuurlijk wél op dat er een groot verschil is tussen de downloadmetingen van maart en die van oktober of november, maar tussentijdse controles lieten niet zo’n grote verschillen zien.

Wat voor detectie- en correctiemaatregelen bestaan er?
Op de testrobots zelf draait in eerste instantie een script dat de internetverbinding probeert te garanderen. Dit script draait continu in de achtergrond en kijkt of er nog een geldige internetverbinding is en of alle achtergrondprogramma’s en -diensten die nodig zijn voor de goede werking van de robot en zijn netwerkfunctionaliteit ook nog actief zijn. Indien niet, maakt het een logbestand aan, probeert aan de weet te komen wat de reden is van de onderbreking en noteert die reden in het logbestand. Ten slotte probeert het de onderbroken dienst te herstarten of de internetverbinding indien mogelijk te herstellen: dat laatste eerst via een reset van de tcp/ip-stack, maar zonodig ook via een reboot van de pc. Alleen als het script vaststelt dat de verbinding langs de kant van de provider verbroken werd, wacht het af totdat dat automatisch hersteld wordt.
Daarnaast is er sinds kort ook een controle op het breedbandprofiel. We hebben immers in het recente verleden een paar gevallen gekend waarbij providers het breedbandprofiel van een van onze testrobots onder onze neus door veranderden. Daardoor gaat de robot beter presteren zonder dat wij daar meteen een oorzaak van kunnen vinden. De nieuwe profielcontrole voert bij het begin van elke test een meting uit van de upstream- en downstreambandbreedte. Als die niet overeenkomen met het opgegeven breedbandprofiel, genereert het script een alarm. Zo’n alarm wordt via de databaseserver naar de beheerder van de ProviderMonitor gestuurd en die zal naar aanleiding van zo’n alarm controleren wat er gaande is.
Aan de kant van onze databaseserver draait een bewakingsscript dat kijkt of alle robots hun resultaten ingestuurd hebben. Gebeurt dat niet tijdig, dan gaat het script na of de robot nog bereikbaar is. Zo ja, probeert het de logbestanden van de robot en eventuele achtergebleven resultaatbestanden te downloaden. Indien dat allemaal niet lukt, gaat er een waarschuwing naar de beheerder van de ProviderMonitor opdat een mens het zou nakijken en corrigeren.
Als alle resultaten binnen zijn, worden die verwerkt. Tijdens dat verwerkingsproces wordt voor alle resultaten gecontroleerd of ze binnen het verwachtingspatroon liggen. Dat betekent, dat bijvoorbeeld een ftp-downloadmeting van een bestand van 100 MiB duidelijk niet binnen de seconde gebeurd kan zijn met een ADSL-profiel. Een resultaat moet binnen een verwachte minimum- en een verwachte maximumwaarde liggen. Zo niet, wordt een waarschuwing naar de beheerder van de ProviderMonitor gestuurd met het verzoek dit na te kijken. Indien alles in orde is, slaat het systeem de resultaten in een database op. Al deze maatregelen zouden de goede werking en de correctheid van de resultaten van de ProviderMonitor moeten garanderen. Dat neemt echter niet weg, dat er zich een probleem kan voordoen dat niet ontdekt wordt door een van de bewakingsroutines of door de regelmatige manuele inspecties en dus door de mazen van het net glipt. In zo’n geval van overmacht wordt zo’n probleem natuurlijk pas opgelost nadat het ontdekt is. Dan publiceren we uiteraard wel een rechtzetting als het probleem een invloed had op de doorgegeven testresultaten en proberen we een bewakingsscript te programmeren of aan te passen om te voorkomen dat ditzelfde probleem opnieuw zou optreden.

Resultaten van de ProviderMonitor sinds 12 november 2003
We hebben ook even een samenvatting gemaakt van de resultaten van de ProviderMonitor sinds 12 november 2003, dus nadat de slecht functionerende robot die Belgacom Skynet ADSL Go testte vervangen was. Je vindt deze resultaten en die van de andere providers voor dezelfde periode in deze deze Excel-tabel.
Houd in gedachten dat de resultaten van Belgacom Skynet gekleurd zijn door hun transparante ftp-caching die ze voorlopig alleen in Antwerpen toepassen, maar die zeer snel wel veralgemeend zal worden tot de rest van Vlaanderen. De resultaten van XS4All ADSL Go zijn in werkelijkheid die van een ADSL Plus lijn, maar dat helpt hen dus kennelijk nauwelijks, behalve bij de http-meting.