Start ved begyndelsen...

...fortsæt til du når slutningen og stop der.

Således lyder kongens instruktion til den hvide kanin i Alice i Eventyrland og det er ikke nogen helt dårlig måde at angribe et projekt på.

Som i muligvis så er jeg med i et projekt der skal bygge en prototype på en "Wave Front Real Time Computer" til ESO's nye monsterteleskop "Extremely Large Telescope"

Det er Force Technology, tidligere "Svejsecentralen" og "Korrosionscentralen" der står for den numeriske del af opgaven (10008x10008 fuldt populeret matrix multiplikation på under 1msec). Min rolle er mest at få alt det uden om den numeriske kode til at spille, herunder nogle krav til tid og den slags. Hvordan vi løser selve opgaven skriver jeg mere om når vi kommer dertil, jeg skal lige have fundet ud af hvem der skal clear'e hvad jeg skriver om de dele.

Men inden vi kan begynde at skrive kode skal der laves noget fodarbejde og derfor har jeg lige været igennem den "sædvanlige process" med at installere et operativsystem, konfigurere et versions styrings værktøj osv. osv.

Alt det kan man i et nyt open source projekt slippe for ved at bruge en af de efterhånden mange gratis tilbud om projektinfrastruktur (github, sourceforge osv.) men vi har nogle kontraktkrav som det ville tage længere tid at få bøjet så de tillader sourceforge/github modellen, end det tager mig at sætte et udviklingsmiljø op.

For mange år siden indså jeg at den eneste forskel der er på en total-backup af et projekt og et release man kan give til kunden, er hvad man skriver på datamediet. Funktionelt er kravene præcis de samme.

Inden man kan noget andet skal man have installeret et operativsystem, derefter skal man have projekt-data kopieret ind på maskinen og endelig skal alting compileres, konfigureres osv.

Der er absolut ingen grund til at et sådant projekt-release skal deles over to halv-fyldte datamedier, så jeg fylder projektdata ned på FreeBSD install-iso.

Og ja, man kan faktisk godt fylde flere filer på en ISO.

Helt lavpraktisk kan man snyde og lave et multi-session image, men det har den ulempe at man ikke ender med en enkelt .iso fil man kan lave en checksum af osv.

Det jeg gør er at clone ISO filens indhold ind i en ny ISO fil:

mkisofs \  
    -v \  
    -b boot/cdboot \  
    -no-emul-boot \  
    -r \  
    -J \  
    -V "WFRTC_Install" \  
    -publisher "Force Technology" \  
    -o ${ISO_DST} \  
    -m rr_moved \  
    -graft-points \  
    /cdrom \  
    WFRTC/sysbuild=/tmp/_.$$/sysbuild \  
    WFRTC.TXT=/tmp/_.$$/docs/install.txt \  
    WFRTC/README.TXT=/tmp/_.$$/docs/install.txt \  
    WFRTC/var_db_ports.tgz=/tmp/_.$$/var_db_ports.tgz \  
    WFRTC/WFRTC.tgz=/tmp/WFRTC.tgz

Den originale install-ISO er mounted på /cdrom og derfra tages det meste af indholdet.

De sidste 5 linier tilføjer det jeg gerne vil have med: Min "sysbuild" konfiguration (mere om den en anden gang), et dokument der forklarer hvordan man skal installere ting (to gange), og et par TGZ filer med projektets data.

Argumentet "-b" og "-no-emul-boot" er halvmagiske for hvert operativsystem og I bliver nødt til at prøve at aflure hvad jeres OS/Distro kræver. Men derudover er metoden lige til at gå til.

Jeg testede proceduren igår: Det tager ca. en halv time at lave en ISO og installere den på en anden maskine, så når vores hardware ankommer er vi i luften med det samme.

Næste gang jeg ruller en ISO er der kommet et shell-script med overtager noget af det manuelle arbejde fra "install.txt"

phk

Kommentarer (14)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Claus Junker Jørgensen

I har altså kontraktkrav der siger at i explicit ikke må købe hosting af versionsstyring/backup ude i byen? :o

Fordi ellers kan man jo godt hoste closed source på GitHub. Det koster bare penge ;-) Noget skal jo financiere den gratis hosting på GitHub, ikk?

  • 0
  • 0
Poul-Henning Kamp Blogger

I har altså kontraktkrav der siger at i explicit ikke må købe hosting af versionsstyring/backup ude i byen? :o

Nej egentlig ikke, men der ligger en stak standard dokumenter for hvorledes ESO kører projekter og det er nemmere bare at gøre som der står, end forklare at GitHub eller SourceForge lever op til samme krav.

