Re: [atlas] Probe status / self-help
On 20/04/2016 15:32, Robert Kisteleki wrote: > Dear All, > > Today we released a new feature intended to help the probe hosts detecting, > understanding and fixing various issued related to probes. > > You should be able to see a new "Status" tab on your probe page. This is > where we explain various conditions, such as USB problems, non-working IPv6 > or DNS resolutions quirks. > > Please note that this bit is in early stages (officially labeled as beta). > We believe it works in general, however for now it only explains various > system tags that mark error conditions. It will have more features in the > future. It is also intended to be a place where we can add features that > explain, for example, "your probe behaves differently than the rest" or > "path MTU issues detected" or such. > > We think this will be a useful feature to hosts. Let us know if you have > specific suggestions for improvement. > > Regards, > Robert Kisteleki > RIPE NCC > > It would be nice if not only the probe owner but other users would be able to view this tab in order to help the users with problematic probes fix their issues. Thanks, Hank
Re: [atlas] Probe status / self-help
seems to work ok for me, would bee good to get a status history maybe from sos logs ? Colin > On 20 Apr 2016, at 13:32, Robert Kisteleki wrote: > > Dear All, > > Today we released a new feature intended to help the probe hosts detecting, > understanding and fixing various issued related to probes. > > You should be able to see a new "Status" tab on your probe page. This is > where we explain various conditions, such as USB problems, non-working IPv6 > or DNS resolutions quirks. > > Please note that this bit is in early stages (officially labeled as beta). > We believe it works in general, however for now it only explains various > system tags that mark error conditions. It will have more features in the > future. It is also intended to be a place where we can add features that > explain, for example, "your probe behaves differently than the rest" or > "path MTU issues detected" or such. > > We think this will be a useful feature to hosts. Let us know if you have > specific suggestions for improvement. > > Regards, > Robert Kisteleki > RIPE NCC > >
[atlas] Probe status / self-help
Dear All, Today we released a new feature intended to help the probe hosts detecting, understanding and fixing various issued related to probes. You should be able to see a new "Status" tab on your probe page. This is where we explain various conditions, such as USB problems, non-working IPv6 or DNS resolutions quirks. Please note that this bit is in early stages (officially labeled as beta). We believe it works in general, however for now it only explains various system tags that mark error conditions. It will have more features in the future. It is also intended to be a place where we can add features that explain, for example, "your probe behaves differently than the rest" or "path MTU issues detected" or such. We think this will be a useful feature to hosts. Let us know if you have specific suggestions for improvement. Regards, Robert Kisteleki RIPE NCC
Re: [atlas] *-capable ≠ *-works + *-doesnt-work
> 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
