Hi, There are three hardware versions of RIPE Atlas probes namely v1,v2 and v3. Each of the support different firmware versions. Can I get the latest firmware version supported by each the hardware versions? Thanks, Steffie
On 2013.12.17. 16:44, Eravuchira, Steffie Jacob wrote:
Hi,
There are three hardware versions of RIPE Atlas probes namely v1,v2 and v3. Each of the support different firmware versions. Can I get the latest firmware version supported by each the hardware versions?
Thanks, Steffie
Hello, Usually the different hardware revisions run the same firmware version. Currently that's not the case (v3 is one version ahead at 4580, v1/2 are at 4570). The system automatically notifies probes about the latest firmware available for that hardware revision whenever the probe reconnects. The probe then upgrades right away, if the latest version is not yet installed. This requires no intervention from the probe host. If the probe is otherwise up and running happily, then it does not get the notification, therefore does not upgrade until the next reconnect. So in general we have a lazy upgrade approach. As of right now, all connected probes across all probe hardware revisions are running the latest firmware version available (with the exception of two misbehaving v2 probes). Hope this helps, Robert
On 17 Dec 2013, at 20:05, Robert Kisteleki <robert@ripe.net> wrote:
On 2013.12.17. 16:44, Eravuchira, Steffie Jacob wrote:
There are three hardware versions of RIPE Atlas probes namely v1,v2 and v3. Each of the support different firmware versions. Can I get the latest firmware version supported by each the hardware versions?
Thanks, Steffie
Hello,
Usually the different hardware revisions run the same firmware version. Currently that's not the case (v3 is one version ahead at 4580, v1/2 are at 4570).
The system automatically notifies probes about the latest firmware available for that hardware revision whenever the probe reconnects. The probe then upgrades right away, if the latest version is not yet installed. This requires no intervention from the probe host.
If the probe is otherwise up and running happily, then it does not get the notification, therefore does not upgrade until the next reconnect. So in general we have a lazy upgrade approach.
As of right now, all connected probes across all probe hardware revisions are running the latest firmware version available (with the exception of two misbehaving v2 probes).
Hello Robert, The question popped up at our end because we were looking at the plots of measurement results generated by different probes. We wanted to make sure these probes were comprised of the same hardware and that they run the same firmware version. It’s great that each UDM attaches the firmware version of the probe as a tag in its results. However: a) Although, the hardwares currently are capable of running the same firmware revision, but as you mentioned, at times they diverge away. b) Would different hardwares always support the latest firmware version? I ask because v3 is more capable than v1/v2, and I don’t know if you plan to diverge away the firmware at some point to provide more measurement capabilities for v3 probes. Due to a) and b) would it make sense to also attach the hardware version (v1, v2, v3) of the probe as a tag in each UDM result as well? We don’t know if different hardwares have effects on the measurement results. We can cross-confirm this if the UDMs attach a hardware version in addition to the firmware revision. Thanks! Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com
Hello,
Hello Robert,
The question popped up at our end because we were looking at the plots of measurement results generated by different probes. We wanted to make sure these probes were comprised of the same hardware and that they run the same firmware version. It’s great that each UDM attaches the firmware version of the probe as a tag in its results. However:
a) Although, the hardwares currently are capable of running the same firmware revision, but as you mentioned, at times they diverge away.
b) Would different hardwares always support the latest firmware version? I ask because v3 is more capable than v1/v2, and I don’t know if you plan to diverge away the firmware at some point to provide more measurement capabilities for v3 probes.
As a general rule, we keep the firmware versions in sync across hardware revisions in order to have the same capabilities available. The current situation is a bit of an exception, but that's only because we needed to deploy a new firmware for one hardware version only; functionally there's no difference.
Due to a) and b) would it make sense to also attach the hardware version (v1, v2, v3) of the probe as a tag in each UDM result as well? We don’t know if different hardwares have effects on the measurement results. We can cross-confirm this if the UDMs attach a hardware version in addition to the firmware revision.
This would be possible, though (with some more documentation from our end [*]) one could also easily determine the hardware version from the probe ID. Regards, Robert [*] the quick version: - ID < 1500: v1 - 2000 < ID < 5000: v2 - 6000 < ID < 7000: anchor - ID > 10000: v3
Thanks!
Best, Vaibhav
----------------------------------------------------- Vaibhav Bajpai
Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany
www.vaibhavbajpai.com
On 02 Jan 2014, at 11:44, Robert Kisteleki <robert@ripe.net> wrote:
[...]
As a general rule, we keep the firmware versions in sync across hardware revisions in order to have the same capabilities available. The current situation is a bit of an exception, but that's only because we needed to deploy a new firmware for one hardware version only; functionally there's no difference.
Due to a) and b) would it make sense to also attach the hardware version (v1, v2, v3) of the probe as a tag in each UDM result as well? We don’t know if different hardwares have effects on the measurement results. We can cross-confirm this if the UDMs attach a hardware version in addition to the firmware revision.
This would be possible, though (with some more documentation from our end [*]) one could also easily determine the hardware version from the probe ID.
Regards, Robert
[*] the quick version: - ID < 1500: v1 - 2000 < ID < 5000: v2 - 6000 < ID < 7000: anchor - ID > 10000: v3
Aha! This is useful. Thanks for sharing. Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com
Robert Kisteleki wrote: [...] given the "lazy" approach :-)
As a general rule, we keep the firmware versions in sync across hardware revisions in order to have the same capabilities available. The current situation is a bit of an exception, but that's only because we needed to deploy a new firmware for one hardware version only; functionally there's no difference.
I just noticed that our (old tech) anchor is still more than one version behind. Is there some sort of schedule to make them load the update eventually, in case they do not disconnect "regularly". Which is sort of expected behaviour for Anchors, imho :-) Wilfried.
On 2014.01.15. 15:46, Wilfried Woeber wrote:
Robert Kisteleki wrote:
[...]
given the "lazy" approach :-)
As a general rule, we keep the firmware versions in sync across hardware revisions in order to have the same capabilities available. The current situation is a bit of an exception, but that's only because we needed to deploy a new firmware for one hardware version only; functionally there's no difference.
I just noticed that our (old tech) anchor is still more than one version behind.
Is there some sort of schedule to make them load the update eventually, in case they do not disconnect "regularly". Which is sort of expected behaviour for Anchors, imho :-)
Wilfried.
Yes, good point, we'll be a bit more aggressive with Anchors :-) (And the morhogenetic field seems to be strong today, I hear our engineers have discussed this just this afternoon...) Robert
participants (4)
-
Bajpai, Vaibhav
-
Eravuchira, Steffie Jacob
-
Robert Kisteleki
-
Wilfried Woeber