sslug-teknik team mailing list archive
-
sslug-teknik team
-
Mailing list archive
-
Message #53860
Re: low latency for linux
On Wednesday 14 August 2002 08:17, you wrote:
> Hej derude
>
> Jeg har nogle spørgsmål om hvordan man får den lavest mulige (konsistente)
> latency under linux,
> håber der er nogle derude som kan/vil hjælpe...
>
> Jeg har nu fået kompileret et 2.4.19 kerne med lowlatency patches til
> 2.4.19pre10, og det booter ihvertfald.
> Men er det i orden at bruge et low latency patch til 2.4.19pre10 på en
> 2.4.19 final kerne ?
> Eller er jeg nødt til at bruge præcist den samme kerne som patchet er
> skrevet til ?
>
> Jeg benytter for at undersøge latency et modul skrevet af folkene bag
> linux device drivers second edition. Modulet registrerer sig på
> parallelporten og ekkoer
> alle bytes man sender til det videre til parallelporten. En lus i denne gør
> så at der
> genereres et interrupt, som aktiverer modulet igen. En streng med timeofday
> kan nu læses
> fra modulet. I mit test program har jeg nu 2 threads, 1 som med ca 125 us
> mellemrum skriver
> til modulet, og i den anden thread læser jeg fra modulet.
> Så sammenligner jeg den aktuelle tid med den streng som er læst fra modulet
> og forskellen
> kalder jeg min latency.
> I en standard 2.4.18 kerne får jeg typiske latencies på 4-5 us, men en gang
> imellem
> får jeg tider i millisekund størrelsen (lad os sige 10 - 20 ms).
> Det er ikke acceptabelt til det jeg skal bruge så jeg fandt et site med low
> latency patches.
> Desværre kunne jeg altså ikke finde et til hverken 2.4.18 eller 2.4.19
> derfor spørgsmålet ovenfor.
>
> Hvis det er ok det jeg har gjort med patchet, kan nogen så svare mig på
> hvordan jeg aktiverer
> low latency ?
> Da jeg compilede valgte jeg foruden low latency understøttelse, at aktivere
> kontrol via syscontrol,
> men vil det sige at jeg default ikke kører low latency ? og hvis det er
> tilfældet hvordan slår
> jeg det så til ?
>
> Uden at gøre noget er det ikke
> vildt imponerende hvad jeg har opnået (faktisk ingen forskel) idet jeg
> har målt 2.5 ms som worst case i første forsøg over ca 2 minutter (1 mill.
> interrupts)
>
> På sitet med low latency patchene stod der at man kunne opnå worst case
> latency på 0.5 millisekunder,
> hvilket netop er hvad jeg har brug for. (det kan jeg lige akkurat leve med)
> så noget har jeg gjort galt,
> men hvad ?
>
> Mvh Lars
Hej Lars
Linux er ikke et hårdt realtids system men et blødt realtidssystem, hvilket
vil sige at der ikke er garenterede svartider i systemet. For at få
garenterede svartider er du altså nødt til at bruge et hårdt realtids system
og heldigvis er der lavet et sådan til (næsten da) Linux. Årsagen til (næsten
da) er at Linux delen blive et "task". Realtids kernen har så 100% magt over
interrupts osv, som den i givne tilfælder sender videre til Linux tasket som
et software interrupts. Realtidskernen kan på et hvilket afbryde afbryde
linux tasket hvis det måtte være nødvendigt. Med alt menes _alt_ også
interrupts routiner i linux, disse er simpelthen blevet isoleret ved at alle
registre i CPU'en er lavet om til software registre i Linux tasket, hvorfor
Linux tasket ikke kan se at det er blevet afbrudt. Det har desværre den
sideeffekt at det få fatale konsekvenser hvis en funktion fra LInux tasket
kaldes direkte fra et realtids task. Kaldet skal typisk gennem et andet lag
først.
Jeg kender ikke den low latecy patch, men det virker ikke på mig som hård
realtid. Det vil den ikke være hvis tasket bliver styret af schedularen under
Linux.
Systemerne med hård realtid hedder RTLinux og RTAI. (der er flere)
RTLinux og RTAI er frigvet under GPL2 og kan hentes fra :
http://www.fsmlabs.com/community/
http://www.aero.polimi.it/~rtai/
RTAI er frigivet under GPL1 og må siges at følge GPL tanken noget mere. Til
gengæld er dokumentationen til RTLinux ret god. Deres virkemåde er stort set
identisk.
Begge systemer garentere en max latency på omkring 10uSec. Det er dog meget
afhængig af den hardware der anvendes. Der har været tilfælde hvor et
grafikkort har øget latency med omkring ca. 7uSec
--
-o) Anders Gnistrup
/\ agn@xxxxxxx
_\_v
Do not fear the pinguins.
Follow ups
References