[etherlab-users] [etherlab-dev] Datagram SKIPPED x Times

[Andreas Stewering-Bone]

Hello Mike

Please use ether etherlab-user mailing list for such things.


Am 22.03.2012 00:17, schrieb Mike O'Connor:
> Hi Andreas
>
> Yep 4K is no problem is higher that is a problem. We have 2 bus 
> couplers in a daisy chain on my test rig, and 4 IO modules.
>
Very small system.

> I'll try a different card soon, but I've used both the generic and non 
> generic Intel drivers with no different in the possible rates.
>
If you use the same card (Intel) there will be no difference, because it 
is the same firmware on the card, which is the reason for the problem.

> 4K works great doubling it to 8K the SKIPPED goes though the roof, as 
> I said I've confirmed the bus coupler is not an issue the issue is the 
> PC not doing the right thing with the packets.
>
> I just really want to now what sort of rate could be achievable with 
> etherlab. The packet captures I've seen seem to indicate that the bus 
> couplers are able to run a very high rate. (ie at least 25K)
>
I ran userspace (preempt) targets with up to 10k, 20k is also possible, 
depends a little bit on your computer.



Greatings

Andreas

> Mike
>
>
> On 21/03/12 11:13 PM, Andreas Stewering-Bone wrote:
>> Hello Mike,
>>
>> The max rate depends on your bus topology (Number of Slaves, Number 
>> of EKXXX modules).
>> Generally 4K should be no problem.
>>
>> But if you have the possibility, please do not use Intel cards, try a 
>> stupid Realtek card.
>> Intel cards are known to have some freatures which can make some 
>> trouble at higher rate.
>>
>> Do not use the generic interface for such rates, please use the 
>> native drivers.
>>
>> Greatings
>>
>> Andreas
>>
>> Am 21.03.2012 13:25, schrieb Mike O'Connor:
>>> Hi All
>>>
>>> I have been testing with Etherlab and a small number of Beckhoff 
>>> Digital
>>> IO, the Ethercat (not Etherlab) technical data seems to indicate 
>>> that an
>>> updates at a rate of at least 30 micro seconds for up to 1000 IO points
>>> (possibly faster for smaller numbers) is possible.
>>>
>>> I adjusted the user land examples to work with our IO and then started
>>> increasing the frequency and found that at 4K I get no issue (maybe a
>>> couple of the dmesg messages below at the start)
>>>
>>> [  412.872048] EtherCAT WARNING: Datagram f6bbfc00 (domain0-0) was
>>> SKIPPED 6 times.
>>>
>>> but as I increase the rate to 8K then 12K and finally 25K the number of
>>> SKIPPED gets larger and larger
>>>
>>> [173178.785515] EtherCAT WARNING: Datagram f6851360 (domain0-0) was
>>> SKIPPED 43476 times.
>>>
>>> I did adjust the intel GigE driver (e1000e) to use a
>>> InterruptThrottleRate of 0 which helped a lot with consistency. I also
>>> tried the non generic drive with no change in the above messages.
>>>
>>> I've confirmed via a mirror port on a switch and a capture of the
>>> packets that the IO is replying to every packet we send and that the
>>> rate of sending would seem to match the 8K, 12K, and 25K.
>>>
>>> This seems to indicate to me that the issue is in the Ethercat master,
>>> is etherlab up to the task of running a high scan rate ?
>>>
>>> Thanks
>>> Mike
>>>
>>> _______________________________________________
>>> etherlab-dev mailing list
>>> etherlab-dev at etherlab.org
>>> http://lists.etherlab.org/mailman/listinfo/etherlab-dev
>>
>>
>> Mit freundlichem Gruß
>>
>> Andreas Stewering-Bone
>>
>


Mit freundlichem Gruß

Andreas Stewering-Bone

-- 
------------------------------------------------------------------------

Dipl.-Ing.(FH) Andreas Stewering-Bone
andreas.stewering-bone at igh-essen.com
Tel.: +49 201 / 36014-15

Ingenieurgemeinschaft IgH
Gesellschaft für Ingenieurleistungen mbH
Heinz-Bäcker-Str. 34
D-45356 Essen
Amtsgericht Essen HRB 11500
USt-Id.-Nr.: DE 174 626 722
Geschäftsführung:
- Dr.-Ing. S. Rotthäuser,
- Dr.-Ing. T. Finke,
- Dr.-Ing. W. Hagemeister
Tel.: +49 201 / 360-14-0
http://www.igh-essen.com

------------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20120322/3faa00c3/attachment-0003.htm>