Hello, I am looking at the probe API data for connected probes (status = 1) for day = 20160418 system-ipv6-capable = 3556 system-ipv6-works = 2995 system-ipv6-doesnt-work = 710 Why is system-ipv6-works + system-ipv6-doesnt-work > system-ipv6-capable? system-ipv4-capable = 9336 system-ipv4-works = 9187 system-ipv4-doesnt-work = 67 Why is system-ipv4-works + system-ipv4-doesnt-work < system-ipv4-capable? Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany ===================================
On 19/04/2016 11:07, Bajpai, Vaibhav wrote:
Hello,
I am looking at the probe API data for connected probes (status = 1) for day = 20160418
system-ipv6-capable = 3556 system-ipv6-works = 2995 system-ipv6-doesnt-work = 710
Why is system-ipv6-works + system-ipv6-doesnt-work > system-ipv6-capable?
system-ipv4-capable = 9336 system-ipv4-works = 9187 system-ipv4-doesnt-work = 67
Why is system-ipv4-works + system-ipv4-doesnt-work < system-ipv4-capable?
Dear Vaibhav, You are right that system-ipv6-works + system-ipv6-doesnt-work should be a subset of system-ipv6-capable. The -works and -doesnt-work tags are assigned based on measurement results from the past few hours, and there appears to be a bug whereby probes are continuing to carry out IPv6 measurements even when they no longer have IPv6 capability. This understandably results in unsuccessful results, which triggers the "doesnt-work" tag. Thank you for pointing this out to us, we are working on a fix now. The other case (system-ipv4-works + system-ipv4-doesnt-work < system-ipv4-capable) makes more sense, because it's possible that a probe is marked as "capable" but doesn't actually return any measurement results for some reason -- for instance, it may be able to connect to the controller over IPv4 -- so we know for sure that it is "capable" of IPv4 -- but isn't able to report any IPv4 measurement results because of a faulty SD card, which isn't reflective of an IPv4 issue per se. We only mark a probe as "ipvX-doesnt-work" when we actually get unsuccessful results back from it, so in some cases a probe will have neither "works" nor "doesnt-work" tags. Kind regards, Chris Amin
On 19 Apr 2016, at 15:07, Chris Amin <camin@ripe.net> wrote:
On 19/04/2016 11:07, Bajpai, Vaibhav wrote:
I am looking at the probe API data for connected probes (status = 1) for day = 20160418
system-ipv6-capable = 3556 system-ipv6-works = 2995 system-ipv6-doesnt-work = 710
Why is system-ipv6-works + system-ipv6-doesnt-work > system-ipv6-capable?
system-ipv4-capable = 9336 system-ipv4-works = 9187 system-ipv4-doesnt-work = 67
Why is system-ipv4-works + system-ipv4-doesnt-work < system-ipv4-capable?
Dear Vaibhav,
You are right that system-ipv6-works + system-ipv6-doesnt-work should be a subset of system-ipv6-capable. The -works and -doesnt-work tags are assigned based on measurement results from the past few hours, and there appears to be a bug whereby probes are continuing to carry out IPv6 measurements even when they no longer have IPv6 capability. This understandably results in unsuccessful results, which triggers the "doesnt-work" tag. Thank you for pointing this out to us, we are working on a fix now.
Oh! OK.
The other case (system-ipv4-works + system-ipv4-doesnt-work < system-ipv4-capable) makes more sense, because it's possible that a probe is marked as "capable" but doesn't actually return any measurement results for some reason -- for instance, it may be able to connect to the controller over IPv4 -- so we know for sure that it is "capable" of IPv4 -- but isn't able to report any IPv4 measurement results because of a faulty SD card, which isn't reflective of an IPv4 issue per se. We only mark a probe as "ipvX-doesnt-work" when we actually get unsuccessful results back from it, so in some cases a probe will have neither "works" nor "doesnt-work" tags.
This is useful information. Thanks for sharing
Kind regards, Chris Amin
Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany ===================================
participants (2)
-
Bajpai, Vaibhav -
Chris Amin