> Hello, > > I was asked to demonstrate RTLinux to research group at the university > (TU-Darmstadt). They are now using proprietery RT OS. > > All wenn well and we had usually about 5us irq latency. The problem > was every now and then the latency got as high as 20-25 micro seconds. > > That is way to much. > > I was running this on a Intel Celeron 300A with ISA timercard giving > interrupt and the IRQ-handler sending one pulse to the Parallel-Port. > RedHat 7.2 with RTLinux 3.1 on Kernel 2.4.4 and KDE. (I know ISA isn't > the best for RT but it shouldn't matter with this test). >
off corse it ill mater for this test - you are blocking the bus with the isa card atleast for a few mycroseconds you can pull the bus to its knees and that means that the entire system is slowing down . > My question is: Is it known what programs/tasks could be blocking > interrupts? Wouldn't it be possible to not run those programs to > guaranty shorter responce time ? > You will have a hard time guaranteeing response imes below 20us if you have ISA cards in the system - this level of response definitly depends a lot on tha hardware you select . > I would apreciate any info. > you could through out the isa card and use the paralell port to demonstrate interrupt response - trigger it on Pin 10 and let the rt-handler answer on D0-D7 that should be well below 20us - but remember that if you have multiple interrupt sources - let say mouse+keybord+harddrive+network+timer-card then there always is the (rare) posibility that they all fire at the SAME time and the interrupt emulation code must be run 5 times befor your handler gets a chance to answer on the parallel port - then the 20us may be hard to guarantee.... This is though a hardware limit that you are hitting not a software problem. hofrat -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
