Connecting network makes CPU use 100% CPU

When I am using the embedded PHY network and the sample code given in the docs, I get a 100% CPU usage a couple seconds after plugging in a network cable and network link being achieved.

I am seeing the same behaviour when starting a TCP socket gets to this line: (no network link at this moment)

Socket ClientSocket = Socket.Accept();

The same behaviour is once again seen when enabling a CAN controller.

Is all of this expected behaviour? The system seems to be functioning normally. All of this is tested with a SC20100S running the latest preview firmware and latest nuget packages.

We will check.

1 Like


CPU reporting is correct.
There is one thing is not correct yet cause CPU 100%.

Good to have this feature :))

1 Like

Does that mean cpu time has been wasted for the last versions? :slight_smile:
In that case, great feature to have!

1 Like

So, because we can now, I have been doing in depth CPU usage profiling in my code. I found that the Socket.Accept() method still seems to be using a lot of CPU time - at idle, my software is sitting at about 39% (it has a couple of in the background running a heavy CANbus thread and a few serial ports, with controller logic behind the UI, etc) with no sockets open. When i open a socket to listen (in normal use i can have up to 3), each socket waiting for a connection will increase my idle CPU by 10-15% (additive - my idle CPU usage is now 50-55% with one socket). Is this expected? is there any way to free up that CPU time or is that just something I will have to work around and leave headroom for?

Gotta say, this feature is super nice.

1 Like

Accept() is 39%, and doing something with socket 50->55% is normal to us, at least for now :)).

1 Like

Cool, I won’t worry about it then.

This is about what I’m seeing.

Processing 300 can msg/sec, having two tcp sockets waiting for connection and parsing 2 incoming NMEA streams runs at about 55% cpu usage constantly.

This feature is so useful for in depth cpu profiling, it’s amazing.