Gilles Chanteperdrix wrote: > Bernhard Pfund wrote: >> Gilles Chanteperdrix wrote: >>> Bernhard Pfund wrote: >>>> [EMAIL PROTECTED] wrote: >>>>> Zitat von Gilles Chanteperdrix <[EMAIL PROTECTED]>: >>>>> >>>>>> Bernhard Pfund wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> I have some strange behaviour here. When I try to run a periodic task >>>>>>> sending small packets at 10kHz over an UDP socket, after some few cycles >>>>>>> I get ENOBUFS. I can play with rtskb pool size, which extends the number >>>>>>> of successful cycles, but I have the feeling that there's no >>>>>>> housekeeping taking place. >>>>>>> >>>>>>> Funny enough I could run the very same code for hours before I updated >>>>>>> to the latest code base of Linux, RTnet and RTAI. >>>>>> Hi, >>>>>> >>>>>> I do not know if this is your issue, but I had problems of this kind >>>>>> once. My problem was that my application was sending packets but never >>>>>> receiving, and it happened that somehow, the network sent packet to the >>>>>> port automatically allocated by rtnet. So, the received packets were >>>>>> exhausting the socket buffers. >>>>>> >>>>> Salut Gilles >>>>> >>>>> That might be the issue. I deactivated the receiver thread for test >>>>> purposes... I'll re-activate it and see what happens. Thanks a lot for >>>>> the hint! >>>>> >>>>> Bernhard >>>> All, >>>> >>>> Gilles's hint was straight to the point! It works again... >>>> >>>> Thanks Gilles, Jan and Paul for the valuable feedback! >>> Ok. I am afraid I will make myself ridiculous with a stupid idea, but I >>> dare anyway: why using not using a different pool for sending and >>> receiving ? >>> >> Well, that could be caused by my infinite ignorance in not knowing how >> to accomplish that :) I have a separate send and receive buffer in my >> userspace application, for the rest I put all my faith in RTnet... >> >> Or was that the direction you aimed at? > > It was rather a question directed to Jan: I was proposing to use two > different pools for RTnet housekeeping.
Possible, but would increase the memory requirements of every app. Or what defaults would you suggest for those buffer pools? In the end the problem is (once again) unpredictable traffic on the wire, no? That's usually a sign of a deeper problem. Anyway, there are a few approaches to improve the situation without patching RTnet: - increase the buffers of the socket (see RTNET_RTIOC_EXTPOOL ioctl in existing examples) - this only makes sense if you can actually predict the packet peak your system has to handle - dedicate a separate socket to sending messages - this only works if RX and TX ports can be different Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
