Are there socket ciount limits on the Teensey 4.1?

D

dgnuff

Active member
I'm currently working on a project, and I'm using a Wiznet 5500 for ethernet connectivity. I'm becoming increasingly unhappy by the constraint imposed by that chip where it only allows 8 sockets open at once.

For a number of reasons, not the least of which is the additional CPU horsepower, I'm strongly considering porting the project to a Teensey 4.1. However, that has me curious to know how constrained, if at all, the Teensey 4.1 is with regard to count of open sockets.There is going to be an upper limit somewhere, but if it's anything greater than 64, I can effectively ignore it for this application.

Can anyone provide any insight into what I can expect in this regard?

Thanks!
 
Last edited:
Number of sockets is purely a software limitation, not hardware.

QNEthernet for Teensy4 defines the number of supported sockets in a header file so the maximum can be adjusted before compiling.
 
The ethernet hardware on Teensy 4.1 uses a ring buffer and bus master DMA, similar to traditional ethernet on PCs. So in theory you can have any number of sockets. But as a practical matter you'll be working with the internal RAM for packet buffers, which comes in two regions of 512K. You can probably use most of RAM2 for buffers, if your program is able to do the rest within RAM1.

W5500 has 32K, which is the main reason Wiznet designed it for 8 sockets max.

So as generic guidance without knowing anything about your application or network protocols, one generic way to compare the simultaneous sockets capability of W5500 vs Teensy 4.1 would be 32K versus ~450K. Ultimately the internal RAM will be the limiting factor, so a realistic expectation would be about 10X to 15X more than W5500, but not on the scale of a traditional PC where RAM is measured in gigabytes.
 
Thanks for the replies.

In practice, I should be able to comfortably fit in 32 total sockets. If I read the source from the Github repo correctly, the default is 8 each UDP, TCP listening and TCP connected. I can easily get by with 16 TCP connections, leaving the other two at 8 each, giving the total of 32.

The other thing that I'm really looking forward to is the performance improvement that the ring buffer and DMA will bring.

To provide a little insight, I'm trying to fit a smarthome controller on a microcontroller. Thing HA or Hubitat to get some idea of what I'm doing.

So the socket requirements are as follows: UDP is handled through just two sockets, one "listening" for incoming data, and a second one that handles all outbound traffic. The outbound traffic socket maintains a std::map that links remote address with "interested parties" that want to receive replies. Thus when I call recvfrom to get an inbound packet, I can check the packet's source address against entries in the std::map and figures who to forward the reply to.

There are just two TCP listening sockets: one on port 80 for incoming http:// calls to perform various actions, and one for a custom protocol that the controller uses.

Everything else is a TCP connection. Either an outbound connection, usually an http:// call to an endpoint elsewhere on the local subnet, or the connection resulting from an accept() call on one of the two listening sockets.

In practice I just don't see 16 TCP connections happening at once. There will be connections going on, but never at that sort of volume.
 
You might be able to get away with a single UDP socket instead of two. You can use a single UDP socket for listening on one specific port, and that same socket for sending to arbitrary locations.
 
shawn said:
You might be able to get away with a single UDP socket instead of two. You can use a single UDP socket for listening on one specific port, and that same socket for sending to arbitrary locations.
Click to expand...

I'd thought about doing that on the Wiznet 5500 chip, and indeed I do agree it's possible. However I decided against it, because it significantly increased the complexity of dealing with inbound data. If it's from a "known" address, it goes back to the appropriate sender, but what to do with unsolicited data? Without looking into the packet, I can't tell if it's a stale reply to an old transmit i.e. a reply to a transmit that happened hours ago and is now no longer considered valid, or if it's actual data that should be passed on.

And of course this just completely ceases to be an issue on the Teensy 4.1 since as outlined above, it has plenty enough sockets of all types to see me through. The main pain point on the Wiznet 5500 was TCP connections. Out of the eight available, one is reserved for the chip itself, most likely for DHCP / DNS / mDNS etc. queries, leaving seven for the app. Two UDP, two listening TCP leaves three for TCP connections, which is really tight.
 
Sorry, I meant in QNEthernet. I don’t see how that would increase complexity, unless you’re using the randomly-generated local port as some sort of ID or something? (Or something else I’m not thinking of.) I was proposing it as a way to save memory without much change in the code. Incoming packets aren’t related to the outgoing packets for a given socket; they’re not like TCP sockets.

In any case, I’m sure you’re doing what’s best for you. I just wanted future readers to know that it’s a thing.
 
Last edited:
Agreed. Trying to combine those two sockets doesn't change anything in QNEthernet. The complexity gets added in the application itself, and without a very long essay on exactly what it's doing and how it's doing it, that's not so easy to explain.
 
You must log in or register to reply here.
Back
Top