The Great Network Shootout

@ godefroi - it is completely based on it!

Doesnā€™t the Mountaineer use the STM32 MAC and an external PHY ? If so then there must be something different than the ENCJxxxxx code ?

@ Rajesh - Yes, we use the Ethernet controller built into STM32. To give credit where credit is due: our Mountaineer partner company CSA Engineering has built a fast interrupt-driven, DMA-based driver for this controller plus the external PHY chip.

So, the networking stuff will be significantly different, then, in any case?

Looking at my Mountaineer Ethernet board in this test that is running 4.3, I wouldnā€™t say different, or at least not as far as the code I wrote goes, but certainly different in terms of how reliable the network connection has been as its been rock solid.



using System;
using System.Net;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using OpenSense;
using GT = Gadgeteer;
using GTM = Gadgeteer.Modules;

namespace MountaineerNetwork
{
    public partial class Program
    {
        #region Confidential Settings
//chop
        #endregion

        private static OpenSenseClient _openSenseClient;
        private readonly GT.Timer _timer = new GT.Timer(30000);
        private int _caughterrors;
        private string _error_msg;
        private int _iteration;
        private uint _memory;
        private int _resets;
        private int _status;

        private TimeSpan _upTime = new TimeSpan(0, 0, 0, 0);

        // This method is run when the mainboard is powered up or reset.   
        private void ProgramStarted()
        {
            // Use Debug.Print to show messages in Visual Studio's "Output" window during debugging.
            Debug.Print("Program Started");

            _memory = Debug.GC(false);
            _upTime = PowerState.Uptime;
            _status = 0;
            _error_msg = "Starting Run with " + _timer.Interval + " interval";

            _timer.Tick += _timer_Tick;

            ethernetForMountaineerEth.NetworkUp += ethernetForMountaineerEth_NetworkUp;
            ethernetForMountaineerEth.NetworkDown += ethernetForMountaineerEth_NetworkDown;

            if (!ethernetForMountaineerEth.NetworkSettings.IsDhcpEnabled)
                ethernetForMountaineerEth.NetworkSettings.EnableDhcp();

            ethernetForMountaineerEth.UseDHCP();
        }


        private void ethernetForMountaineerEth_NetworkDown(GTM.Module.NetworkModule sender,
            GTM.Module.NetworkModule.NetworkState state)
        {
            Debug.Print("Network Down");
        }

        private void ethernetForMountaineerEth_NetworkUp(GTM.Module.NetworkModule sender,
            GTM.Module.NetworkModule.NetworkState state)
        {
            Debug.Print(ethernetForMountaineerEth.NetworkSettings.IPAddress);

            foreach (string dsnAddress in ethernetForMountaineerEth.NetworkSettings.DnsAddresses)
            {
                Debug.Print("DNS Server: " + dsnAddress);
            }

            if (ethernetForMountaineerEth.IsNetworkUp)
            {
                SetupOpenSense();

                _timer.Start();
            }
        }

        private void SetupOpenSense()
        {
            _openSenseClient = new OpenSenseClient();
            _openSenseClient.SenseKey = OPENSENSEWRITEKEY;
        }

        private void _timer_Tick(GT.Timer timer)
        {
            _memory = Debug.GC(false);
            _upTime = PowerState.Uptime;

            _iteration++;

            _openSenseClient.data.Clear();

            _openSenseClient.AddFeedValue(MEMORYCHANNEL, _memory.ToString());
            _openSenseClient.AddFeedValue(ITERATINOCHANNEL, _iteration.ToString());
            _openSenseClient.AddFeedValue(STATUSCHANNEL, _status.ToString());
            _openSenseClient.AddFeedValue(RESETCHANNEL, _resets.ToString());
            _openSenseClient.AddFeedValue(CAUGHTERRORSCHANNEL, _caughterrors.ToString());

            if (_error_msg != string.Empty)
            {
                _openSenseClient.AddFeedValue(MESSAGESCHANNEL, _error_msg);
                _error_msg = String.Empty;
            }

            try
            {
                HttpStatusCode y = _openSenseClient.Send();

                if (y != HttpStatusCode.OK)
                {
                    _caughterrors++;
                }

                _status = (int) y;
            }
            catch (Exception ex)
            {
                Debug.Print(ex.Message);

                _status = -200;
                _resets++;

                _timer.Stop();

                _error_msg = "Iteration " + _iteration + ": " + ex.Message + "@ \n" + ex.StackTrace + "@ \n" +
                             ex.InnerException.Message;

                ethernetForMountaineerEth.NetworkSettings.ReleaseDhcpLease();
                ethernetForMountaineerEth.UseDHCP();
            }
        }
    }
}


