Raptor + ENC28 -> Unstable networking?

Archive
1

I have an application running on the raptor, with the ENC28 module as networking interface.

I send out of the raptor 2 message/sec

I receive 3-10 messages by sec (I tried to send every 350ms, 200ms, 100ms).
I use TCP socket.

The system is running for a random time, 3min to 1hour, and after that give me a socket exception :

#### Exception System.Net.Sockets.SocketException - CLR_E_FAIL (16) ####
#### Message: 
#### Microsoft.SPOT.Net.SocketNative::send [IP: 0000] ####
#### System.Net.Sockets.Socket::Send [IP: 0018] ####
#### System.Net.Sockets.Socket::Send [IP: 0010] ####

With the previous G400 firmware, the system has to be electrically cutted-off to restart the system, a reset didn’t brought the network back.
Since the latest firmware, the reset bring the network up.

I tried everything to make it working, changing my code multiple times to ensure that the performances of my processing code didn’t affect the capacity of the G400 to process the IP packets.

I came to the conclusion that the problem is related to the TCP/IP stack.

So, did you get a problem like that ? Is there a known issue ?
Is there some limitations ?

What must I do to pass through that problem ?

Any help would be appreciated !

2

@ GMISoft -

can you show a simple code, please?

3

Sure, here is the socket creation :

 Socket cli = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
  cli.ReceiveTimeout = 10000;
  cli.SendTimeout = 10000;

Message sending (Message is a byte[])






```cs

byte[] buffer = new byte[8 * 1024];

Receive :


public byte[] Receive(out int ReceivedBytes)
{
    if (cli.Available == 0) return null;
    ReceivedBytes = cli.Receive(buffer);

    return buffer;
}

Application is complex, but shortly there is a “receive” thread which put received bytes into a rounding buffer, a “sending” thread who send message and a processing thread which takes bytes from the rounding buffer to process them

4

After long time debugging, I’m sure that the error appears during receive operation exclusively.
The more short is the delay between 2 packet reception, the more quickly the network is crashing.

So, as far as I can analyse the situation, the crash appears when the card is overloaded.

I optimized my code to ensure that no blocking code, or heavy sequence would suspend the execution, since the packet building is done by the mainboard CPU (If I’m not mistaken…)

I relaunched a test sequence today to check if it resolve the problem… I’ll let you know

Something else, I changed the


to

```cs]while (cli.Available == 0) Thread.Sleep(20);[/code


After removing completely that part, it has clearly improve the stability of the network.
5

I didn’t really understand your change that improved things. First you say you changed to a While() + Sleep(), and then you say “removing completely”. What do you mean?

When I see a Sleep() improving things I suspect you’ve got a tight loop that’s consuming processor time and not relinquishing for a different thread to handle some of it’s processing… the forced sleep means the dispatcher gets to timeslice over to another thread. Is your app heavily threaded?

6

Hi Brett,

Thanks for your reply,

There is multiple point :

  1. The application is obviously heavily threaded, but threads are synchronized to avoid an heavy CPU concurrency. Since we can use VS2012, I can easily monitor my threads to be sure they are not running crazy.
  2. The code has been optimized (I clearly don’t mean optimized by adding some Sleep()) but code performance improvement.
  3. I remove the entire block that was looking if there are any bytes available on the socket. It seems that the call to that function is heavy or risky.
  4. Nowhere in my code there is a “while something” that run without releasing the dispatcher.

The only thing that I suspected in a major CPU consumption was a byte array copy (probably 700 byte to copy inside an array for buffer releasing place) It’s running sometimes

This is another part that I removed (the byte array copy) and the system looks more stable.

The point is, that may be we could use a lot of CPU (and I will), but even if I understand that the connection/socket crashes, I don’t agree with the IP stack crash.

As far as the tests are running, It now looks better. It’s not totally stable yet, so I also added a code to “reset” the networking interface.

I hope to get a totally clean networking layer asap

7

So, it seems I finally find the cause of the “unstability”, but may be it’s the normal case, I don’t know…

I explain :

I have a Raptor+Enc28 (no matter what the purpose is), which connect at startup to a TCP server (on Windows).
Raptor send a status message every 0.5 second and the server send messages every 0.25 second.
As soon as you are not in the receive method (because you are processing the received message), if some messages are arriving to the Raptor, your network stack is crashed.

So, no matter the CPU availability (I overload the code with some While(true) Thread.Sleep(1)) the problem is with some buffer (I suppose) related to the network stack.

If you do a socket.Receive on the Raptor after packet are effectively arrived, it seems to crash the ENC28 NetworkInterfaceExtension