Jorge Almeida wrote:
> Hello to all,
> 
> I'm testing the SOCK_RAW functionality in the rtnet framework for long 
> periods of time and a problem is happening.
> I will try to describe it:
> 
> I'm making tests sending 1.000.000 (one milion messages), with an interval of 
> 5 ms each.
> After some time, more than 100.000 messages, the host were the test is 
> running has a strange behaviour, the program does not return but the bash 
> dies. I must make the login phase again to enter the host.
> The messages stop of being sent (I'm monitoring the network with ethereal).
> 
> In the /proc i find some data about the file descriptor used by the socket 
> (/proc/rtai/rtdm/open_fildes)
> Index   Locked   Device
> 0         0            PACKET_RAW
> 
> I think this is OK because the socket was never closed.

Because the sender somehow died I think. But why does the console also
die? That's not a typical program error. Anything on the kernel console?

> 
> But the behaviour is strange.
> My guess is that this problem is due to some kind of semaphore or any 
> synchronization mechanism.

The guess is based on which information?

> 
> 
> Any clues for wath is happening?

Nope.

If there are no signs anywhere, I would first try to run your scenario
over a similar time using some vanilla RTnet version with normal packet
sockets. Have you tried this before? Just to exclude that there are
major stability issues.

BTW, you are on RTAI? What version, patch, gcc?

Jan

Attachment: 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-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rtnet-developers

Reply via email to