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