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.

Kommentarer (25)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#3 Michael Cederberg

... og det har gjort en forskel på hvilke opgvar vi kan løse (fx. "big data"). Desværre er er ny hardward i mange tilfælde blevet synonymt med brute force dataprocessing uden finesse. Det er selvfølgeligt altid en balance hvor meget man vil goldplate, men det er forfriskende at høre at I ikke er forfaldet til samme men i stedet har bygget en løsning hvor gevinsten at lavere operationelle omkostninger i årene fremad. Jeg gætter på at når softwaren først kører og spejlene styres ordentligt så piller ingen ved skidtet i mange mange år.

  • 1
  • 0
#9 Klavs Klavsen

Hvor "let" er det at skifte til en hvilken som helst anden anden distribution?

Som PHK beskriver det, så kører de jo ikke engang systemd som init - så umiddelbart kan de hurtigt skifte til en hvilken som helst distro, hvor de kan få en Python version og C compiler deres kode passer til, dog vil de formodentlig foretrække en distribution der udgiver backport af sikkerhedsfikses i en del år - hvilket låser dem Ubuntu, nu CentOS lukkes.

Alternativt kan de opdatere og teste nyere python versioner løbende, efterhånden som der kommer sikkerhedsrettelser, de vurderer skal på maskinerne. De er jo ikke ligefrem vildt udsat sikkerhedsmæssigt - og vælger man at ignorere evt. sårbarheder i python, så kan de skifte til "alt" - da det som beskrevet i artiklen, kun er deres egen init, lidt python miljø og vanilla kerne de kører.

  • 5
  • 0
#12 Troels Henriksen

dog vil de formodentlig foretrække en distribution der udgiver backport af sikkerhedsfikses i en del år - hvilket låser dem Ubuntu, nu CentOS lukkes.

Er det egentlig så vigtigt? Det lyder ikke som om disse maskiner skal udsættes for input fra fremmede kilder, så med mindre en af spejlsensorerne falder til den mørke side, så tror jeg sikkerhedsfladen er ret lille.

Hvad er det for en implementering af matriksmultiplikation I bruger? Blot en almindelig LAPACK fra Netlib? Intel's MKL er populært, men jeg ved ikke hvordan det kører på Epyc.

Jeg er også lidt usikker på nogle af tallene. Er det hver sensor der 500 gange i sekundet har brug for at lave matriksmultiplikationer for 700GFLOPs, således at hver sensor har brug for 350TFLOPS regnekraft? Det lyder som en del mere end selv et par muskuløse Epyc'er kan klare - de tal jeg kan finde ligner mere noget med 5TFLOPS, og selv det lyder lidt højt (jeg antager der er tale om double precision). Selv de hurtigste GPUer kan kun lige runde 10TFLOPS.

  • 2
  • 0
#13 Flemming Riis
  • 0
  • 0
#17 Poul-Henning Kamp Blogger

Hvad er det for en implementering af matriksmultiplikation I bruger? Blot en almindelig LAPACK fra Netlib? Intel's MKL er populært, men jeg ved ikke hvordan det kører på Epyc.

MVM'en er håndrullet, så vi kan begynde at regne så snart den enkelte pakke er ankommet.

Billedet fra sensoren fylder 160 jumbopakker og scannes samtidig fra to sider ind mod midten. Hele udlæsningen tager (i denne sammenhæng) meget lang tid.

Se evt: https://www.teledyne-e2v.com/content/uploads/2014/10/Downing-ELT-WFS-spi...

Efter at have lavet dark/flatfield på billedet, pakke for pakke, er det kun et ringformet udsnit af billedet der skal regnes videre på og dette udsnit skal yderligere opdeles i "centroider" hvis X og Y vægt er input til MVM.

Ved at sortere MVM'en kan de enkelte CPU cores startes progressivt og den sidste bliver færdig ganske kort tid efter sidste inputpakke, der indeholder den midterste strimmel af billedet, er ankommet.

  • 4
  • 0
#19 Troels Henriksen

Billedet fra sensoren fylder 160 jumbopakker og scannes samtidig fra to sider ind mod midten. Hele udlæsningen tager (i denne sammenhæng) meget lang tid.

Cool! Jeg har stort set udelukkende erfaring med bulk/throughput-orienteret beregning, så min sædvanlige intuition fungerer ikke rigtigt når fokus er streaming som her. Det er en ret interessant fremgangsmåde at lave den slags "inkrementel" MVM - det betyder vel så også at dens throughput ikke behøver være så høj som i en traditionel LAPACK, da den bare skal følge med IO-hastigheden. Har I overhovedet brug for at benytte vektorinstruktioner? Hvis ydelsesbudgettet kan holde til det, så ville det jo stemme godt overens med jeres generelle fokus på langvarig holdbarhed at holde sig til de mest almindelige instruktioner (f.eks ved at skrive det i helt portabel C, så man også kunne gå over til ARM hvis x86 står i flammer om et årti).

  • 1
  • 0
#20 Martin Zacho

Det er selvfølgeligt altid en balance hvor meget man vil goldplate, men det er forfriskende at høre at I ikke er forfaldet til samme men i stedet har bygget en løsning hvor gevinsten at lavere operationelle omkostninger i årene fremad.

Når man starter et nyt udviklingprojekt, kan det ofte betale sig at "gold plate", da det sparer tid og på det tidspunkt hvor projektet skal i produktion, er hardwaren blevet 2-3 gange hurtigere (målt i GFLOPS). Den tid som en udvikler benytter på at få en uddateret HW til at performe optimalt, kan oftest bruges bedre :)

  • 1
  • 1
#22 Martin Juhl Jørgensen

Tillad min ignorance omkring POSIX init og systemD et øjeblik. Du nævner at det i princippet er en vanilje Linux kerne, vil det sige ingen real-time patch osv? Hvordan har i garanteret hård realtidskravene så, er det per design af få applikationer der kører deterministisk?

  • 0
  • 0
#23 Poul-Henning Kamp Blogger

Du nævner at det i princippet er en vanilje Linux kerne, vil det sige ingen real-time patch osv?

Korrekt.

Det er ikke os der har valgt at kalde det "real-time", det er ESO og det er mest fordi det har man altid gjort.

I virkeligheden er det et batch-system uden noget som helst "real-time" over sig: Vi ved præcist hvornår input-pakkerne ankommer.

Den eneste måde vi så i praksis udnytter den viden på, er ved ikke selv at sende noget overhead traffik lige på det tidspunkt.

  • 3
  • 0
#24 Jan Heisterberg

PHK:

  1. kan du mon komme med tal for hvor hurtigt spejlene skal ændres for at følge med de atmosfæriske forstyrrelser ?

  2. kan du komme med tal for vandringen af aktuatorerne ? (måske i anden enhed end den velkendte journalistenhed "mulehår".).

  • 0
  • 0
Log ind eller Opret konto for at kommentere