Hi, we have a custom board based on the FEX Cobra-II design. The board is used to receive SNMP traps and forward these over serial port. Unfortunately we have very poor performance for receiving UDP. With about 50pps (~50 byte packets) the interface starts dropping packets. Increasing socket buffer does not help nor increasing read priority on input thread. It seems that the ENC28 can’t hand the packet over to G120 fast enough although the data rate is just (~50508 = 20kbps). At the same time another thread is transmitting over com1:. Could this be part of the problem. Interrupt contention? Would be happy for any feedback / insight into the problem.
The theoretical Maximum of G120 + ENC28 when downloading a file via HTTP (TCP/IP), and dropping the bytes (no processing) is about 45KB/sec. (actual quick test result by GHI).
I think UDP will not be much faster.
also smaller packets reduce throughput also I guess.
Edit: also make sure you have at least an Sleep(0); in the loop of each thread. If you don’t. each thread will run for 20ms before the next one gets active.
Thanks for the fast reply. Explicitly yielding with Sleep(0) in all other threads actually helps a bit. I’m a bit dissapointed over the performance though. From the datasheets alone i was expecting performance up towards mbps and not a few kbps. Do you have any insight as to what is the real bottle neck here? The only funny thing i found is that on the Cobra II board LED-B seem to be wired to default to half duplex (magic meaning from ENC28 datasheet).
(MY GUESS)I would blame cpu because its a twentieth the speed of a netbook @ 2.2ghz approx. also how the framework and system is designed in general, to work on low ram devices.
CPU is definitely one piece of the bottleneck here.
According to numbers from GHI, G400 + ENC28 is faster.
G400D also provides builtin Ethernet (like EMX) which should be faster I guess.
An additional bit of information to help evaluate the achieved rate:
- An IPV4 packet has a minimum overhead (header) of 20 bytes. A 50 byte payload would actually produce a packet of 70 bytes.
Overclocking the memory bus (to 120mhz) gives a huge performance boost that also improves packetrate so i’m considering doing that even on production boards for now 8)
I’ve been doing this since before 8Mhz was really fast so i’m fairly certain CPU speed is not the bottleneck here. I still think >50pps is possible with this hardware setup. My two cents would be on pipelining SPI commands to reduce SPI roundtrips.
The G120 board uses the LPC1788FET180 which has a built in RMI interface. The interface is exposed but not supported according to documentation. Is there any plans on supporting this in the future?
My money is on the processing of the packets.
Yes it is supported, however we have not documented how just yet. We are waiting on the next sdk release which is in its final stages but no set date yet.