I have to get a machine out the door, but that’s totally worth a try and I’ll give it a test tomorrow.
Thanks! On 3/8/16, 4:29 PM, "etherlab-users on behalf of Gavin Lambert" <[email protected] on behalf of [email protected]> wrote: >[Repost to list due to incorrect email address.] > >On 9 March 2016 05:09, quoth Thomas Bitsky Jr: >> I have tried this on two pieces of hardware. They run the same >> operating system and configuration, same EtherLAB master version, same >> Ethernet driver. >> >> System 1 (Intel i3 NUC, 1 Intel e1000e Ethernet port): exec min 6789 >> .. max >> 50345 (nano seconds) >> System 2 (Intel quad celeoron, 4 x e1000e Ethernet port): exec min >> 15588 … max 323376 (nano seconds) (Both systems: Ubuntu Server >> 14.04LTS, Linux core 3.12.50-rt68 #1 SMP PREEMPT RT) >> >> On system 1, the unmatched packets never happen; for whatever reason, >> those functions are returning much more rapidly. On the second system, >> the worst case happens about once per minute, once every two minutes. >> >> 1. Am I unreasonable in thinking these times are excessive? I >> understand that the system is communicating out to external hardware >> and there will be a delay, but the difference between the two computers is >> surprising to me. >> 2. Is this a consequence of using the EtherCAT master from user space? >> I’ve always used it from kernel space before. However, I’ve never done >> as extensive of timing measurements before. The EtherLAB documentation >> mentioned that the userspace library only added 1 microsecond of >> overhead, if I recall. Is this as good as it gets from the user space? >> 3. Is there a way to address this problem, or is it completely >> dependent upon the hardware? > >I'm not sure if it will help in this case (the issue was discovered when >testing something else), but it might be worthwhile trying this patch: > > http://lists.etherlab.org/pipermail/etherlab-dev/2015/000475.html > >There's some fairly slow watchdog code in the e1000e driver that can execute >synchronously inside ecrt_master_receive. Normally the watchdog is blocked >entirely when the port is receiving packets, but since one of your systems has >several ports (and presumably not all of them are in use) it's possible that >you're being affected by this. The patch pushes the watchdog back onto a >separate worker thread (although it also allows it to run even when receiving >packets, for other reasons). > >As I said, not sure if it will help here, but seems worth a try at least. :) > > >_______________________________________________ >etherlab-users mailing list >[email protected] >http://lists.etherlab.org/mailman/listinfo/etherlab-users _______________________________________________ etherlab-users mailing list [email protected] http://lists.etherlab.org/mailman/listinfo/etherlab-users
