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. _______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
