Dette indlæg er alene udtryk for skribentens egen holdning.

ESO/ELT WFRTC: Hul igennem

6. juli 2012 kl. 23:403
Artiklen er ældre end 30 dage

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:

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

Artiklen fortsætter efter annoncen

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"

3 kommentarer.  Hop til debatten
Denne artikel er gratis...

...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.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
2
7. juli 2012 kl. 20:20

Hvor kommer de "halve" maskiner fra? Fx punktet ved 2½ på grafen.

1
7. juli 2012 kl. 10:06

Tak for at du deler det med os! Det kunne også være interessant at høre lidt mere om teknikken, f.eks. netværk, bruger i MPI eller lign. osv?