Real-time vs. Low Latency

Real-time og low latency er to helt forskjellige ting, og kan i mange tilfeller motarbeide hverandre. Hvis du er interessert i temaet anbefaler jeg kryss sjekk med seriøse lærebøker, det begynner å bli to-tre år siden jeg holdt på med dette, og jeg har aldri vært spesielt dypt i det.

Den norske oversettelsen "sanntid" har kanskje litt av skylden for at folk er forvirret. Mange tror at real-time betyr noe sånt som "Input A -> Output B i sanntid". De fleste som driver med datamaskiner vet at dette ikke er mulig, det er alltid en forsinkelse mellom A og B. Fellen som folk går i er at de tror at real-time indikerer at denne forsinkelsen "ikke er merkbar" eller et annet, upresist uttrykk.

Det real-time computing (RTC) går ut på er at du kan garantere at Input A -> Output B innenfor X tidsenheter. Men hva X er må spesifiseres nærmere og avhenger selvfølgelig av maskinvaren og hvilke andre oppgaver den må utføre. Mye av arbeidet med RTC er matematisk og går ut på å bevise at i verste fall, uansett data som mates inn maskin, vil den svare innenfor gitt tidsramme. Slike bevis blir vanskelige når man involverer snarveier og hurtiglager.

Å nice andre prosesser og lignende er ikke nok. Hard real-time går helt til bunns i koden, f.eks. hva skjer om alle hashtabellene er i verst mulig forfatning, hvor lang tid vil det da ta? (Alle nøkler ga samme hash verdi, slik tabellen må utvides eller strukturene lenkes). Hvis dette ikke er godt nok, kan du bevise at tabellene aldri vil havne i en slik forfatning?

Hvis du tenker på hvor mange steder i koden hashtabeller brukes, og hvor mange forskjellige verdier (eksempelvis via nettverkspakker) som kan mates inn, så ser man fort at dette blir vanskelig å bevise noe som helst for et komplisert system som Linux.

Det finnes mange måter å løse real-time kravet på. En av disse er å si at man ikke bryr seg om 99% av det Linux kan gjøre. Si at man bare vil garantere at når pakke med kjennetegn A kommer inn gjennom nettverksporten så går det maksimalt 2 ms til LEDen på forsiden lyser. Jeg ignorerer "interrupts" for å gjøre eksempelet litt enklere. Legg merke til hvor trivielt dette er i forhold til at som er involvert ved lydbehandling.

Da må man beregne hvor lang tid det tar fra man begynner å reagere på pakken til LEDen lyser. Denne verdien er minste mulige X, dvs. at maskinen ikke kan gjøre noe annet enn å se etter denne pakken.

Hvis man vil at systemet skal brukes til andre ting også må man vite hvor lang tid det tar, i absolutt verste fall, å sette til side den oppgaven man holder på med i det pakken kommer. Hvis summen av disse to fortsatt utgjør mindre enn 2ms så kan du teoretisk sett drive med multitasking. Forskjellen mellom disse to verdiene er hvor lang tid du kan kjøre den andre oppgaven før du igjen sjekker etter pakke A.

Problemet er at det kan være tidkrevende å hele tiden se etter denne pakken. Bl.a. kan det skje at deler av CPU cachen tømmes i det man bytter oppgave. Så selv om du nå kan garantere at systemet reagerer innen 2ms kan det være at systemet er overbelastet på andre områder. Dvs. at det nesten alltid vil ta rundt 2 ms LEDen lyser.

Hvis du derimot ikke hadde sjekket regelmessig, så er det tenkelig at maskinen får unnagjort de andre oppgavene i god tid, slik at den er klar i det pakke A kommer og kan slå på LEDen med minimal forsinkelse.

Heldigvis finnes det noe som heter interrupts som i enkle tilfeller kan løse problemet jeg beskriver ovenfor. Men PCer er også nødt til å ta flere hensyn, å være real-time på et område er sjelden nok. Hvis du skal kjøre internettradio fra din maskin nytter det ikke at input fra mikrofon prosessereres real-time, du er også nødt til å få komprimert dette og sendt pakken ut på nettverket, noe som igjen kan kreve oppslag i en database på harddisken for å se hvem mottagere er ... og slik fortsetter det.

Low latency handler først og fremst om å prioritere litt annerledes. Hvis man er interessert i snittet så er det langt mindre komplisert enn real-time. En del av det kan sikkert implementeres dynamisk, noe av dette handler om sysctl innstillinger.

Men hvis man skal tune dette maksimalt så må man endre underliggende kode, f.eks. kan man spare tid på å droppe fancy køsystemer og asynkron behandling i områdene man prioriterer. Dette er relativt store endringer, og detaljene avhenger av nøyaktig hva man prøver å oppnå. Uansett er man, i likhet med internettradio eksempelet ovenfor, nødt til å ta noen avgjørelser på tynt grunnlag om hva man vil prioritere.

Håper dette hjelper til med å belyse problemstillingen, ta fremstillingen med en klype salt.