Desuden er vi kun en håndfuld involverede personer og sikkert kun tre der skal skrive kode...

  • 4
  • 0
Mikkel Meyer Andersen

Når du skriver matrixmultiplikation, mener du så en 10008x10008 multipliceret med en 10008xN matrix for N = 1, N > 1 eller N >> 1?

Kan I ikke bruge BLAS eller LAPACK til matrixmultiplikationen? Det plejer at være ret hurtigt (jeg tør dog ikke sige, om det er tilstrækkeligt i dette tilfælde, men så vidt jeg ved, er det her state of the art indenfor den genre findes).

Du skriver, at matricen er fuldt populeret - ved I slet ikke noget om strukturen?

  • 0
  • 0
Martin Hundebøll

Jeg har den sidste uges tid rodet en del med en Linux install på et SD-kort (til et pandaboard). Det fede ved SD-kort er jo read/write i stedet for read-only.

Jeg har simpelthen bare en kørende install (af Arch Linux) som jeg kloner med "dd" - inkl. bootloader osv. Man kan lave alverdens tricks med img-filen (som indeholder to partitioner - med rootfs på partition 2), men her er nogle af de mest anvendelige:

Backup:

dd if=/dev/sdb of=disk.img

Restore:

dd if=disk.img of=/dev/sdb

Mount / (root):

fdisk -l disk.img  
mount -o loop,offset=<start-sector*512> disk.img /mnt/

Fjern ubrugt plads:

losetup /dev/loop0 disk.img --offset=<start-sector>*512  
e2fsck -f /dev/loop0  
resize2fs -M /dev/loop0 # Læs hvor mange 4k-blocks fs ny fylder fra output  
losetup -d /dev/loop0  
fdisk disk.img # Slet partion 2 og opret ny med +<blocks*8> sectors  
dd if=disk.img of=disk-small.img bs=512 count=<end-sector+1>

Udvid med ubrugt plads (efter restore):

fdisk /dev/sdb # Slet partition 2 og opret en ny med mere plads  
e2fsck -f /dev/sdb2  
resize2fs /dev/sdb2

På den her måde slipper man helt uden om installationsprocessen og det er nemt at lave en nyt "release" :) (Og nu jeg det endelig skrevet ned til mig selv...)

  • 2
  • 0
Poul-Henning Kamp Blogger

Jeg roder muligvis stadig rundt i de der matrices størrelse :-)

Vi får 1x10008 ieee binary32 floats ind, de skal først igennem en 10008x10008 sparse matrix multiplikation (max 12 ikke-nul per kolonne) Derefter skal den resulternde 1x10008 igennem en 10008x6350 der er fuldt populeret, den har ingen struktur at lege med og sidste bit af resultatet på 1x6350 skal foreligge præcis 1millisekund (+/- 20 mikrosekunder) efter at vi har modtaget første bit af input vektoren. Gentages hvert andet sekund i minimum 4 timer i træk.

  • 0
  • 0
Jesper Louis Andersen

Det er slet ikke givet på forhånd at ATLAS/LAPACK/BLAS er i stand til at gøre det hurtigt nok. Men heldigvis er det 32bit ieee floats, så du kan uden problemer købe et par TEGRA kort hos Nvidia og sætte dem til at lave arbejde. Så er spørgsmålet bare om vi kan få data hurtigt nok til kortet - det afhænger til dels af hvor hurtigt matricerne skal opdateres.

  • 0
  • 0
Claus Stovgaard

Virker som et super spændende projekt.

Nu er jeg embedded mand, så jeg vil se på noget FPGA acceleration hvis interfacet ellers giver mulighed for det.

F.eks. så har Dini group jo accelerationskort som http://www.dinigroup.com/new/DNBFC_S12_PCIe.php

Hørte Mike derfra beskrive et 4U cluster med 12 af sådan nogen kort. Performance, hvis ellers algoritmerne kan beskrives i hardware og data transporteres rundt, er noget af det højst mulige.

  • 1
  • 0
Esben Nielsen

Hvad er jeres interfaces med det øvrige system? Hvilke muligheder har I for valg af hardware?

20us er et meget lille jitter i forhold til det man møder på almindeligt PC hardware, selv med det bedste realtids OS.

Umiddelbar ville jeg bruge en FPGA til det hele; men det kommer an på, hvordan man skal få data ind og ud. Det er lidt svært at lave TCP i en FPGA, mens man godt kan få en FPGA til at snakke UDP og lignende simple protokoller.

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