Right, I meant the underlying network code, not the NETMF APIs.

As a follow up I left a Mountaineer Ethernet board going and it has passed 26,000 iterations and still going strong so that is over 9 days of an iteration every 30 seconds, good work @ Cuno and company, it looks like a winner, again I can hardly wait to get my hands on 4.3 as networking looks like a champ.

http://open.sen.se/sensemeters/tab/6373/

2 Likes

The Mountaineer Etherboard is closing in on 50,000 iterations (currently at 47,335) and is proving to be unstoppably great, so I feel rather confident that its a rock star waiting to happen so once it hits 50,000 Iā€™m going to stop this experiment and call it a success.

http://open.sen.se/sensemeters/tab/6373/

1 Like

The Mountaineer Ethernet board running 4.3 has completed over 57,000 iterations, and I even did nasty things like reboot the router that it was connected to and while that caused errors (ie the http requests failed as expected given the device was no longer connected to the internet) as soon as the router came back up the connections were re-established without intervention and the test continued along successfully, sweet. So its time to shut this experiment down as it has accomplished everything I wanted and memory usage looked solid.

2 Likes

Hi Duke,
can you please try this and report backā€¦
assuming your board is on DHCPā€¦ While itā€™s connected try to unplug itā€¦ Reboot the router plug another device to the router, then plug your board back againā€¦ Basically Iā€™m interested to know what will happen if the dynamically assigned IP address of the board is changedā€¦

once the router reboots check out the newly assigned ip of the board and see if it continues to workā€¦

thanksā€¦

@ Jay Jay Iā€™ll do that tomorrow and let you know the results. I assume what the idea is to have it do a reconnect and force it to grab a different IP Address. Maybe Iā€™ll be a real meanie and swap what router it is connected to mid test (that uses a different IP range) and see what happens. That will force it to renegotiate a new IP address and if it can do that independently, then I think we have a winner.

@ Jay Jay I need to roll back a couple of versions of Gadgeteer so I can get back to the 4.3 that I have a firmware for the Mountaineer Ethernet board, so hopefully tonight Iā€™ll get a little time to do that.

Otherwise Iā€™m curious seeing Corentin Zill was involved in the Gadgeteer Core 2.43.900 release how much of his networking magic made its way into the release, so Iā€™ve kicked off another round of Cerberus, Hydra and Spider wired/wifi testing to see if they still kick out at 2570 iterations.

http://open.sen.se/sensemeters/tab/6390/

Thanks for the update, looking forward to the good newsā€¦

@ Jay Jay well that was fun as I had all sorts of fun rolling back to test this, but the answer for the moment would be a ā€˜Noā€™, but the version of 4.3 Iā€™m testing and its associated firmware etc is only beta so I would fully expect to be some issues.

It does beg the question however of how would you ā€˜dropā€™ an existing connection (if one existed) and then get a new one? It was a question I had early on as it doesnā€™t seem clear to me. I tried experimenting with just doing a UseDHCP call, but I donā€™t think that drop/reconnects an existing connection, so then I tried stuff like ReleaseDhcpLease which seems to clean out the connection (expect the DNS address which is interesting), but the following call to RenewDhcpLease doesnā€™t seem to do anything (I would have guessed if you didnā€™t have a DHCP connection that it would request one). All through this the IsNetWorkUp returns true, so I suspect there is still some work to be done in this area, but ā€˜IsConnectedā€™ stuff is never easy.

So what I did was during the test disconnect the cable from a 192.168.3.x network and then plugged it into a 192.168.5.x network, and the idea was to see if the network would reconnect. Is that what you had in mind?

Thanks Duke, but for the ā€œnetworking magicā€, thatā€™s my buddy Pierre-Yves from CSA Engineering who made the whole work!

Anyway, thanks for testing all these baords!

Yesā€¦
Did it pick up a new IP and resumed work?

[quote=ā€œJay Jayā€]

Yesā€¦
Did it pick up a new IP and resumed work?
[/quote]Nope. NOTE however Iā€™m working with a beta of a beta firmware so the final release version might be very different.

[/quote]

Yesā€¦
Did it pick up a new IP and resumed work?
[/quote]Nope. NOTE however Iā€™m working with a beta of a beta firmware so the final release version might be very different.
[/quote]

dang, I was afraid of reading that answer, and I really hope the networking stuff gets fixed because itā€™s a real show stopperā€¦

thanks for the testsā€¦

As an experiment I ran the latest 4.2 version of the Hydra test to see if there had been any improvement to networking and I see we still have our magic number of 2570 iterations where the networking quits.

If I can get a 4.3 version working (no luck so far), I see how it compares.

1 Like

Whats holding you back? Really crossing my fingers that this is working better.