[LUGOS-PROG] Milisekundni stevec

[Miroslav Jurkas]

Metod Kozelj wrote:

>
> Howdy!
>
> davorin.robba at ensico.si wrote:
>
> > Zal morajo biti vsaj milisekunde. Na majhnem kontrolerju (PC baziran 
> na 486) smo razvili aplikacijo (napisana v C/C++), ki tece na linuxu. 
> V aplikaciji rabimo milisekundni cas za sinhronizacijo in racunanje 
> timeout-ov.
> >
>
> Se bojim, da bos tezko prisel skozi z milisekundami. Sicer je odvisno od
> HW platforme, ampak za ix86 je resolucija sistemske ure 100HZ
> (asm/param.h; pri alfah je bodisi 1024 ali pa 1200 Hz). Najbrz obstaja
> kaksna sistemska funkcija, ki ti vrne vrednost uptime, v skrajni sili pa
> jo preberes iz /proc/uptime. Spodaj je en primerek takega programa ...
> za odpiranje /proc/uptime, branje in zapiranje je poraba med 200 
> (P4-1.7G)
> in 2000 (P-100M) mikrosekund. Rezultate mi vraca v desetinkah 
> milisekunde,
> ampak mocno dvomim, da je taka natancnost relevantna.
>
> Druga moznost je branje casa iz CMOS ure. Sicer se jo da tudi
> spreminjati, ampak je to malo manj verjetno ... Poglej si
> */mc146818rtc.h za opis funkcij ... se mi pa zdi, da v tem primeru
> (zaradi outb, inb) potrebujes sistemske privilegije.
>
Mogoc(e ae manjae pojasnilo (glede na to, da z Davorinom delava na istem 
projektu). Milisekundno bazo potrebujemo zaradi obstojec(e 
implementacije naaih timerjev (SW timerji v compatibility knji~nici - 
naai, ki izvira iz RTOS-ov, OS/2 in Winsov). Natanc(nost 1, 5, 10, 20 ms 
je precej irelevantna v konkretnem primeru, kvec(jemu resolucija 1ms. V 
bistvu potrebujemo free running counter, ki v enem long-u ateje 
milisekunde ali kaj podobnega (tako, da potem naai timerji nesejo cca 24 
dni) in je od trenutnega svetovnega c(asa neodvisen.
Problem je nastopil zaradi tega, ker smo kot vir za prerac(un v 
milisekundno bazo uporabili clock_gettime() in ga ustrezno prerac(unali. 
Ta c(as je real (World) time in se seveda spremeni po c(asovni 
sinhronizaciji, kar ima na timerje po izvedeni sinhronizaciji 
katastrofalni uc(inek.
Sicer delamo s knji~nico ACE, ki ima tudi svoje timerje in glej ga 
zlomka, na 486 se ti napajajo iz istega vira... Nekje sem nekaj prebral 
o kernel timerjih, pa nisem pivsem razumel... Najbr~ je to vezabo na 
scheduler neposredno in s tega vira se najbr~napaja tudi select() pri 
socketih.
Na pantium-u ni nobenega problema, ker je na voljo TSC register...
Naai timerji morajo biti kar se da hitri (smejo porabiti le malo c(asa), 
odpiranje in zapiranje skozi file system zato pac( odpade. Ta c(as se na 
enem segmentu uporablja tudi za sinhronizacijo med procesi, zato mora 
biti izrac(unljiv na za vse procese enako.

Aplikacija, ki tec(e na 486 je RTU (remote terminal unit), ki deluje 
tudi kot pretvornik protokolov s procesnimi zmo~nostmi. Aplikacija je 
multi-threaded (pthread library). Sistem ima hard real-time ekstenzijo 
(od FSM labs), znotraj katere poskrbimo za zajem in upravljanje 
neposredno prikljuc(ene periferije. Napravi periodic(no sinhroniziramo 
c(as in v tej toc(ki je prialo do problema.

Najbr~ bomo morali celovito spremeniti implementacijo naaih timerjev (~e 
zaradi ~ivljenja v prihodnjosti), kar pa za sabo povlec(e spremembe in 
testiranje kupa ~e delujoc(ega programja.


Lep pozdrav
  Miroslav

-------------------------------------------------
** ENSICO d.o.o. www.ensico.si                 **
** miroslav.jurkas at ensico.si                   **
** project manager & unix system administrator **
-------------------------------------------------