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

[Bajpai, Vaibhav]

> On 19 Apr 2016, at 15:07, Chris Amin  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
===



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Chris Amin]

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



signature.asc
Description: OpenPGP digital signature