# Viewing Probe Test Results **URL:** \ **Category:** RIPE Atlas\ **Created:** [10 February 2023 10:29 UTC](https://forum.ripe.net/t/viewing-probe-test-results/378 "2023-02-10T10:29:28Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![SimonC](https://avatars.discourse-cdn.com/v4/letter/s/87869e/32.png) [@SimonC](https://forum.ripe.net/u/SimonC)\ **Post date:** [10 February 2023 10:29 UTC](https://forum.ripe.net/t/viewing-probe-test-results/378/1 "2023-02-10T10:29:28Z")
yesterday I ran the following measurement: > **[RIPE Atlas](https://atlas.ripe.net/frames/measurements/49851475/#!probes)** > > RIPE Atlas, RIPE, Atlas When I look at the Latest Results all I get is an overall text report showing RTT (presumably this is Avg over the 16 pings I set) and 0% Packet Loss: | Probe | ASN (IPv4) | ASN (IPv6) | | | Time (UTC) | RTT | Packet Loss | | --- | --- | --- | --- | --- | --- | --- | --- | | 60998 | 702 | | | | 2023-02-09 14:10 | 80.612 | 0.0% | But if I run the same ping test from Global Traceroute I get a nicer verbose output: PING 54.156.0.0 (54.156.0.0): 56 data bytes Response from 54.156.0.0: icmp\_seq=0 ttl=233 time=81.928062 ms Response from 54.156.0.0: icmp\_seq=1 ttl=233 time=81.817491 ms Response from 54.156.0.0: icmp\_seq=2 ttl=233 time=81.593709 ms Response from 54.156.0.0: icmp\_seq=3 ttl=233 time=81.60163 ms Response from 54.156.0.0: icmp\_seq=4 ttl=233 time=81.590189 ms Response from 54.156.0.0: icmp\_seq=5 ttl=233 time=81.570347 ms Response from 54.156.0.0: icmp\_seq=6 ttl=233 time=81.456015 ms Response from 54.156.0.0: icmp\_seq=7 ttl=233 time=81.544104 ms Response from 54.156.0.0: icmp\_seq=8 ttl=233 time=81.676437 ms Response from 54.156.0.0: icmp\_seq=9 ttl=233 time=81.769646 ms — 54.156.0.0 ping statistics — 10 packets transmitted, 10 packets received, 0.0% packet loss round-trip min/avg/max = 81.456015/81.928062/81.654763 ms Source address is 193.79.9.138 ######################## I cant see any obvious option to change the reporting output - even under advanced options when setting up the measurement. Am I missing something obvious or is this just the way it is? Ironically sending the same 10 pings from the same probe Global Traceroute took less than 1m30s and after 6 mins I am still waiting for RIPE to complete (status = ongoing and I tried refreshing page in case it was stuck). ---
**Author:** ![robertk](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.ripe.net/robertk/32/413_2.png) [@robertk](https://forum.ripe.net/u/robertk)\ **Post date:** [10 February 2023 13:33 UTC](https://forum.ripe.net/t/viewing-probe-test-results/378/2 "2023-02-10T13:33:05Z")
You are showing the web UI of Atlas vs. terminal(ish?) output of another tool. This is what you get if you use the RIPE Atlas CLI: ```plaintext $ time ripe-atlas measure ping --target 8.8.8.8 --probes 5 Looking good! Measurement 49878155 was created and details about it can be found here: https://atlas.ripe.net/measurements/49878155/ Connecting to stream... PING 8.8.8.8 (resolved on server) 48 bytes from 8.8.8.8 via probe #1004871 (212.8.116.1): ttl=117 times=7.664 ms, 7.444 ms, 7.396 ms 48 bytes from 8.8.8.8 via probe #1003111 (188.192.134.178): ttl=113 times=18.174 ms, 16.247 ms, 18.003 ms 48 bytes from 8.8.8.8 via probe #1004099 (94.140.72.185): ttl=58 times=75.476 ms, 86.843 ms, 79.331 ms 48 bytes from 8.8.8.8 via probe #1002766 (70.176.169.215): ttl=117 times=22.821 ms, 23.028 ms, 21.333 ms 48 bytes from 8.8.8.8 via probe #53026 (62.28.23.75): ttl=60 times=18.82 ms, 17.421 ms, 18.292 ms --- 8.8.8.8 ping statistics --- 15 packets transmitted, 15 received, 0.0% loss rtt min/med/avg/max = 7.396/18.292/29.220/86.843 ms Disconnected from stream real 0m9.801s user 0m0.183s sys 0m0.046s ``` Note: it took 10 seconds _in total_. Of course if there’s one result that keeps on not coming… then one will wait longer. The one-off measurements are officially closed after 10 or 15 minutes - because by that time the results either came in or they never will 🙂 ---
**Author:** ![SimonC](https://avatars.discourse-cdn.com/v4/letter/s/87869e/32.png) [@SimonC](https://forum.ripe.net/u/SimonC)\ **Post date:** [10 February 2023 14:03 UTC](https://forum.ripe.net/t/viewing-probe-test-results/378/3 "2023-02-10T14:03:41Z")
Thanks. I am pretty new to this. The output I provided was from the Global Traceroute Webtool (pretty handy for basic single probe ping / trace / dns tests as requires no credit and easier to find specific probes imho): > **[Global Traceroute](https://www.globaltraceroute.com/)** > > Traceroutes from all over the world. Is there any easy way to access Atlas CLI for a HW probe or is this the only way: [https://ripe-atlas-tools.readthedocs.io/en/latest/](https://ripe-atlas-tools.readthedocs.io/en/latest/) If the latter seems a little strange that a free 3rd party tool offers CLI style output when Atlas itself doesnt as standard. ---
**Author:** ![robertk](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.ripe.net/robertk/32/413_2.png) [@robertk](https://forum.ripe.net/u/robertk)\ **Post date:** [10 February 2023 14:09 UTC](https://forum.ripe.net/t/viewing-probe-test-results/378/4 "2023-02-10T14:09:34Z")
Welcome! 🙂 The RIPE Atlas CLI (aka Magellan) is a tool that is maintained by the Atlas team itself. There are some other similar tools. RIPE Atlas internally uses JSON results; this tool is one that makes them simple to read. The web UI also does its best to render the results in a browser-friendly way. I guess it would be possible to add a page/tab in the UI for measurement results to “show the results like you would in a terminal”. Is that what you’re looking for? ---
**Author:** ![SimonC](https://avatars.discourse-cdn.com/v4/letter/s/87869e/32.png) [@SimonC](https://forum.ripe.net/u/SimonC)\ **Post date:** [10 February 2023 14:34 UTC](https://forum.ripe.net/t/viewing-probe-test-results/378/5 "2023-02-10T14:34:34Z")
Thanks & yes that sounds great. Coming from a Networking environment where pretty much everything is CLI based I find it much easier to see results as they happen and get the results in real time rather than wait 10mins to confirm a result (especially when doing live testing for an ongoing fault).