On 2008-11-21, Dave Meador <[EMAIL PROTECTED]> wrote: > >>> When the board is running uClinux it sometimes responds in >>> 1.8ms, and sometimes takes 8ms. When running eCos (which >>> doesn't have zero-copy network stack), the response is always >>> between 1.7 and 2.0ms. So, my conclusion is that the extra >>> time (up to 6ms) is probably the time it takes for the >>> scheduler to wake up the user task. >>> >> Sounds likely indeed. So we need to find out what event might >> introduce such a delay. This would be bad for other soft realtime >> tasks as well. It would be nice to see if it really happens without >> Ethernet transfer and it it is seen only in user land or with drivers >> as well. > > What ethernet driver are you using?
The one in the uClinux distro from Altera. > Perhaps you could survey the driver code to make sure there > are no 'features' which might delay/prevent reception of > packets. Just a thought. I read through it a couple weeks ago and didn't see anything that looked likely to delay packet reception. I'll look through it again. > I recall that I spotted some code in a 3com driver a while > back which masked RX interrupts for a short time when > receiving too many interrupts too fast. I believe that this > was to prevent CPU starvation and denial of service type of > conditions. It doesn't do anything like that. I should try to figure out how to wake a user thread from a HW timer to see if the latency is in the scheduling of the thread. -- Grant _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
