From: serdarkoylu@fisek.com.tr
Date: Wed 17 Aug 2005 - 16:36:18 EEST
Selamlar..
On August 17, 3:20 pm "Omer F. USTA" <usta@bilisimlab.com> wrote:
> Merhabalar
>
> >
> > Öncelikle bu kod nerede? User Space? Kernel vs.
> >
>
> Kod user space içinde çalıştırılıyor acaba nice ile
> bunun önceliği arttırılırsa süreyi düşürebilir miyim ?
> veya olayı bir derece daha ileri kernel boyutuna nasıl sokarım ?
>
> Bildiğim kadarıyla bir outp işlemi 8t lik kadar zamanda
> tamamlanıyorsa bunun 2t den sonraki kısım delay kısmı yani
Sanırım komutun clock-cycle cinsinden süresini kastediyorsun. outp/inp
birer makro. Assembly seviyesinde bu komutların herhangi bir delay'e sahip
olmaları söz konusu değil. Fakat, outp gibi komutlar, out op-code'un
ardından bir bekleme çevrimi eklerler..
> parazit filan olur ben bunu biraz daha tutayim diye devam edilen
> kısım. Ben hadi diyorum bu 8t nin yarısını kırpamaz mıyım ?
> yani 4t süreye indiremez miyim bir outp yi ?
Bu 8t süresi (CPU Model, marka vs. göre değişebilir) CPU'nun işi
yapması için gereken saat çevrimi. Bu değişmez.
> Birde pp normal modda çalışıyor şu anda ecp ye alırsan
> bu süreyi aşağı çekmemde yardımcı olur mu ?
Sorunlar bu kadar basit değil. 800 ns periyot, 1 MHz gibi bir hıza
tekabül eder. Paralel port donanımının bu hızda bağlı olduğu
devreyi sürmesi pek beklenmez. Portun çıkışındaki filter sistemi,
kablonun yükü vs. derken, oluşan kapasitif yükün portun yüksek
içdirenci üzerinden dolması için gereken süre bu süreden daha uzun
olabilir. Bu konuda anakarta, SuperIO chipsetine vs. bakmak lazım. Bu
portlar bu tür yüksek hızlar düşünülmüş şeyler değil.
Bu donanım tarafı. Yazılım tarafından bakalım..
outb(value, port);
wait_for_ns(800);
outb(value, port);
Gibi bir sözde kodumuz olsun. wait_for_ns, basitçe şöyle implement
edilsin:
curr_time = tsc_read() + ns * JIFFIES;
while (tsc_read() < curr_time);
return;
İşte tam tsc_read()'dan dönüldüğü anda ekran kartı tazelemenin
bittiÄŸini, RTC 1/18 sn.lik peryodun dolduÄŸunu vs. bildiren bir IRQ
üretir, CPU eli mahkum gider IRQ service rutininde bir şeyler yapar.
Yani, scheduler'i kapatsanız bile kesmeler bu hassasiyetten sizi
uzaklaştırır.
Çözüm kesmeleri kapatmaktır, "CLI/STI" miydi neydi, öyle bir opcode
vardı..
BU yüzden bu tür zamanlamanın olası tek yeri kernel. Fakat, IRQ'leri
maskelediniz mi, sistem donar kalır.
Çözüm, bir watchdog kurmaktır. Bunun sonucunda sisteme uygun zaman
sonra kodun devam etmesini istersiniz. Bu bir yere kadar çözüm
olacaktır. Yani asenkron çalışma. Ama Linux gibi genel amaçlı bir
kernelde, PC gibi bu işler için olmayan bir mimaride, ns. hassasiyetinde
watchdog olması biraz zor.
Ben olsam, paralel porttan inhibit edilebilen bir osilatör/multivibratör
yapardım. Paralel porttan onu kumanda eder, bu zamanlamayı ona
yaptırırdım. Hatırladığım kadarıyla, processor'ün /IOW hattını
aktif etmesinden, datanın çıkıştaki latch'lere yazılması için en az
200 ns filan gerekiyordu. Buradan sinyalin hatta ulaşıp karşı cihaza
ulaşması ne tutar bilmiyorum.
Bunu yapamıyorsam, kernel üzerinde, bilhassa relatime patchleri olan bir
kernelde, set_timer_nsec() gibi fonksiyonlarla çalışmak bir çözüm
olabilir.
Buraya bir bakın, sanırım fikir verecek bir şeyler bulabilirsiniz..
Saygı ve sevgiler..
_______________________________________________
Linux-programlama mailing list
Linux-programlama@liste.linux.org.tr
http://liste.linux.org.tr/mailman/listinfo/linux-programlama