[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
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users
