>> 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? 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 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.
_______________________________________________ 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
