Moderne hardware ER fantastisk
Det er på tide at få "afrapporteret" vores ESO projekt.
Sporten kort: ESO bygger verdens største teleskop på en bjergtop i Chile. Tænk på det som en kikkert med et spejl så bredt som Rundetårn er højt i en bygning på størrelse med hele Rosenborg slot.
Man kan ikke lave spejle der er stive nok til at holde formen og derfor laver man "deformable" mirrors, hvor hundrede eller tusindevis af "actuators" på bagsiden af spejlet kan trykke og trække til formen er perfekt indenfor en brøkdel af en bølgelængde, hvilket i runde træk vil sige en et mulehår[1].
Når nu man faktisk kan bøje sine spejle, kan man gøre smartere ting end at give dem perfekt form, man kan f.eks give dem en form der kompenserer for inhomogeniteter i luften over teleskopet og på den måde få spejlene til at holde op med at tindre.
Det kaldes "adaptiv optik" og er sindsygt spændende og imponerende teknik.
I praksis består det af fem dele:
Kraftige lasere med 589.2 nanometer bølgelængde, der kan anslå natrium atomer i den yderste atmosfære, ca. 90km oppe og derved lave en "kunstig stjerne".
"Wavefront sensors", specielle linser der afbilleder lyset fra kunststjernes afvigelse fra perfect når det kommer tilbage til teleskopet.
En masse "hurtig" men temmelig simpel regnekraft til at lave disse billeder om til styresignaler til aktuatorerne på spejlene på få millisekunder.
Aktuatorene og deres spejle.
En masse "langsom" regnekraft til intensive og indviklede beregninger af koefficienterne til de "hurtige" udregninger.
Vores opgave var den i midten: Byg en "Hard Real-Time Core Prototype" der kørte på almindelige servere, istedet for som tidligere, 19" rack fyldt med specialbygget elektronik der ikke kan skaffes reservedele til efter ganske få år.
I hårde tal: Der er seks "Wavefront sensors" på 800x800 pixels, de tager billeder 500 gange i sekundet, der skal laves ca. 700 GFLOPs matematik og resultatet skal sendes til spejlenes aktuatorer så hurtigt som muligt for at få så høj båndbredde i reguleringen som muligt[2].
Og det har vi så lavet.
Vi er i den forbindelse Niels Hald Petesen fra Force Technology, som har taget sig af matematikken og undertegnede der har taget sig af "alt det andet".
Til hvert kamera bruger vi to 2U servere med to af de største EPYC cpu'er vi kunne købe på det tidspunkt. Den ene server tager sig af den optiske "dark/flat" korrektion af kameraets lysfølsomhed, opsplitning af billedet svarende til de "Shack-Hartmann lenslets" der sidder foran kameraet og projection til spejlenes koordinatsystem via en 4616x6316 matrix-multiplikation. Den anden server laver en tilsvarende matrix-multiplikation men med modsatte dimensioner, på tilbagekoblingssignalet fra spejlene.
En "backend" server samler data fra alle de seks spejles "frontends" laver lidt, relativt set triviel matematik og sender kommandoerne til spejlene, modtager feedback fra spejlene, laver den omvendte matematik og sender mellemresultatet til de seks "assisterende frontends".
Siden vi købte de "store servere" har AMD været i køkkenet og idag kan man formodentlig nøjes med en server per sensor[3].
Software mæssigt var det et krav at bruge CentOS og derfor var den første opgave at lave en "systemdectomy", for alene i vores analysefase voksede SystemD med flere hundrede tusinde linier kode og guderne må vide hvad SystemD er og gør til Sct. Hans.
Hvis denne prototype skulle have nogen værdi for ESO, så nytter det ikke at den kun virker i tre måneder indtil SystemD projektet får deres næste indfald.
Den nemmeste måde at slippe for SystemD er at forhindre den i nogensinde at starte: Vores "real-time nodes" netbooter og på ramdisken er /sbin/init ikke SystemD men et lille shell-script som loader nogle netværksdrivere, konfigurerer nogle IP# og starter et lille serverprogram kaldet "domus".
Kontrol-computeren kontakter "domus" via TCP og downloader og kører det til maskinen hørende program ad den vej.
Vi er nødt til at tweake et par tunables, interrupt-pacing/adaptive-rx og den slags og vi har givet kernen nogle argumenter så vi kan styre helt præcis hvilke tråde der kører på hvilke cores osv, men det er en 100% vaniall Linux kerne, lige ud af æsken.
Der er en anden styre-computer kaldet "pacer" der er ansvarlig for at holde rytmen i hele clusteret og som sørger for at parametre, f.eks 120MB koeffienter til de store matrix-multiplikationer kan opdateres uden at forstyrre "produktionen" af gennemstrømmende data.
Der er den komplikation at alting i systemet skal være parametre: Antallet af sensorer, deres størresle, antallet af spejle, deres størrelse osv. osv. osv.
Det har vi klaret ved at lave en datamodel af systemet i Python som spytter en masse C-kildetekst ud for os, f.eks al koden til modtagelse og transmission af de mange datastrømme i systemet.
Alt i alt er der lidt over 50 tusinde linier kode, ca. 12 tusinde linier med en egentlige matematik, herunder koordination mellem alle de CPU-cores der løfter opgaverne i fællesskab, ca. 21 tusinde linier kode i "infrastruktur" og 7000 linier pythonkode til datamodellen og "confidence test".
Med et så stort system, hvor alting til og med er parametre, skal man tænke grundigt over en test-strategi inden man overhovedet går i gang.
Man kan faktisk godt lave "Continuous Integration" på et system så "underligt" som dette, men man skal tænke sig om fra starten, hvis det ikke skal blive en Storm-P konstruktion der giver falske alarmer i tide og utide.
Vores "confidence test" består af Pythonkode der definerer de enkelte test-cases og noget C-kode der faktisk driver systemet igennem selve testen, hvorefter pythonkoden checker resultatet.
I praksis tager det et par minutter at køre en make confidence og det er lidt længere end jeg bryder mig om, men absolut acceptabelt.
Grunden til at testen hedder "confidence test" er at det ikke er i nærheden af at være en total test af systemet, men hvis den nikker lodret er der rigtig god grund til at have tillid til at systemet virker.
Når man har behov for at blive mere overbevist, kører man hundredevis af randomiserede kørsler, med mange hundrede parallelle kopier af de enkelte deltests, indtil man er tilfreds.
Fordi det er en prototype har det været os magtpåliggende at gøre den så generel og "hackable" som muligt, f.eks har alle programmer et indbygget command line interface, således at man nemt kan tilføje et "håndtag" mens man roder med koden.
Den endelige performance, på de parametre der virkelig batter noget for den resulterende videnskab, specielt gennemløbstiden og jitter på kontrolsignaler til spejlene, er væsentligt bedre end kravene i kontrakten og det har heldigvis kompenseret lidt for at vi er blevet noget forsinkede.
Det der måske har gjort det største indtryk på mig er hvor fantastisk moderne hardware faktisk er.
Da ESO begyndte at planlægge dette teleskop, for ca. tyve år siden, ville denne regneopgave have krævet verdens ca. 15 hurtigste supercomputer, f.eks en IBM SP Power3 med 700 noder.
Idag forventes man selv at taste den slags "småordrer" ind i serverproducentens webshop.
ESO er allerede ved at bygge et par produktionssystemer til andre teleskoper baseret på vores prototype og det er så godt som sikkert at ELT teleskopet kommer til at køre på det også.
phk
PS: Som I måske fornemmer har jeg endnu ikke ESO's tilladelse til at gå alt for meget i detaljer, men jeg satser på at få godkendt et nørd-foredrag om projektet inden IDAs Driving IT.
[1] De fleste mennesker bliver overrasket når man fortæller dem at vores følesans virker kan mærke ting der måles i nanometer, men det kan vi. Nogle bedre end andre.
[2] Det er undgåeligt at der vil opstå resonanser i en stålkonstruktion på størrelse med Rosenborg, disse skulle gerne kunne kompenseres ud med AO så båndbredden skal helst op på flere hundrede Hz.
[3] Der er dog en krølle på den hale: Chips med 5nm geometri er per definition mere følsomme for kosmisk stråling end f.eks chips med 7nm geometri og i produktion havner disse maskiner i 3km højde, hvilket vil sige at der er langt færre atomer over dem til at skærme imod kosmisk stråling.
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
