From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <46C09B86.3030709@domain.hid> Date: Mon, 13 Aug 2007 19:57:26 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <46C02829.9020009@domain.hid> <46C04384.4030805@domain.hid> <46C05180.5090302@domain.hid> <46C05690.2010108@domain.hid> <46C063E0.1010809@domain.hid> <46C07005.8000504@domain.hid> <46C07EDC.4040305@domain.hid> <46C08D64.4050903@domain.hid> <46C09773.5070607@domain.hid> In-Reply-To: <46C09773.5070607@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0A5E6D8FEA83E79C8A8C56F7" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-help] [Ethercatmaster-users] EML conflict with RTCAN? low_level_input framebuilding failed. List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: rolandtollenaar@domain.hid Cc: Xenomai-help@domain.hid, EML users , rtnet-users This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0A5E6D8FEA83E79C8A8C56F7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Roland Tollenaar wrote: > Hi Jan, >=20 >=20 >>> thus network buffer allocation is ought to run >>>> against the real-time rtskb pool - which is by default empty :p. See= >>>> README.pools from the RTnet documentation on this. > I read this documentation. Together with an archive email of this list = I > understand that if I load rtnet.ko like >=20 > insmod rtnet.ko rtskb_cache_size=3D64 >=20 > (for the benfit of other poor souls in the future :)) >=20 > it should help. And it does make a huge difference. Now instead of not > giving a problem 1 out of 5 times its more like giving a problem 1 ever= y > 10 times. >=20 > The 64 is a value I got from the mailing list. How large can I make thi= s > and what am I compromising? Each buffer is slightly more than 1.5 KB heavy. Do your maths :). How many buffers you need depend on how many incoming and outgoing frames might be queued into they are processed. And that depends on the frame rate and the time your EML stack has to handle it in the worst case. I can't give you numbers on this, that depends on _your_ setup. >=20 >=20 >>>> I don't have the EML design at hand, but you might be able to avoid >>>> this >>>> by initialising before creating the shadow task or by explicitly >>> In fact this is what I tried initially. IT does not work at all. so I= >>> ended up initializing in the thread. Problem? >> >> Not necessarily. But it would have been nice to report the other issue= >> as well, because maybe there is something to be fixed (either in the >> code or in the docs). Initialisation almost always happens in non-RT >> context, and you shouldn't be force to do this under RT constraints. I= f >> this is an RTnet and/or EML problem, please report it on the related >> lists! > Will do so with your compliments and regards. :) I tried to initialize > like I initialize rtcan in non-rt but it really does not work. That sounds like a bug - of what component soever. >=20 >=20 >> Did you set the rtskb_cache_size module parameter for the rtnet.ko? Di= d >> you choose it appropriately large so that buffer pool do not exhaust i= f >> RTnet is blocked by other system activity? Again, check the >> documentation. > As stated, this seems to mitigate the problem. What is not clear to me > is why the default of the rtskb pool is zero? Because you _normally_ don't need it and would thus wast the allocated memory. Jan --------------enig0A5E6D8FEA83E79C8A8C56F7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGwJuHniDOoMHTA+kRAjXBAJ9TWTVtppUoPEddBsLrLi2R/r/qTACfTihi 8Jh21bC9atuvk3JLvUAQebU= =HBA1 -----END PGP SIGNATURE----- --------------enig0A5E6D8FEA83E79C8A8C56F7--