ESO/ELT WFRTC: Hul igennem

Som altid er der god venderadius på de gode intentioners holdeplads, men altså: Nu har vi fået hul igennem vores "Wave Front Real Time Cluster"

Og det første foreløbige resultat ser således ud:

Illustration: Privatfoto

På Y aksen har vi hvor mange mikrosekunder vi bruger på den store 10.008 -> 6.350 matrix multiplikation.

På X aksen er hvor mange maskiner der er brug for i clusteret.

Ganske som Niels forudsage er fire-fem maskiner "sweet-spot" hvor man får mest for pengene: Har man færre maskiner falder ting ud af CPU'ernes cache, har man flere maskiner er det begrænset hvor meget man vinder i tid per maskine.

Det er dog slet ikke utænkeligt at der er en videnskabelig fordel ved at kaste 10 maskiner efter clusteret, det vil formodentlig tillade en opdateringsfrekvens på 2kHz på den adaptive optik.

Og det er det jeg godt kan lide ved at arbejde på et projekt som det her: Naturligvis vil kunden gerne høre om vi har fundet en måde at gøre det for de halve penge, men de vil meget hellere høre os gøre det dobbelt så godt for de samme penge.

Nu hvor vi har hul igennem, skal vi bare have fuget tingene ordenligt sammen.

En af de ting der ikke er på plads er opstarts-proceduren: Det er fint nok at det hele svinger når alt ligger det rette sted i de rigtige cache-linier, men vi mangler lige at komme fra BRSA og til at alt ligger klart og klappet.

Det jeg endte med at bruge dagen idag på, er en kvasi-PLL der slår takten for clusteret. I drift får vi takten fra Wave Front sensorene, men clusteret starter inden da og har brug for en fritløbende takt at starte med. Når så WF pakkerne begynder at dukke op skal clusteret svinges ind i denne takt men vi kan ikke arbitrært forkorte en arbejds-cyclus, så PLL'e tager store forskelle ved at gøre arbejds-cyclus længere, indtil vi har WF pakkerne i det rette tidsvindue, derefter skifter den til en mere almindelig PLL for at holde synkronisering.

Det hele kompliceres af at vi kan miste WF pakker og WF pakkerne kan skifte både fase og frekvens i forbindelse med "mode-changes" og særligt her i debug-fasen, mens man febrilsk prøver at holde alle boldene i luften.

Det næste problem vi skal have tacklet er opdatering af registreringsmatricen, det tager pt. 1.5 millisekund og det er i bedste fald dobbelt så lang tid som vi har til det indenfor kontraktkravene og 5 gange længere tid end vi synes det bør tage. Problemet er at vi har den nye matrice liggende på CORE#0 og skal have den kopieret til CORE#1...5 og helst uden at alle fem cores står og jokker hinanden over tæerne i cache/memory båndbredde.

Og så selvfølgelig alle de andre ting, men det vigtigste er at vi har hul igennem...

phk

PS: "BRSA" = "Big Red Switch Activation"

Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Log ind eller Opret konto for at kommentere