Arm is energiezuinig en tegenwoordig ook krachtig genoeg om de concurrentie met X86 aan te kunnen in een tradtioneel Intel-domein als embedded computers. Een rondgang langs leveranciers leert echter...
Nu politici en beleidsmakers hun aandacht hebben gericht op het oplossen van de crisis en de naderende megabezuinigingen schuift het...
Als het van de initiatiefnemers van het Greentouch-consortium afhangt (www.greentouch.org), zullen we binnen tien jaar duizend keer energie-efficiënter kunnen ‘surfen’. Een mooie maar noodzakelijke...
8 mei 2009
De algemene beschikbaarheid van snelle Ethernet-verbindingen nodigt uit tot allerlei nieuwe toepassingen waar de technologie oorspronkelijk niet voor is ontworpen. Met het gebruik van bestaande netwerkinfrastructuren zijn grote kostenbesparingen te bereiken. Antoine Hermans en Henri Faber van Adeas delen hun ervaringen.
Met de opkomst van snelle netwerkverbindingen zoals Gigabit Ethernet is het nu mogelijk om snelle realtime datastromen gebruik te laten maken van goedkope standaard netwerkcomponenten in plaats van dure dedicated verbindingen. Vanwege de alomtegenwoordigheid van Ethernet-netwerken is er een trend om allerlei apparatuur onderling met Ethernet te verbinden. Er zitten echter haken en ogen aan het gebruik voor het verspreiden van snelle realtime datastromen. Omdat de technologie is ontwikkeld voor het transport van niet-tijdkritische data zijn de eigenschappen totaal anders dan die voor een realtime applicatie gewenst zijn. Waar bijvoorbeeld digitale video een continue stroom is met een constante snelheid, is Ethernet een pakketgebaseerd medium waarvan het gedrag over tijd nogal kan verschillen.
Een Ethernet-netwerk bestaat uit een aantal knooppunten die onderling met elkaar zijn verbonden. Niet elk knooppunt heeft een directe verbinding met alle andere. Om data van het ene punt naar het andere te sturen, moet het door een aantal andere knopen worden gerouteerd. Het is mogelijk dat er tussen twee punten meerdere routes bestaan. De tijd die een pakket nodig heeft om van de zender naar de ontvanger te komen, is afhankelijk van de gekozen route door het netwerk. Ook de hoeveelheid ander verkeer dat gebruikmaakt van (een deel van) dezelfde route beďnvloedt onze datastroom. Bij drukke lijnen kan het zo zijn dat datapakketten af en toe op elkaar moeten wachten. Ook is het mogelijk dat een datapakket helemaal niet meer aankomt. Dit kan gebeuren door externe invloeden zoals een elektriciteitsontlading bij bliksem in de omgeving van de kabel of door interne factoren zoals overbelasting van het netwerk.
Door de aanwezigheid van de knooppunten en andere datastromen is het gedrag van Ethernet niet deterministisch. Dataverkeer dat met een constante snelheid het netwerk ingaat, komt bij de ontvanger aan met een variërende snelheid. Deze door het netwerk veroorzaakte afwijking noemen we netwerkjitter.
Adeas ontwikkelde een over Ethernet gevoede converter die DVB-ASI-video omzet naar video over Ethernet.
Omdat Ethernet is ontwikkeld om een mix van verschillende data te transporteren, zijn er diverse protocollen die voor de verschillende gegevens worden gebruikt. Het is van groot belang om het juiste protocol te kiezen, dat past bij de data die we willen verzenden. De criteria hiervoor zijn onder meer het realtime gedrag van het protocol en de omgang met pakketverlies.
Er zijn binnen Ethernet twee basisprotocollen waar bijna alle andere op zijn gebaseerd: TCP en UDP. Het TCP-protocol heeft een ingebouwd mechanisme dat het verlies van pakketten onderweg kan oplossen: de ontvanger stuurt voor elk pakket een ontvangstbevestiging terug naar de zender. Wanneer deze bevestiging ontbreekt voor een pakket, stuurt de zender het pakket gewoon nog een keer. Het UDP-protocol heeft geen mechanisme om het ontbreken van pakketten te ontdekken.
Je zou nu kunnen denken dat TCP het meest geschikt is voor het versturen van een datastroom, maar dat is niet altijd waar. De foutcorrigerende eigenschap van het protocol veroorzaakt juist een aantal andere problemen. Bij hoge bitrates is er namelijk veel geheugen nodig om pakketten op te slaan waarvoor nog geen ontvangstbevestiging is teruggekomen. Ook de ontvanger heeft een grote buffer nodig om te kunnen wachten tot het vermiste pakket eindelijk is gearriveerd. De tijd tussen het oorspronkelijk versturen van een pakket en het aankomen van het opnieuw gestuurde pakket kan oplopen tot meer dan een halve seconde. Bij het bekijken van webpagina’s is het niet erg vervelend als we af en toe een halve seconde langer moeten wachten voordat de pagina zichtbaar is. Voor interactieve televisie, zoals een live interview, is er echter een maximaal tijdsverschil tussen de studio en de televisiekijker nodig van minder dan 200 ms. Bij grotere vertragingen is het voeren van een gesprek bijna onmogelijk. Wachten op missende data is hier duidelijk geen optie omdat een videostroom door moet blijven lopen. De vertraging mag niet te groot worden en moet constant zijn.
Als we een systeem ontwikkelen waarbij (video)datastromen realtime en met hoge snelheid over Ethernet moeten worden getransporteerd, komen we voor een aantal uitdagingen te staan. Het netwerk heeft immers tal van eigenschappen die op het eerste gezicht niet gepaard gaan met snelle realtime informatieoverdracht. Het eerste en meest evidente aspect is de bandbreedte. Natuurlijk moeten alle noodzakelijke data op nominale snelheid kunnen worden getransporteerd. Maar als een switch of een andere netwerkcomponent de data tijdelijk tegenhoudt - en dus opslaat - omdat een ander pakket voorrang krijgt, zal deze tijdsvertraging weer moeten worden ingelopen. Dit kan met de maximale netwerksnelheid gebeuren. De ontvangende kant moet de data met deze snelheid kunnen opvangen. Voor een gigabitnetwerk betekent dit dat het ingangsdatapad minimaal 1 Gbit/s moet aankunnen, ook al is de nominale datarate bijvoorbeeld maar 270 Mbit/s.
De gewenste data kan in een FPGA worden gefilterd van de ongewenste en naar verschillende verwerkingseenheden worden gestuurd. Je kunt die filter zien als soort firewall: alleen gewenste informatie komt er doorheen. De ongewenste pakketten nemen dan weliswaar geen processingtijd in beslag, maar als de gewenste pakketten aaneengesloten binnenkomen, zullen deze toch moeten worden opgevangen om dataverlies te voorkomen. Dit kan eenvoudig door de data in een snel geheugen zoals DDR2 te schrijven. Moeilijker is het om er in een realtime omgeving voor te zorgen dat de buffer nooit leeg of vol raakt; achter de buffer moet de data met een constante bitrate door kunnen blijven lopen.
Het is noodzakelijk om een algoritme te ontwikkelen om de snelheid en timing van uitlezen te bepalen. Afhankelijk van de toepassing is dit geen sinecure. Stel dat een videostandaard een timingnauwkeurigheid vereist van beter dan 100 ns. Dat wil zeggen dat het tijdstip waarop de data verder wordt verwerkt, op 100 ns accuraat moet zijn. Als je bedenkt dat de Ethernet-pakketten met een netwerkjitter van 100 ms binnen kunnen komen, is het duidelijk dat simpel uitmiddelen niet werkbaar is. Dit zou een filter opleveren met een erg lange looptijd.
De grootte van de inputbuffer is niet eenduidig te kiezen. We moeten een afweging maken tussen maximaal op te vangen onderbrekingen (jitter) en delay. Een grote buffer kan weliswaar veel jitter opvangen, maar zorgt inherent ook voor veel signaalvertraging.
Omdat de dataoverdracht via Ethernet niet gegarandeerd ‘verliesvrij’ is, moeten we rekening houden met pakketverlies. Afhankelijk van het gekozen protocol kan het ontbreken van pakketten worden gedetecteerd. Alle verdere algoritmes en verwerking kunnen hier dan rekening mee houden. Vaak is het echter niet eenvoudig om het verlies exact en snel te detecteren. Algoritmes zullen dit mee moeten nemen, zonder er heftig op te reageren. De ‘vervolgschade’ moet beperkt blijven. Een compleet videoframe laten vallen of dupliceren is voor een gebruiker meestal niet zichtbaar, maar het ontbreken van een stel audiosamples is funest.
Beter is het natuurlijk om ervoor te zorgen dat we verloren pakketten weer kunnen reconstrueren. Voor dit doel kunnen we forward error correction (Fec) gebruiken. De zender stuurt naast de inhoudelijke datapakketten ook Fec-pakketten. Hiermee kan de ontvanger een of meerdere verloren datapakketten reconstrueren. Dit wordt regelmatig toegepast bij het overzenden van videostromen. Het realtime genereren van Fec-pakketten of het reconstrueren van datapakketten vergt een snelle processing. We implementeren dit in een FPGA, omdat die het meestal sneller en efficiënter kan dan een microprocessor.
Tijdens de ontwikkeling van de systeemarchitectuur moeten we het hele systeem doorrekenen om te controleren of alle afzonderlijke processingunits de gewenste performance halen. In veel gevallen is een microprocessor een bottleneck, omdat de overhead die gepaard gaat met sommige protocollen voor een microprocessor tijdsintensief is. De kracht van een FPGA-gebaseerd systeem is dat we die overhead hierin geheel of gedeeltelijk kunnen onderbrengen. Je moet dan denken aan de berekening van checksums of het opzetten en onderhouden van een complete TCP-verbinding. Deze techniek heet offloading.
In realtime systemen kan het voorkomen dat de ontvanger qua tijd of frequentie aan de zender moet worden gelockt. Denk maar aan het apart routen en afhandelen van audio- en video-informatie waarbij het essentieel is dat beeld en geluid gesynchroniseerd blijven (lip sync). Het kan ook van belang zijn dat een oscillator aan de kant van de ontvanger exact dezelfde frequentie heeft als aan de zenderzijde. Dit is te realiseren door gebruik te maken van het Precision Time Protocol (PTP), ofwel IEEE 1588. Hiermee is het mogelijk om verschillende Ethernet-ontvangers gelijk te laten lopen tot op tien nanoseconden nauwkeurig. Daar er nog niet veel hardwarecomponenten beschikbaar zijn voor dit doel, implementeren we dit protocol ook in de FPGA - het tijdcruciale deel in hardware en de control- en protocolafhandeling in software.
Het vooroplopen in de techniek kan betekenen dat sommige mechanismen of methodes nog niet officieel in een standaard zijn vastgelegd. In zo’n geval gaan we dan van start met de ontwikkeling en houden we bij de keuze van de FPGA rekening met een uitbreiding of aanpassing van het systeem. Samen met de implementatie van een remote upgrademogelijkheid via Ethernet zorgt dit ervoor dat we in staat zijn toekomstige aanpassingen in standaarden door te voeren.
Concluderend kunnen we vaststellen dat er veel komt kijken bij het opzetten van de architectuur voor Ethernet-communicatie. Er zijn veel keuzes te maken die van invloed zijn op de performance en kwaliteit van het eindproduct. Bovenstaand verhaal licht een tipje van de sluier op, maar is zeker niet compleet. Een gedegen vooronderzoek voorafgaand aan de ontwikkeling en betrokkenheid van ervaren specialisten zijn van groot belang voor het succesvol afronden van het project.
Antoine Hermans en Henri Faber zijn respectievelijk technisch directeur en senior designer bij Adeas. Dit projectbureau werkt onder meer aan geavanceerde FPGA-gebaseerde systemen voor het transport van digitale video over Ethernet-netwerken.
© Bits & Chips | Deze pagina op internet: http://www.bits-chips.nl/nc/nieuws/bekijk/artikel/alles-over-ethernet.html
