Prestanda WeOS-NG

Vad kul att det gått så bra! Spännande med prestandafrågan. Den har ju varit uppe några ggr nu, ända sedan vi gjorde en första mätning på routingprestande för snart två år sen på en av våra första prototyper till ny SW-design, och fick väldigt dålig prestanda.

Det finns flera frågor här att ta hänsyn till när prestanda kommer upp på bordet, är det:

    Layer-2, dvs. omkopplingstider för FRNT och RSTP?
    Layer-3, dvs. routing och/eller masquerading

Jag gissar att det enbart är layer-3 som är det folk pratar om och där är det ju i grund och botten en fråga om hur många hästar man har under huven, dvs. vilken HW vi har.

För produkter som kört WeOS 4.x har det enbart varit fråga om SW-baserad routing och firewalling, så CPU:n och overhead från SW sätter begräsningarna.  I WeOS 4.x har vi lagt mycket tid i flera omgångar på att optimera paketflödet, så det är rätt svårt att slå på produkter som är helt förvisade till SW-baserad routing.

Vad vi i designen av WeOS-NG (som redan är satt) har valt att fokusera på är:

    Skalbarhet - det ska vara enkelt att lägga till nya funktioner
    Separation - tydlig separation av HW-stöd och SW-funktioner för att tillåta friare design av ny HW
    HW-baserad routing - framtida produkter, såväl som många befintliga har stöd för offloading i HW för acceleration av hela, eller delar av stacken


Genom att göra ett tydligt snitt mellan Linux (som är kerneln) och våra applikationer i userspace ger designen i WeOS-NG oss något som faktiskt fungerar som ett vanligt Linux-system. Precis så som rackbaserade Linux-servrar eller min laptop fungerar.

WeOS-NG ger oss en abstraktion som inte var möjlig med WeOS 4.x. Den tillåter mycket enklare utveckling av nya funktioner på en vanlig laptop.  Ökad testbarhet i det att vi isolerat kan testa nya funktioner innan de integreras i WeOS och en produktrelease.

Funktioner som är integrerade i WeOS kommer kunna testas utan fysisk hårdvara.  Vi kommer till och med kunna testa hela nätverk med flera emulerade HW-noder för mer avancerade funktioner som t.ex. FRNT och OSPF.

Den flexibilitet vi får, inte bara för vad jag nämde ovan om uteckling av SW, utan även för HW gör att vi kommer få mycket lättare att se vad HW tillför. Med relativt liten insats i Linux (kerneln) kan vi lägga till acceleration av routing på Cerebrum-plattformen, vilket hade varit väldigt svårt att få till med WeOS 4.x.

Tyvärr är all denna flexibilitet, skalbarnet och frikoppling från HW inte utan kostnad.  SW lyder bara under en enda fysisk storhet och det är tid.  Allt vi gör betalar vi med i tid. Så när vi nu får frågan om prestanda, och vi kommer benchmarkas mot en optimerad WeOS 4.x på åldrande HW utan möjlighet till acceleration lär jämförelsen bli rätt skev.

Samtidigt förstår både jag och mina kollegor att man från marknads sida gärna vill ha en enkel metric att jämföra sig med.  Både mellan våra egna och konkurrerande produkter.

Så hur ska vi göra?

Här följer ett förslag på vad, hur och varför (inte):

Produkt	        Layer-2	Layer-3 	Hur/Usecase	Varför
-----------------------------------------------------------------------------------------------
Lynx 110	FRNT	N/A     	Omkopplingstid	Främsta use-caset (max 20 msec)
Lynx 210	FRNT	N/A     	-       	Som Lynx 110, ej gjord för routing
Falcon, Viper	FRNT	N/A     	-       	----- " ----- " ----- " ----- " -----
DDW-142 	FRNT	N/A      	Omkopplingstid	----- " ----- " ----- " ----- " -----
DDW-242 	FRNT	N/A     	-       	----- " ----- " ----- " ----- " -----
RedFox RFI	FRNT	Routing 	Plain, no NAT	Som Lynx 110, samt rå routingperf.
RedFox RFIR	FRNT	-       	-       	Samma som RFI (ej supportad?)
RedFox RFR	FRNT	NAT       	1-to-1 NAT      Vanligt tåg-case
RedFox RFI	FRNT	MASQ       	Inet GW 	Routing + NAT (masquerading)

Nuvarande Lynx, Viper, DDW och Falcon har alla den långsammaste CPU-plattformen, både 100- och 200-modellerna.  Plattformen har en Freescale i.MX27 CPU (endast 16 kiB L1 cache) och var aldrig tänkt som routingplattform.  Pga den lilla cachen, och cachehanteringen på den ARMv5-arkitekture, är den väldigt känslig för "cache thrashing", vilket vi sett har ökat kraftigt med nyare Linux kernel.  För prestandatest mot dessa körandes WeOS 4.x är omkopplingstiden på FRNT troligen den mest relevanta.

För RedFox (Corazon, som har 32 kiB L1-cache och 256 kiB L2-cache!) kan vi köra simpel routing och masquerading, dvs utan och med firewall.  På WeOS-NG har vi en hel del prestanda att hämta hem i det förra fallet då vi kommer kunna stänga av firewallen helt, medan WeOS 4.x inte tillåter att den är helt avstängd och därmed får viss penalty (WeOS 4.x säger att firewallen är avstängd, men den är på i bakgrunden för att filtrera trafik till tjänster och andra oheliga saker).

För Layer-2-produkter rekommenderar vi därför FRNT omkopplingstid och på Layer-3 produkter FRNT omkopplingstid och två routingtester, med och utan firewall.  Vad exakt det ska stå i kraven på prestanda får vi nog sätta oss ned och prata mer om, för bara av det jag försökt förklara ovan så borde det framgå att det inte är helt enkelt att få fram en sådana siffror.

Mvh
 /Jocke