Grant Edwards wrote:
My guess is that the latency is due to delays in the user
thread being woken.
It would be great to know if that is true by creating a test case that
wakes the user thread by some other event.
If the latency is mainly imposed by the network stack, a great
improvement could be achieved by a "zero-copy-stack".
The delay due to copying network packets should be constant.
Not necessarily. It might impose a constant factor, as something that
interrupts the copying might delay it. So bursts of high priority events
would create a varying delay that would be reduced by zero-copy
operation. But I have no idea if this is a realistic cause for the delay.
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.
I do suppose that you assigned a high "realtime" priority to your user
land task so that time slices can't do harm to it...
-Michael
_______________________________________________
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
