This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[atlas] *-capable ≠ *-works + *-doesnt-work
- Previous message (by thread): [atlas] *-capable ≠ *-works + *-doesnt-work
- Next message (by thread): [atlas] RIPE Atlas CLI Toolset now available on NLNOG RING
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Bajpai, Vaibhav
v.bajpai at jacobs-university.de
Wed Apr 20 13:32:19 CEST 2016
> On 19 Apr 2016, at 15:07, Chris Amin <camin at 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 =================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: </ripe/mail/archives/ripe-atlas/attachments/20160420/c1f0ce82/attachment.sig>
- Previous message (by thread): [atlas] *-capable ≠ *-works + *-doesnt-work
- Next message (by thread): [atlas] RIPE Atlas CLI Toolset now available on NLNOG RING
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]