UEFI-3 belastningsprøve interrupt.

Dette bør være volapyk for alle, der ikke har læst og forstået det forrige indlæg “UEFI vs PC emulatorer” inklusive “UEFI2.PDF”.
Så er der advaret.
Der er lavet en belastningsprøve af en UEFI-3 PC baseret på Intel i-5 cpu. Der er her tale om en regulær industri-PC med minimal CSM-support, der alene gælder for prommen hos et eksternt skærmkort, og som kun bruges til at tænde for ønsket videomode.
Hvad der gør den til UEFI-3, er, at det ikke længere er muligt at få et isat PCI-xpress skærmkort til at supportere de gamle VGA/VESA modes baseret på et ramvindue inden for den første megabyte (0xa0000 o.s.v.). BIOS og bundkort nægter at allokere d.v.s. bus-dekode nogen form for adapter ram-vindue her, og prøver man at aktivere en af de gamle modes via CSM og gammel int 10h video-bios, fejlmeldes.
Kortet er derfor utilgængeligt fra realmode, men fungerer sammen med GOPA7.EXE (256 farvers 800×600 vesa 0x103) i kombination med en ny 32-bit kompilation, hvor:
1) Alt hvad der før var interrupt-baseret, er nu poll-baseret (ligesom UEFI selv).
2) Det timertick, der driver pollet og realtidsdelen herunder grafikken, er nu eneste interrupt-kilde (bortset fra de uundgåelige smi-ints). Det nye er her, at timertick drives ved hjælp af HPET (timer) og xAPIC (interrupt controller) ved en frekvens på 9296 Hz. Tidligere var frekvensen kun en 4-dedel, d.v.s. 2324 Hz og det var den gamle timer (8254) og den gamle int-controller (8259), der stod for det.
Den gamle kode, der tidligere kørte 2324 Hz opgaven med lukket interrupt, kører nu åbent, og startes op ved hvert fjerde af de nu 9296 ticks/sekund. De gamle interrupt-opgaver løses nu som poll 4 gange med lige stort tidsmellemrum, hver gang 2324 Hz opgaven løses een gang.
Den store belastningsprøve blev lavet på den tungeste app nogensinde: KOLD2 (Hoved-PC i Kolding), som den så ud i starten af 2021, hvor alle relæboxe var af DV-typen, og hvor alene denne post tegnede sig for 8960 interrupts i sekundet. Samtidig blev en mølles hovedmotor overvåget, der gav knap 25 pulser i sekundet (en puls/omdrejning fra superhurtig induktiv føler), og hvor det var vigtigt, at vi ved at måle tid mellem pulser kunne opdage en for stor nedbremsning hurtigst muligt, så vi kunne stoppe fødesnegl og hindre fastkørsel af mølle.
Her kunne et enkelt tabt interrupt medføre unødig opbremsning af fødesnegl og dermed tab af effektivitet.

Resultat:
Worst-case interrupt-forsinkelse blev målt til 34.33 us, men PC-en skal statistisk set køre i nogen tid, før de sidste to mikrosekunder viser sig. I det første lille minuts tid vises en max forsinkelse på 32.34 us. Så det er et ret kvalificeret gæt, at de sidste knap 2 mikrosekunder netop er de 2 mikrosekunder, et udefra påtvunget smi-interrupt max må forsinke den normale interrupt-håndtering.
Det knap to mikrosekunder lange smi-int afslører sig først, når det rammer tidsvinduet mellem, at HPET har sendt FSB/MSI int mod CPU-en, og til CPU-en er nået velbeholdent frem til int-handleren, hvor vi skynder os at aflæse HPET tællerværdien til analysebrug.
Det tungeste bidrag er det extra overhead, der er forbundet med interrupt, der indtræffer mens lavt priviligeret kode exekverer (f.ex. V86 kode).
Et forsøg på samme PC, hvor der ikke sker privilegie-skift (fordi der kun findes flad 32-bit kode, der kører i level-0, d.v.s. mest priviligeret) viser nemlig hhv 5.2 og 7.19 us.
Så alt tyder på, at SMI interruptsne ikke laver unoder af betydning. De lovlige aktiviteter, der udføres af disse ikke særlig hyppige afbrydelser på under 2 us skulle være ting som overvågning af CPU temperatur og tænd/sluk knappen.
PC-en har kørt i en uge, med worst case interrupt forsinkelses tallet stående fast på 34.33 us og der er jævnlige kørsler med harddisk (AHCI SATA), der kan belaste systembussen.
Det kunne ligne en slags “proof-of-concept” på, at 2028-grænsen måske er en saga blot.