Re: [atlas] ripe-atlas Digest, Vol 137, Issue 8
On 09/01/2023 11:32, ripe-atlas-request@ripe.net wrote:
The hardware probes are fully managed by RIPE NCC, and their only purpose is to execute measurements. I agree here, whether to update is up to RIPE NCC. On software probes, RIPE NCC is not in control of the unit. The software probe may run other services and updating is up to its local sysadmin. Consider operating system updates, which are updated by RIPE NCC on the hardware probes, but cannot be updated on software probes.
To automatically update, the solution here is a simple CRON job which executes yum -q update atlasswprobe periodically (say once per day or so), which was the solution that was part of the RPM up to 5080. Would it help if we add this to the instructions?
One question perhaps is if a probe running very obsoleted probe code, is useful or perhaps at some time probes older than version 1234 should not be used for pool measurements? For instance, release 2345 enables measurements on 240/12 while older releases, including release 2344, 240/12 is broken. Then, having probes with software 2344 or lower will give bias on measurements for 240/12. And for that reason I wonder if it makes sense to have a policy to "phase out" probes that are running obsoleted code, however well intended? Geert Jan
Hello, On 2023-01-09 22:59, Geert Jan de Groot wrote:
One question perhaps is if a probe running very obsoleted probe code, is useful or perhaps at some time probes older than version 1234 should not be used for pool measurements?
For instance, release 2345 enables measurements on 240/12 while older releases, including release 2344, 240/12 is broken. Then, having probes with software 2344 or lower will give bias on measurements for 240/12.
Let me offer some background information here. For the most part, newer firmware versions provide bugfixes and/or new functionality. If a particular feature already exists in version $OLD_VERSION which is running on some probes, there's no reason to exclude probes from measurements that need this feature just because it's not the $NEWEST_VERSION. On the flip side, the measurement scheduler is _mostly_ aware of new features in the firmware, in particular new measurement types and options and such. The we-no-longer-exclude-240/4 change is not one where we added this logic; mostly because it would be an exceptional case for a transitional period, ie. until probes upgrade to the version that has this change. The exception here is the v1/v2 probes; these are not useful for these measurements. Because of this I'd recommend excluding these, either in the measurement specification, or while processing the results.
And for that reason I wonder if it makes sense to have a policy to "phase out" probes that are running obsoleted code, however well intended?
Indeed, that is a direction we are / will be headed. We plan to add notifications for software probe hosts if their probe firmware is not up-to-date. In addition, eventually we'll "phase out" (as you say) probes that have too old firmware - where the definition of "too old" can change over time. Cheers, Robert
Geert Jan
participants (2)
-
Geert Jan de Groot -
Robert Kisteleki