[etherlab-users] Distributed Clocks

[Thomas Bitsky Jr]

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" <etherlab-users-bounces at etherlab.org on behalf of gavinl at compacsort.com> 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
>etherlab-users at etherlab.org
>http://lists.etherlab.org/mailman/listinfo/etherlab-users