@ DukeNukem - keep up the good work! Thanks for doing this. Its exciting.
@ Duke Nukem - Great work, and very interesting results.
What sort of ācaught errorsā are you getting?
No errors or exceptions - does this mean that OpenSen.se plays nicer with TCP and HTTP than ThingSpeak?
The Mountaineer is still running with over 4300 iterations. Iām only able to get tweets etc of the errors so I donāt have a full capture but for example this morning the Mountaineer board had an:
Mountaineer Error Exception was thrown: System.ArgumentOutOfRangeException
but I suspect it might be a ThingSpeak return related issue. Now Iām not about to slag ThingSpeak as right now they are really popular and just getting beaten like a free rent mule and my OpenSen.se client is no where as full featured as the ThingSpeak client so party on ThingSpeak.
Today Iāll try to switch all the boards over to testing against OpenSen.se and see how that goes. I upped the interval time for the Cerberus test currently running against OpenSen.se to see if it still stops at 2750 or sooner which might indicate there is a time related factor in the soup here thats causing problems.
This is getting highly, highly weird as I ran the Cerberus against OpenSen.se and increased the iteration duration from 30 to 40 seconds in order to see if this was some kind of time dependency, but nope there is something magic about iteration 2570 as that is when it stopped. I have a spider wifi and spider wired running as well against OpenSen.se and so Iāll see if they stop at 2570 as well.
OK so what is the magic around exactly 2570 network iterations?
My guess is memory or some other leak. Each request leaks enough of the resource so that at 2570 requests, the available resource has been exhausted. Could be handles, could be memory, could be some buffer somewhere.
Thatās my guess.
hi during my testing of the network stack I learned that VS tends to hide some of the debugging msgs especially the low level ones, so I strated to debug using MFDeploy and was surprised to see the low level debug msg appearingā¦ my recommendation is to launch MFDeploy>>choose your protocol USB and pick you board then file>>connect and start your tests and watch the output window of MFdeploy when you reach those error or at least when it stops and let us know what you see.
good luck and thanks for doing thisā¦
Jay.
OpenSen.se link is http://open.sen.se/sensemeters/tab/4380/?preview=on
So far Iām learning lots about what OpenSen.se can do so lots of learning going on here.
@ Duke Nukem - Thanks for your work on this. Is your test code available anywhere? I have a Cerb I could use to test and see if I get similar results.
@ skeller - It is in the first message of this thread
https://www.ghielectronics.com/community/forum/topic?id=14607&page=1
This morningās status report.
Both the wired and wifi tests using a spider crapped out at 2569 (at different times as I started them at different times), which is interesting as I think I started both of those under debug and then let them run on, possible connection between debug and whatever is crapping out, possibly.
Memory usage is one of the things measured each iteration during the test, and it looks solid, so Iām thinking there is a handle somewhere that isnāt being released correctly.
The Mountaineer board which is running 4.3 doesnāt seem to experience this problem and it kicks along nicely until I stop it.
Iāll see what I can do to get my OpenSen.se charts etc made public so people can check in on them if they wish, and perhaps post the code for this in CodeShare so other folks can try it if they wish as well. Today is getting the Hydra switched over to the OpenSen.se and I think Iāll add a Raptor to the list of mainboards being tested, but I suspect it will hit the same issue as well.
Oops forgot to post this morning.
@ skeller Iāll CodeShare the Cerberus projects for this, probably tomorrow as I think the wife has plan for tonight which donāt involve me geeking out.
+1 This would help with my request hereā¦
https://www.ghielectronics.com/community/forum/topic?id=14852&page=1#msg150076
@ Duke Nukem - canāt wait to get you the 4.3 firmware to see if that us different, should!
While 4.3 look great, I have found something which worked on 4.2 which currently doesnāt work on 4.3 so Iāll be sending this off to whoever wants it:
In the OpenSense client I do this
var request = (HttpWebRequest) WebRequest.Create(_endPointURL);
where
private static string _endPointURL = @ āhttp://api.sen.se/events/ā;
and this works in 4.2, but gives a Host not found error in 4.3 on the Mountaineer.
Of course I wanted to work on this today, but it appears that OpenSen.se is down at the moment, the suckage of working with sites that arenāt yours I guess.
** HOLD ON THIS AS SOME FURTHER TESTING IS ONGOING **
worked with Spider running wifi and wired, but not with Cerberus running 4.2, so maybe not a 4.2 4.3 thing but something else.
OK Found the problem. In the network configuration I had a DNS address entry for a network that I wasnāt connecting to (I have far too many test networks in my office), and since I had a DNS entry it wouldnāt pull back the DNS address from the router I was connecting to, and hence DNS calls would fail.
So if your having trouble getting your network app to work, check the network configuration and ensure that the DNS entries are 0.0.0.0 or are a DNS server you can get to.
I had modified the network settings as I had multiple ENC28ās on the same router and wanted to ensure unique MAC Addresses.
I set up a Cerb using a modified version of the code in post #1. To speed things along in testing the ā2570ā issue I created 3 channels on ThingSpeak and rotated through them at an interval of 6 seconds. (Each channel updated at 18 seconds.)
With the debugger connected it made it to exactly 2100 iterations and it hung at:
this.socket.Connect(this.hostIpEndPoint);
in the ThingSpeakClient.cs, Update() function.
After about 28 minutes of being hung up I got a System.OutOfMemoryException error in the debug window.
Looking at the code in codeshare, I would suggest the following.
Make sure keepalive is set to false before getting the response.
Make sure connection is set to close before getting the response.
Make sure to close the response you get back after you are done reading it.
The code is leaking resources, probably because it is not closing the response.
If none of that works, I would suggest using the code from netmftoolbox on Codeplex.
http://netmftoolbox.codeplex.com/SourceControl/latest#Framework/NET.HTTP_Client/HTTP_Client.cs
I have been using it for years on both 4.1 and 4.2.
It doesnāt implement the PUT verb, but you donāt need it. It also doesnāt handle chunked responses properly, but you might not really need that.
The next thing you will hit is the infinite timeout on Connect, when the server doesnāt respond or a packet gets lost.
1 Like
I got up to 9108 iterations on my Cerb. I was updating ThingSpeak every 6 seconds. (3 channels in a round robin fashion so each channel had an 18 second update.)
I moved the entire _timer_Tick() function into its own thread. Because its in its own thread I am not exactly sure where it has stopped but I had a State variable that was set right before it went into _thingSpeak.Update(). My guess is that it got hung up on socket.Connect().
I donāt know if that sheds any additional light on the subject or not.
The magic number of 2570 has shown up again for the Cerberus test and the Spider Wifi stopped at 2569 but I think it didnāt count the network cycle for the initial start message so 2570 counting that., now to see if the wifi and hydra kick out at the same point. The Mountaineer Ethernet board is kicking butt and taking names, but its running 4.3 and doesnāt seem to suffer from this problem.
@ Frogmore next round of testing will include your suggestion one ( Make sure keepalive is set to false before getting the response ) as its not set which I think makes it true, otherwise I thought the client had your other suggestions already handled. Ultimately one of the questions I had is why the Mountaineer Ethernet board running the same code didnāt stop and Cuno had mentioned they had put in a ton of work on networking and so Iām very much looking forward to NetMF 4.3 support in Gadgeteer.
http://open.sen.se/sensemeters/tab/6372/
@ Skeller Iām going to fire up another test where it cycles every 10 seconds and see if that makes a difference. it didnāt make any difference when I went from a cycle time of 30 to 40 seconds, it still kicked out at 2570, but change is good for finding issues.
I donāt think GHIās current firmware is based on the Oberon port, is it? If not, it wouldnāt necessarily benefit from the work Oberon put into the networkingā¦