We have created a page where our users can test the bandwidth they can benefit when upgrading the firmware on their controllers. To have a valid result, the test has to be made while in the same network with the controller.
Right now, we have download servers in multiple parts of the world. Thanks to geolocation, every client will connect to the nearest endpoint when downloading.
To test, one can use https://spd.mios.com and choose any of the servers there. We save some telemetry data, like IP address, location, download and upload speeds, browser.
This test does not get you to the closest server automatically.
Forgive my skepticism about the download speed being the cause for the upgrade failures as downloads can fail by more than just internet speed being slow. I know you also use md5 for integrity check post downloads but if I may suggest… I dug into the upgrade scripts you use and it seems awfully complicated.
You first download a shell script with the same firmware name and then run the script which optionally downloads a full OS image and then download the squashfs file and apply into the target partition…
Wouldn’t it be safer/more reliable for us to download the full firmware image to the local PC first and use a tool to upload it to the vera? Maybe integrate that tool into the firmware itself so that the upload can only be local? There is just no way you will be able to cover all the internet connection deficiencies in the world.
There are a lot of possible options here, but the decision for most of the possible solutions is not mine to take. The dual step upgrade was created long time ago by me, as it happens, and I am proud of it as a solution for the problem I tried to address at that time. Normally we should be able to skip this based on initial firmware version, but we are not. Was not implemented and can’t easily be implemented; so, every unit that needs to be upgraded (by the user, with prompt), has to go through this.
If the company policy would have been to force upgrades (as Amazon or Philips do), the need of the two step upgrade now would have been 0.
Some problems will for sure be solved by having multiple download servers, especially the ones due to long upgrades, that normally should be 10-15 minutes and go to hours due to download speed.
I think the current solution you came up with is actually clever and elegant if the constraint is to have the vera do the whole thing on its own. Don’t get me wrong.
I just question if that constraint you had is worth keeping in light of all these upgrade failures.
It seems like running a sysupgrade makes things more challenging when done within the limited storage space and error prone NAND flash hardware of the vera. Also doing multiple downloads just multiplies the risks, especially after the upgrade process has started but you already know that…
Likely because you use browsers to download files which have a lot of ecc, multiple parallel calls and retry built in… not quite the case of the good old wget call.
I picked the Libre-server geographically closest to me and ran a couple of times. It looks like the LibreTest is limited to 100Mbs/ down but that is probably approaching the limit of an embedded appliances transfer rate so it is still a reasonable test.
We have multiple servers in the us, lesser in South America and the same for Europe. The size of our firmware won’t usually be enough for the speed to top up.
By checking the stats, no upgrade should fail due to low speed. Even tests from Cape Town were able to get to ~8mb/s. Minimum download speed was 0.81mbps (mobile connection), the biggest was 372.50mbps, average 48mbps. Inside Brasil, downloads average at 120mbps. Ah, the biggest was Dubai to Paris.
