Jeroen Van den Keybus wrote: > The Etherlab developers are > > obviously not interested in those changes, so I have to maintain > > them myself. > > I'm not sure. They are rather in a continuous state of business, I would > say.
OK, I shouldn't speculate about motivations, but the result to me is the same. > - If I had known and considered all this back then, I might have > > started with other code instead of Etherlab which is already > > userspace based, but has different interfaces (and possibly > > different bugs). > > It is often instructive to review why you made the initial choice. You > could be forgetting important positive arguments. For me, that would > include the fact that Etherlab is a clean, well-structured project which > has a sizeable user group. I suppose so (though I never researched the alternatives too closely -- at the time, RTAI seemed the natural choice and Etherlab was the only one that supported it). OTOH, considering the amount of time (several weeks in total) I spent finding, debugging and fixing the various bugs, I could probably also have gotten one of the alternatives to a useful state, even if they might not have been so clean and well-structured. But all that's academic now. I don't really consider porting my application to another code base. Porting Etherlab to userspace seems much easier in comparison: Most of the changes will (almost :) follow the old saying "if it compiles, ship it", since when replacing/adjusting kernel functionality, compile errors will show immediately what's missing; whereas the complex logic (e.g. my changes WRT mailbox dispatching, but also the master and slave logic of the original code) will stay mostly untouched. > > But as things are now, since my code is tightly > > bound to the Etherlab interface, and well tested with (the patched > > version of) it, it seems easier to port this code to userspace > > than change my application code. > > If it get it correctly, you consider porting your code that is running in > kernel space to user space. I would say that, depending on your platform, > that conversion is a no-brainer and Etherlab has little to do with that. No, I actually plan to port the whole of Etherlab to userspace. That's a little more involved. I think I can handle the interface differences. The only thing I was really unsure about is packet latency (which was of course the only reason to use RTAI in the first place back then). > > - Use the generic backend driver which also shouldn't require too > > many changes since it already uses a raw ethernet socket which is > > also available from userspace). > > The raw ethernet socket has limited zero-copy capability and not every > driver is optimized for it. Do you know which drivers work best with it? (For a fair comparison, I should note that the non-generic Etherlab drivers also limit the choice of network adapters. For me, the only viable choice ATM is e1000; others report rtl8169 works better, but in my initial tests it didn't; though this might have been due to the other bugs I found later; after I found and fixed the bugs in the e1000 driver, it's been working well for me, and I didn't go back to rtl8169. In any case, the choice of network adapters for EtherCAT is quite limited, and as long as at least one popular model is among them, I can live with that.) > It's great (and designed) for capturing massive > amounts of traffic (mostly Wireshark), but low latency was never the > objective. Be warned. Please correct me if I'm wrong, but isn't zero-copy about performance rather than latency? Performance is not really an issue for me (our peak load is well below 1 MByte/s), and a fixed latency overhead due to copying shouldn't matter much either -- in other words, I don't care if the CPU is busy dealing with the network adapter while sending out and receiving packets; it would be idle during this time otherwise; my application code runs in the time between. What worried me more is network packets delayed by other (non-cyclic, unplanned) activity such as network traffic on another adapter, disk I/O, etc., but I did some timing tests which look alright (see my answer to Florian). > I'm trying to convince you to reconsider your choice to fork, because I > think that the choice may not be based on the correct arguments, but also > because Etherlab would benefit from as large a user base as it can get. In > a sense, it is already a niche project as it is. This sounds nice in theory, but in practice my experience has been little different. What good is a large user base? Right, you get more tests, bug reports and fixes. But if those get ignored, well ... Regards, Frank -- Dipl.-Math. Frank Heckenbach <f.heckenb...@fh-soft.de> Stubenlohstr. 6, 91052 Erlangen, Germany, +49-9131-21359 Systems Programming, Software Development, IT Consulting _______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
