>From: Jan Kiszka <[EMAIL PROTECTED]> >To: Monotosh Das <[EMAIL PROTECTED]> >CC: rtnet-users@lists.sourceforge.net >Subject: Re: [RTnet-users] Revceiving UDP/IP data in user space using RTAI >LXRT >Date: Fri, 19 Jan 2007 21:24:57 +0100 > >Monotosh Das wrote: > > Hello jan, > > Thank you for your prompt reply. > > > > As mentioned by you I have turned on the Internal Debug flag in the > > configuration and rebuild it.... and the application started working > > (atleast started sending and receiving data with the Winsock program > > with running on a windows PC). > > Following message was printed in the kernel log... > > "Assertion failed! > > /usr/src/rtnet-0.9.8/stack/ipv4/udp.c:rt_udp_recvmsg:398 skb != NULL". > >Uhh, that's not nice. It means that the socket got the clear signal that >there should be some data in its queue, but it isn't. Either we are >loosing data in the socket queue, or the underlying rtdm_sem is somehow >broken.
So what do you suggest? should I try any older version of RTnet? > >Do you already get this for the very first run (or with pulled cable) >when there can't be any packet in the queue? It was mainly noticed when there was no data atall. That is windows brother is not running... When the socket starts receiving data this message is hardly apearing... > > > So my conclusion is that we have to turn on this flag during >installation. > >...at least when something fishy is going on (like an oops). Still, this >assertion never triggered anywhere yet, and most involved RTnet code is >fairly matured (disclaimer: personal believe). > > > > > I have observed following non real-time characteristics.... > > 1) The rtnet socket loses some initial data. > > 2) It is loosing Data in alternate cycles.... on this point I am not > > giving that much stress before I could point out the actual culprit... > > it may be the windows brother who is not delivering data on time... or > > may be the sampling time of the rtai is varying... > > 3) Even after closing the application in the windows side, the rtnet > > still receives 16 packets.... > >Might all be related to the core issue of queuing and signalling arrived >packets. Let's concentrate on the bug that is screaming loudest. > > > > > I require following help from you... > > is there any clue how to specify the wait period in the receive socket? > > presently it is operating in Non Blocking mode..... > >Well, to check if it's an issue with non-blocking mode for the socket, >try using a small timeout (e.g. 1000 ns). That should fire immediately >if there is no packet pending, practically giving the same behaviour. >The polling period must not have any influence (except that you will run >into overflow/packet drops if the remote station keeps sending faster >than you poll). > >Moreover, you may want to attach a packet sniffer to the link between >the Windows and the RTnet box (a hub is required then to grab unicast >traffic), or use RTcap on the RTnet box (see READMEs). The latter has >the advantage that we see which packets made it to the RT-NIC, the >former would also capture potentially dropped frames - comparing both >will reveal this. > >Jan > ><< signature.asc >> _________________________________________________________________ Spice up your IM conversations. New, colorful and animated emoticons. Get chatting! http://server1.msn.co.in/SP05/emoticons/ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
