[etherlab-dev] Userspace fork of Etherlab
Gavin Lambert
gavinl at compacsort.com
Sun Jan 18 23:39:15 CET 2015
On 17 January 2015 02:00, quoth Frank Heckenbach:
> My result was that with very small packets, I can get cycle times of
1500ms
> without overruns. As the size of the packet (or packets if larger than
MTU)
> per cycles increases, so does the cycle time to run reliably, and with
really
> large packets I can get cycle times such that a bit more than 50% of
> theoretical bandwidth is used in either direction (which seems quie
> reasonable since it's what I've experienced and seen recommended for other
> communication protocols, and it also proves full-duplex works, otherwise
no
> more than 50% would be possible).
>
> Our project runs at 2000ms (500Hz), and at that rate, I could get packets
of
> 5KB/cycle without overruns which is way above what we require. So the
> userspace port will only be for "slow" cycles (up to 500Hz), but that's
what
> we need. Maybe in a few years, the standard kernel's RT features will
improve
> and the userspace code will allow for faster cycle times without many
> changes.
I assume you meant microseconds here, which are usually shortened to µs or
us, not ms (which is milliseconds). Cycle times of 1500ms would be quite
bad for most applications. :)
> I know about the userspace library. But moving to userspace is not my main
> goal. My main goal is better maintainability for my application, and
getting
> rid of kernel dependencies is a step towards this goal. Using the
kernelspace
> Etherlab code with a userspace application wouldn't help in any
significant
> way since I'd have the same amount of kernel dependencies (my application
> does not contain many).
Given that one of your requirements (judging from your previous patches) is
EoE support, that might be tricky without kernel support.
More information about the etherlab-dev
mailing list