> Evert Lammerts wrote:
>
>>> Imre Paniti wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> I'm getting a lot of ENOBUFS while repeatingly sending over 10
>>>> bytes of data data from a fast rt thread (100 packets per second). I
>>>> guess this makes
>>> I wouldn't consider 100 Hz as fast. Is this the correct rate? Or is
>>> the receiver overloaded and does some MAC layer overflow signalling?
>>
>> The rate is correct, and the reciever is probably not overloaded.
>>
>>
>>>> sense - no available buffers. But how does this work internally,
>>>> what happens with a que on a socket (we're using UDP, might a raw
>>>> socket be better?) when writing to it fast? I know we can increase
>>>> the buffer size, but that would only mean it fills up less fast but
>>>> still fills up. So on
>>>> the practical side of things, what can we do about this -105?
>>>>
>>>> We're using:
>>>> RTAI-3.3-CV
>>>> RTnet 0.9.3
>>>>
>>>>
>>> With or without RTmac? If /wo RTmac: which NIC driver? Switched
>>> Ethernet?
>>>
>>
>> This is lsmod after a simple start-up routine of RTnet:
>>
>>
>> emc2-2:~# lsmod
>> Module                  Size  Used by
>> tdma                   14852  1 rtmac                   8976  1 tdma rtcfg
>> 37168  0
>> rt_loopback             2564  1 rt_8139too             11776  2 rtpacket
>> 4352  0
>> rtipv4                 21536  1 rtcfg rtnet                  29292  7
>> tdma,rtmac,rtcfg,rt_loopback,rt_8139too,rtpacket,rtipv4 rtai_rtdm
>> 16676  6 tdma,rtcfg,rt_8139too,rtpacket,rtipv4,rtnet
>> rtai_sem               15232  4 tdma,rtcfg,rtnet,rtai_rtdm rtai_up
>> 71736  8
>> tdma,rtcfg,rt_loopback,rt_8139too,rtipv4,rtnet,rtai_rtdm,rtai_sem
>> rtai_hal               29176  6
>> rtmac,rt_8139too,rtnet,rtai_rtdm,rtai_sem,rtai_up
>>
>> This means RTmac is used (right?). As you can see we're using a realtek
>>  8139 NIC.
>>
>>
>>>
>>> There are at least two error sources involved when sending out
>>> packets:
>>> first the per-socket pool of rtskbs that is charged when the outgoing
>>> frames are to be build. Later the NIC may report an overflow (EAGAIN)
>>> of its own hardware TX queue - unless you are using RTmac as flow
>>> control manager. This is true for both UDP and packet sockets.
>>
>> So I guess this means the error comes from rtskbs, because we're using
>> RTmac? If so, then what does that mean?
>>
>
> This means now that you do not provide enough bandwidth to your
> transmitter, thus it enqueues more packets then there are transmitted and
> runs out of buffers sooner or later.
>
> How does your TDMA configuration look like (see also
> /proc/rtnet/rtmac/tdma*? And how many other senders are sharing the
> transmission time slot(s) of the particular box?

There's only one sender.

I think I understand what you're saying. Stupid enough I didn't yet put
time into TDMA configuration - but I guess the error has to do with this
(?):

# Master parameters

# Simple setup: List of TDMA slaves
TDMA_SLAVES="192.168.1.100"

# Simple setup: Cycle time in microsecond
TDMA_CYCLE="5000"

# Simple setup: Offset in microsecond between TDMA slots
TDMA_OFFSET="200"

# Advanced setup: Config file containing all TDMA station parameters
#   To use this mode, uncomment the following line and disable the
#   three master parameters above (SLAVES, CYCLE, and OFFSET).
#TDMA_CONFIG="${prefix}/etc/tdma.conf"

The cycle time should be a lot faster, I guess? What about the offset? Or
do you recommend using the advanced set-up? If so, is there some
documentation around on that?

Thanks a bunch! It's great to have such easy and efficient communication
and support.

Evert

>
>>
>> It might be useful for you to take a look at my code. However, this is
>> for a module for CNC software (Enhanced Machine Controller 2, EMC2) and
>> it uses a custom RT API in combination with the RTnet and RTDM API,
>> which makes it a little harder to read. Apart from that, in the actual
>> functions that are exported as RT tasks, nothing really strange happens
>> - a socket
>> is created during module start-up, the RT tasks only either create
>> packets and send them or recieve packets and disect them.
>
> In fact, your problem should be independent of the actual application
> code.
>
> Jan
>
>
>


-- 



-- 
SMTP-server Noordelijke Hogeschool Leeuwarden.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users

Reply via email to