[atlas] *-capable ≠ *-works + *-doesnt-work

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ripe.net/ripe/mail/archives/ripe-atlas/attachments/20160419/2af34885/attachment.sig>