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. Do you already get this for the very first run (or with pulled cable) when there can't be any packet in the queue? > 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
Description: OpenPGP digital signature
------------------------------------------------------------------------- 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
