In a previous blog post I described the Linger error that we were running into from time to time and how you can mitigate against this by setting the ‘Linger’ option on the socket. This was the first of several issues we identified when working with Sockets in the .Net Micro Framework 3.0.
The next challenge we faced was to do with intermittent performance problems when communicating over HTTPS.
Example: The Socket Client Demo
We had noticed that the time it took for our application to communicate with HTTP and HTTPS endpoints (even on our internal network) seemed to vary greatly. These requests were consistent in both size and complexity yet some would take <1s and others appeared to take 10s.
To highlight this problem we used the ‘SocketClient’ demo application provided as part of the Micro Framework 3.0 SDK. This demo application makes a HTTP GET request to a given endpoint out on the internet and reads the response. Choosing this sample application for our testing allowed us to rule out the complexities in our own project as the source of the problem.
We made a small change to the code so that it would tell us how long it took to make each request and then performed the same GET operation 15 times and recorded how long it took each time.
We performed this test twice...
1. Once running on the Microsoft supplied device emulator
2. Once running on our Tahoe II hardware.
... and the results were interesting.
Running the test against the emulator (highlighted on the graph by the blue line) gave us consistent sub 200ms response times 100% of the time. Running on the Tahoe II hardware (the red line on the graph) gave us very erratic response times. Half of the requests returned in under 1 second and the other half took as long as 8 seconds, not a good time at all!
We then ran the same test on a GHI Embedded Development Master System in an attempt to rule out the hardware manufacturer as the cause of the problems and sure enough this device provided just as inconsistent results.
The Solution:
Migrate to .Net 4.0... Now this sounds like a fairly dramatic solution but if the success of your project is defined by delivering good, constant response times when communicating over HTTP or indeed any other protocol over TCP then you will need to use the latest Micro Framework offering from Microsoft.
We approached Microsoft about this issue, presenting our evidence and reproducible steps for them to see with their own eyes. They were quick to acknowledge that we had indeed discovered a bug in their TCP stack and took the appropriate steps to fix this in version 4 of the .Net Micro Framework before releasing it.
Whilst no fix has been provided for version 3 of the Micro Framework we were able to mitigate against these problems because we did not require sub 1 second response times (although it would have been nice).
As a side note...
The other issue that this highlighted was the importance of having real hardware to develop against as early as possible in your .Net Micro Framework projects. As our testing shows – had we spent the majority of our project working on software emulated devices we would have never discovered this issue.
Unit testing and a strong emphasis on code quality can only help you so much in your project. There are some things that you will only ever notice with real hardware. I suspect the same is true of all projects that have a hardware element – be it other embedded development platforms or indeed mobile development.
Author: Gavin Osborn
@gavinosborn
Tweet