From julian.hammer at u-sys.org Mon Jul 1 10:13:39 2019 From: julian.hammer at u-sys.org (Julian Hammer) Date: Mon, 1 Jul 2019 10:13:39 +0200 Subject: [atlas] Search for Probe In-Reply-To: References: Message-ID: <1483DB39-0125-4D50-9E7D-96B87E497E4D@u-sys.org> Hallo Sascha, hast du schon eine? Falls nicht, schick mir mal deine Postanschrift. Gr??e aus Erlangen Julian > On 29. Jun 2019, at 16:20, Sascha Groetzner wrote: > > Hello, > I would like to take part at the ripe atlas grip. I applied already for a probe and still waiting for delivery since a long time. > Does anyone have a probe which isn`t in use or would like to transfer? > best regards > Sascha > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > From bortzmeyer at nic.fr Mon Jul 1 11:11:13 2019 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 1 Jul 2019 11:11:13 +0200 Subject: [atlas] Atlas problems this morning? Message-ID: <20190701091113.oleru2r2vyajtvlr@nic.fr> #22170557, #22171022 and #22171068 terminate but no results are available. Is there some problem going on? From jterbeest at ripe.net Mon Jul 1 11:20:04 2019 From: jterbeest at ripe.net (Johan ter Beest) Date: Mon, 1 Jul 2019 11:20:04 +0200 Subject: [atlas] Atlas problems this morning? In-Reply-To: <20190701091113.oleru2r2vyajtvlr@nic.fr> References: <20190701091113.oleru2r2vyajtvlr@nic.fr> Message-ID: Hi Stephane, > On 1 Jul 2019, at 11:11, Stephane Bortzmeyer wrote: > > #22170557, #22171022 and #22171068 terminate but no results are > available. Is there some problem going on? We?re currently having problems getting the results into HBase It?s slowly recovering and no results will be lost but it might take a few more hours at least until it?s stable again. You can use this call to check if the delay has returned to normal: https://atlas.ripe.net/api/v2/system/data-delay/ Delay should be no more than 100 when things are normal and probably between 20 and 60. Currently it?s at almost 15.000 Cheers, Johan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2634 bytes Desc: not available URL: From giovane.moura at sidn.nl Fri Jul 5 14:33:25 2019 From: giovane.moura at sidn.nl (Giovane Moura) Date: Fri, 5 Jul 2019 12:33:25 +0000 Subject: [atlas] DNS RTT over TCP: twice as long than UDP? Message-ID: Folks, This page at Atlas provides a great visualization on the RTT of DNS queries over TCP/UDP to the Root DNS servers: https://atlas.ripe.net/results/maps/root-server-performance/ We can see that the RTT of TCP queries is at least twice as long than UDP ones (which, according to the page " TCP is expected to be 2-3 times " longer. I cannot replicate these results in my setup, even in large scale from various vantage points: I always get very similar results for either TCP or UDP. Example: UDP: * $ dig example.nl @ns1.dns.nl Query time: 8 msec TCP: * $dig +tcp example.nl @ns1.dns.nl Query time: 9 msec I think there might be something with the definition of RTT. My hypothesis is that the field *rtt* on DNS queries on Atlas[1], for TCP, is, in fact, measuring 2 RTTs: the RTT of the TCP handshake, and the RTT of query/response itself. By definition, however, RTT is "the length of time it takes for a signal to be sent plus the length of time it takes for an acknowledgement of that signal to be received."[2]. So if DNS TCP measurements starts measuring from the SYN packet, that', in fact, be two RTTs. Is this the case with Atlas? I know it may sound a bit like nitpicking, but I just want to be sure of what's exactly being measured. thanks a lot, /giovane [1] https://atlas.ripe.net/docs/data_struct/#v4750_dns [2] https://en.wikipedia.org/wiki/Round-trip_delay_time From bortzmeyer at nic.fr Fri Jul 5 14:59:08 2019 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 5 Jul 2019 14:59:08 +0200 Subject: [atlas] DNS RTT over TCP: twice as long than UDP? In-Reply-To: References: Message-ID: <20190705125908.6ffz6xj6jwh3x3g2@sources.org> On Fri, Jul 05, 2019 at 12:33:25PM +0000, Giovane Moura wrote a message of 26 lines which said: > My hypothesis is that the field *rtt* on DNS queries on Atlas[1], > for TCP, is, in fact, measuring 2 RTTs: the RTT of the TCP > handshake, and the RTT of query/response itself. I assume (I didn't check with tcpdump) that Atlas starts the clock when the SYN packet leaves, and dig when the DNS request leaves. That would explain your observation. Both make sense, and I disagree when you say that the second method is the only right one. In practice, which method is the most relevant depends on whether you use persistent TCP connections or not. From philip.homburg at ripe.net Fri Jul 5 15:20:04 2019 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 5 Jul 2019 15:20:04 +0200 Subject: [atlas] DNS RTT over TCP: twice as long than UDP? In-Reply-To: References: Message-ID: <8f07d3c0-22b0-cda9-5cde-6a3eae13160d@ripe.net> On 2019/07/05 14:33 , Giovane Moura wrote: > https://atlas.ripe.net/results/maps/root-server-performance/ > > By definition, however, RTT is "the length of time it takes for a > signal to be sent plus the length of time it takes for an > acknowledgement of that signal to be received."[2]. So if DNS TCP > measurements starts measuring from the SYN packet, that', in fact, be > two RTTs. Is this the case with Atlas? The use of RTT on that page is wrong. The DNS measurement reports response time. Philip From gponikie at akamai.com Tue Jul 9 13:51:07 2019 From: gponikie at akamai.com (Ponikierski, Grzegorz) Date: Tue, 9 Jul 2019 11:51:07 +0000 Subject: [atlas] DNS RTT over TCP: twice as long than UDP? Message-ID: <6EB563C6-CDFE-496F-A340-D278D1E1EB3C@akamai.com> Just to confirm I verified what exactly dig measures. For example, this dig takes 8ms (which is always rounded): [gponikie at krk-mptoy atlas_day68_step1]$ dig +tcp example.com @1.1.1.1 ; <<>> DiG 9.14.3 <<>> +tcp example.com @1.1.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14416 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1452 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com. 5212 IN A 93.184.216.34 ;; Query time: 8 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ;; WHEN: Tue Jul 09 13:17:55 CEST 2019 ;; MSG SIZE rcvd: 56 If you check it with wireshark it looks like this: No. Time Source Destination Protocol Length Window size value Shift count Info 1 13:17:55.014898 192.168.1.83 1.1.1.1 TCP 78 65535 6 53593 ? 53 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=676915370 TSecr=0 SACK_PERM=1 2 13:17:55.029784 1.1.1.1 192.168.1.83 TCP 74 29200 10 53 ? 53593 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1412 SACK_PERM=1 WS=1024 3 13:17:55.029883 192.168.1.83 1.1.1.1 TCP 54 4096 53593 ? 53 [ACK] Seq=1 Ack=1 Win=262144 Len=0 4 13:17:55.030041 192.168.1.83 1.1.1.1 DNS 108 4096 Standard query 0x3850 A example.com OPT 5 13:17:55.038351 1.1.1.1 192.168.1.83 TCP 68 29 53 ? 53593 [ACK] Seq=1 Ack=55 Win=29696 Len=0 6 13:17:55.038572 1.1.1.1 192.168.1.83 DNS 120 29 Standard query response 0x3850 A example.com A 93.184.216.34 OPT 7 13:17:55.038624 192.168.1.83 1.1.1.1 TCP 54 4095 53593 ? 53 [ACK] Seq=55 Ack=59 Win=262080 Len=0 8 13:17:55.039580 192.168.1.83 1.1.1.1 TCP 54 4096 53593 ? 53 [FIN, ACK] Seq=55 Ack=59 Win=262144 Len=0 9 13:17:55.047201 1.1.1.1 192.168.1.83 TCP 68 29 53 ? 53593 [FIN, ACK] Seq=59 Ack=56 Win=29696 Len=0 10 13:17:55.047273 192.168.1.83 1.1.1.1 TCP 54 4096 53593 ? 53 [ACK] Seq=56 Ack=60 Win=262144 Len=0 From this traffic looks like dig measures time between packets 4 (DNS query) and 6 (DNS response) which is precisely 8.5ms and matches what dig shows. Including TCP handshake it takes 23.7ms, 2.8x longer which is expected . RTT can be measured on different layers for the same communication stream. In case of DNS over UDP we just ignores UDP overhead because it doesn't add any packets. With TCP additional packets are added which significantly increase time that end-user have to wait from first packet to get information that he/she needs. IMO RTT should always be measured from 1st packet to packet which has information that you have actual data. If we want to measure raw DNS performance without overhead then it must be explicitly market it measurement description. Regards, Grzegorz From: Giovane Moura Date: Friday 2019-07-05 at 14:34 To: "ripe-atlas at ripe.net" Subject: [atlas] DNS RTT over TCP: twice as long than UDP? Folks, This page at Atlas provides a great visualization on the RTT of DNS queries over TCP/UDP to the Root DNS servers: https://atlas.ripe.net/results/maps/root-server-performance/ We can see that the RTT of TCP queries is at least twice as long than UDP ones (which, according to the page " TCP is expected to be 2-3 times " longer. I cannot replicate these results in my setup, even in large scale from various vantage points: I always get very similar results for either TCP or UDP. Example: UDP: * $ dig example.nl @ns1.dns.nl Query time: 8 msec TCP: * $dig +tcp example.nl @ns1.dns.nl Query time: 9 msec I think there might be something with the definition of RTT. My hypothesis is that the field *rtt* on DNS queries on Atlas[1], for TCP, is, in fact, measuring 2 RTTs: the RTT of the TCP handshake, and the RTT of query/response itself. By definition, however, RTT is "the length of time it takes for a signal to be sent plus the length of time it takes for an acknowledgement of that signal to be received."[2]. So if DNS TCP measurements starts measuring from the SYN packet, that', in fact, be two RTTs. Is this the case with Atlas? I know it may sound a bit like nitpicking, but I just want to be sure of what's exactly being measured. thanks a lot, /giovane [1] https://atlas.ripe.net/docs/data_struct/#v4750_dns [2] https://en.wikipedia.org/wiki/Round-trip_delay_time -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgalante at ripe.net Tue Jul 9 16:56:22 2019 From: mgalante at ripe.net (Michela Galante) Date: Tue, 9 Jul 2019 16:56:22 +0200 Subject: [atlas] New on RIPE Labs: Internet Tools BoF Discovers Common Challenges for Network Operators Message-ID: <50E6744B-F833-47D2-8663-E3B57960BF2F@ripe.net> Dear colleagues, Here is a great summary provided by Sofia Silva Berenguer (APNIC) of the outcomes of the Internet Tools BoF organised at the recent LACNIC 31 meeting: https://labs.ripe.net/Members/sofia_silva_berenguer/internet-tools-bof-discovers-common-challenges-for-network-operators Kind regards, Michela Galante RIPE NCC From petr.spacek at nic.cz Wed Jul 10 09:15:16 2019 From: petr.spacek at nic.cz (=?UTF-8?B?UGV0ciDFoHBhxI1law==?=) Date: Wed, 10 Jul 2019 09:15:16 +0200 Subject: [atlas] DNS RTT over TCP: twice as long than UDP? In-Reply-To: <6EB563C6-CDFE-496F-A340-D278D1E1EB3C@akamai.com> References: <6EB563C6-CDFE-496F-A340-D278D1E1EB3C@akamai.com> Message-ID: <46fa70af-28e9-fbf3-4077-61a3d3be7696@nic.cz> On 09. 07. 19 13:51, Ponikierski, Grzegorz wrote: > From this traffic looks like dig measures time between packets 4 (DNS > query) and 6 (DNS response) which is precisely 8.5ms and matches what > dig shows. Including TCP handshake it takes 23.7ms, 2.8x longer which is > expected . > > ? > > RTT can be measured on different layers for the same communication > stream. In case of DNS over UDP we just ignores UDP overhead because it > doesn't add any packets. With TCP additional packets are added which > significantly increase time that end-user have to wait from first packet > to get information that he/she needs. IMO RTT should always be measured > from 1^st packet to packet which has information that you have actual > data. If we want to measure raw DNS performance without overhead then it > must be explicitly market it measurement description. If I could get a ponny, I would like to get both numbers: a) Time measured from moment of sending the very first packet (TCP SYN or UDP query) to arrival of DNS answer (not counting TCP FIN etc.). b) Time measured from moment of sending the DNS query (also think of TCP fast open!) to arrival of DNS answer (not counting TCP FIN etc.). Having both numbers would allow to calculate latency of connection vs. DNS query separately, which gets even more important when we consider DNS-over-TLS etc. -- Petr ?pa?ek @ CZ.NIC From gponikie at akamai.com Thu Jul 11 00:06:26 2019 From: gponikie at akamai.com (Ponikierski, Grzegorz) Date: Wed, 10 Jul 2019 22:06:26 +0000 Subject: [atlas] DNS RTT over TCP: twice as long than UDP? In-Reply-To: <46fa70af-28e9-fbf3-4077-61a3d3be7696@nic.cz> References: <6EB563C6-CDFE-496F-A340-D278D1E1EB3C@akamai.com> <46fa70af-28e9-fbf3-4077-61a3d3be7696@nic.cz> Message-ID: Count me in for second pony :D Regards, Grzegorz From: Petr ?pa?ek Organization: CZ.NIC Date: Wednesday 2019-07-10 at 09:14 To: "ripe-atlas at ripe.net" Subject: Re: [atlas] DNS RTT over TCP: twice as long than UDP? On 09. 07. 19 13:51, Ponikierski, Grzegorz wrote: From this traffic looks like dig measures time between packets 4 (DNS query) and 6 (DNS response) which is precisely 8.5ms and matches what dig shows. Including TCP handshake it takes 23.7ms, 2.8x longer which is expected . RTT can be measured on different layers for the same communication stream. In case of DNS over UDP we just ignores UDP overhead because it doesn't add any packets. With TCP additional packets are added which significantly increase time that end-user have to wait from first packet to get information that he/she needs. IMO RTT should always be measured from 1^st packet to packet which has information that you have actual data. If we want to measure raw DNS performance without overhead then it must be explicitly market it measurement description. If I could get a ponny, I would like to get both numbers: a) Time measured from moment of sending the very first packet (TCP SYN or UDP query) to arrival of DNS answer (not counting TCP FIN etc.). b) Time measured from moment of sending the DNS query (also think of TCP fast open!) to arrival of DNS answer (not counting TCP FIN etc.). Having both numbers would allow to calculate latency of connection vs. DNS query separately, which gets even more important when we consider DNS-over-TLS etc. -- Petr ?pa?ek @ CZ.NIC -------------- next part -------------- An HTML attachment was scrubbed... URL: From kiran.gunana at colruytgroup.com Thu Jul 11 08:16:02 2019 From: kiran.gunana at colruytgroup.com (kiran.gunana at colruytgroup.com) Date: Thu, 11 Jul 2019 08:16:02 +0200 (CEST) Subject: [atlas] how to earn credits com236.252.126 Message-ID: <-103926145.530947.1562825761820.JavaMail.was@svpapc06> Hello, I am running my probe since 3 weeks and I spent almost 1milion credits for measuring some metrics, however I am not able to earn any credits. Can some give me the steps to enable me earning some credits as well. rg, kiran. Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.oghia at gmail.com Thu Jul 11 08:33:51 2019 From: mike.oghia at gmail.com (Michael J. Oghia) Date: Thu, 11 Jul 2019 08:33:51 +0200 Subject: [atlas] how to earn credits com236.252.126 In-Reply-To: <-103926145.530947.1562825761820.JavaMail.was@svpapc06> References: <-103926145.530947.1562825761820.JavaMail.was@svpapc06> Message-ID: Can we just transfer you some credits? Most of us have a massive surplus. Let us know your preferred email address. Best, -Michael On Thu, Jul 11, 2019, 8:16 AM wrote: > Hello, > > I am running my probe since 3 weeks and I spent almost 1milion credits for > measuring some metrics, however I am not able to earn any credits. > > Can some give me the steps to enable me earning some credits as well. > > rg, kiran. > > > > *Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website > Ce message est soumis > aux conditions disponibles sur notre site web > This message > is subject to the terms and conditions available on our website > * -------------- next part -------------- An HTML attachment was scrubbed... URL: From kiran.gunana at colruytgroup.com Thu Jul 11 09:10:54 2019 From: kiran.gunana at colruytgroup.com (kiran.gunana at colruytgroup.com) Date: Thu, 11 Jul 2019 09:10:54 +0200 (CEST) Subject: [atlas] how to earn credits com236.259.148 Message-ID: <1614856300.344843.1562829054706.JavaMail.was@svpapc94> Hello Michael, Thanks alot for the good gesture, me too got some good number of credits for now however just wondering after 3 months I will loose them all if I keep doing the same measurments. So looking for a way to earn some credits. rg, kiran ----- Original Message: com236.253.880 --------------------------------- From: Michael J. Oghia (mike.oghia at gmail.com) To: kiran.gunana at colruytgroup.com Copy: ripe-atlas at ripe.net Subject: Re: [atlas] how to earn credits com236.252.126 Date: 11 July 2019 (08:34) Can we just transfer you some credits? Most of us have a massive surplus. Let us know your preferred email address. Best, -Michael On Thu, Jul 11, 2019, 8:16 AM wrote: Hello, I am running my probe since 3 weeks and I spent almost 1milion credits for measuring some metrics, however I am not able to earn any credits. Can some give me the steps to enable me earning some credits as well. rg, kiran. Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.havern at geant.org Thu Jul 11 11:29:15 2019 From: richard.havern at geant.org (Rick Havern) Date: Thu, 11 Jul 2019 09:29:15 +0000 Subject: [atlas] how to earn credits com236.259.148 In-Reply-To: <1614856300.344843.1562829054706.JavaMail.was@svpapc94> References: <1614856300.344843.1562829054706.JavaMail.was@svpapc94> Message-ID: If you operate an Atlas anchor, that will earn a lot more credits, 10x from memory, as compared to a probe. As Michael stated, there are many of us that have multi-billion credit surpluses that we are willing to share. Regards Rick From: ripe-atlas On Behalf Of kiran.gunana at colruytgroup.com Sent: 11 July 2019 08:11 To: mike.oghia at gmail.com Cc: ripe-atlas at ripe.net Subject: Re: [atlas] how to earn credits com236.259.148 Hello Michael, Thanks alot for the good gesture, me too got some good number of credits for now however just wondering after 3 months I will loose them all if I keep doing the same measurments. So looking for a way to earn some credits. rg, kiran ----- Original Message: com236.253.880 --------------------------------- From: Michael J. Oghia (mike.oghia at gmail.com) To: kiran.gunana at colruytgroup.com Copy: ripe-atlas at ripe.net Subject: Re: [atlas] how to earn credits com236.252.126 Date: 11 July 2019 (08:34) Can we just transfer you some credits? Most of us have a massive surplus. Let us know your preferred email address. Best, -Michael On Thu, Jul 11, 2019, 8:16 AM > wrote: Hello, I am running my probe since 3 weeks and I spent almost 1milion credits for measuring some metrics, however I am not able to earn any credits. Can some give me the steps to enable me earning some credits as well. rg, kiran. Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website -------------- next part -------------- An HTML attachment was scrubbed... URL: From jterbeest at ripe.net Thu Jul 11 12:06:58 2019 From: jterbeest at ripe.net (Johan ter Beest) Date: Thu, 11 Jul 2019 12:06:58 +0200 Subject: [atlas] how to earn credits com236.259.148 In-Reply-To: <1614856300.344843.1562829054706.JavaMail.was@svpapc94> References: <1614856300.344843.1562829054706.JavaMail.was@svpapc94> Message-ID: Hi Kiran, You earn credits for the uptime of a probe and the delivered results for measurements that other hosts run towards your probe. Everything is explained here: https://atlas.ripe.net/docs/credits/ If your probe is not earning you any credits then there are two possible reasons: - your probe is not connected - you have not registered your probe so we don?t know who to give the credits to. I don?t know your probe ID so I. Cannot check but it?s most likely that it?s not registered. You can do that here: https://atlas.ripe.net/register/ If you send me a private email with your probe ID, I will give you the credits you should have earned in the last three weeks. Kind regards, Johan ter Beest RIPE Atlas. Team > On 11 Jul 2019, at 09:10, kiran.gunana at colruytgroup.com wrote: > > Hello Michael, > > Thanks alot for the good gesture, me too got some good number of credits for now however just wondering after 3 months I will loose them all if I keep doing the same measurments. > > So looking for a way to earn some credits. > > rg, kiran > > ----- Original Message: com236.253.880 --------------------------------- > > From: Michael J. Oghia (mike.oghia at gmail.com) > To: kiran.gunana at colruytgroup.com > Copy: ripe-atlas at ripe.net > Subject: Re: [atlas] how to earn credits com236.252.126 > Date: 11 July 2019 (08:34) > > > > Can we just transfer you some credits? Most of us have a massive surplus. Let us know your preferred email address. > > Best, > -Michael > > On Thu, Jul 11, 2019, 8:16 AM > wrote: > Hello, > > I am running my probe since 3 weeks and I spent almost 1milion credits for measuring some metrics, however I am not able to earn any credits. > > Can some give me the steps to enable me earning some credits as well. > > rg, kiran. > > > > > Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website > Ce message est soumis aux conditions disponibles sur notre site web > This message is subject to the terms and conditions available on our website > > > > > Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website > Ce message est soumis aux conditions disponibles sur notre site web > This message is subject to the terms and conditions available on our website -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2634 bytes Desc: not available URL: From kiran.gunana at colruytgroup.com Thu Jul 11 12:35:07 2019 From: kiran.gunana at colruytgroup.com (kiran.gunana at colruytgroup.com) Date: Thu, 11 Jul 2019 12:35:07 +0200 (CEST) Subject: [atlas] how to earn credits com236.294.813 Message-ID: <-1819005786.353357.1562841307800.JavaMail.was@svpapc94> Hello Johan, My probe ID is 32256, It is registered and reachable from last 3 weeks, can you please check if I still need to do something to earn my credits. rg, kiran. ----- Original Message: com236.291.250 --------------------------------- From: Johan ter Beest (jterbeest at ripe.net) To: kiran.gunana at colruytgroup.com Copy: ripe-atlas at ripe.net Subject: Re: [atlas] how to earn credits com236.259.148 Date: 11 July 2019 (12:07) Hi Kiran, You earn credits for the uptime of a probe and the delivered results for measurements that other hosts run towards your probe. Everything is explained here: https://atlas.ripe.net/docs/credits/ If your probe is not earning you any credits then there are two possible reasons: - your probe is not connected - you have not registered your probe so we don?t know who to give the credits to. I don?t know your probe ID so I. Cannot check but it?s most likely that it?s not registered. You can do that here: https://atlas.ripe.net/register/ If you send me a private email with your probe ID, I will give you the credits you should have earned in the last three weeks. Kind regards, Johan ter Beest RIPE Atlas. Team On 11 Jul 2019, at 09:10, kiran.gunana at colruytgroup.com wrote: Hello Michael, Thanks alot for the good gesture, me too got some good number of credits for now however just wondering after 3 months I will loose them all if I keep doing the same measurments. So looking for a way to earn some credits. rg, kiran ----- Original Message: com236.253.880 --------------------------------- From: Michael J. Oghia (mike.oghia at gmail.com) To: kiran.gunana at colruytgroup.com Copy: ripe-atlas at ripe.net Subject: Re: [atlas] how to earn credits com236.252.126 Date: 11 July 2019 (08:34) Can we just transfer you some credits? Most of us have a massive surplus. Let us know your preferred email address. Best, -Michael On Thu, Jul 11, 2019, 8:16 AM wrote: Hello, I am running my probe since 3 weeks and I spent almost 1milion credits for measuring some metrics, however I am not able to earn any credits. Can some give me the steps to enable me earning some credits as well. rg, kiran. Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Mon Jul 15 12:00:16 2019 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 15 Jul 2019 12:00:16 +0200 Subject: [atlas] Scheduled work on RIPE Atlas Message-ID: <90f852c6-7f39-c019-399c-686f28b006d8@ripe.net> Dear RIPE Atlas users, We have planned maintenance on the main RIPE Atlas backend database tomorrow (Tuesday, 16 July) starting at 08:00 UTC, 10:00 Amsterdam local time. We expect complete unavailability of the service for a short while and further intermittent delays during the day. During this time the website (UI and APIs) will not be responding (properly). This also means that requests for new measurements will be denied or delayed. Data from existing measurements will still be collected normally, though access to them will be impacted. Our apologies for the inconvenience. Regards, Robert Kisteleki From robert at ripe.net Tue Jul 16 13:46:43 2019 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 16 Jul 2019 13:46:43 +0200 Subject: [atlas] Scheduled work on RIPE Atlas In-Reply-To: <90f852c6-7f39-c019-399c-686f28b006d8@ripe.net> References: <90f852c6-7f39-c019-399c-686f28b006d8@ripe.net> Message-ID: <9002861e-c226-a7ae-924d-d48e49f2285f@ripe.net> Dear All, The publicly visible part of this work finished around noon (local time) and all functions should be back to normal. Regards, Robert On 2019-07-15 12:00, Robert Kisteleki wrote: > Dear RIPE Atlas users, > > We have planned maintenance on the main RIPE Atlas backend database > tomorrow (Tuesday, 16 July) starting at 08:00 UTC, 10:00 Amsterdam local > time. We expect complete unavailability of the service for a short while > and further intermittent delays during the day. > > During this time the website (UI and APIs) will not be responding > (properly). This also means that requests for new measurements will be > denied or delayed. Data from existing measurements will still be > collected normally, though access to them will be impacted. > > Our apologies for the inconvenience. > > Regards, > Robert Kisteleki > > From gponikie at akamai.com Thu Jul 18 12:05:22 2019 From: gponikie at akamai.com (Ponikierski, Grzegorz) Date: Thu, 18 Jul 2019 10:05:22 +0000 Subject: [atlas] Scheduled work on RIPE Atlas In-Reply-To: <9002861e-c226-a7ae-924d-d48e49f2285f@ripe.net> References: <90f852c6-7f39-c019-399c-686f28b006d8@ripe.net> <9002861e-c226-a7ae-924d-d48e49f2285f@ripe.net> Message-ID: <0878C4F3-34BF-454D-A353-065784880700@akamai.com> Hi! Does this maintenance was related with DNS measurements? I generated today 60 DNS, got their IDs, I see in web UI that they are running but when I want to open them or search for them I get nulls or messages like " This measurement most probably does not exist (yet).". Can you for example check measurement 22378601? Regards, Grzegorz From: Robert Kisteleki Organization: RIPE NCC Date: Tuesday 2019-07-16 at 13:47 To: "ripe-atlas at ripe.net" Subject: Re: [atlas] Scheduled work on RIPE Atlas Dear All, The publicly visible part of this work finished around noon (local time) and all functions should be back to normal. Regards, Robert On 2019-07-15 12:00, Robert Kisteleki wrote: Dear RIPE Atlas users, We have planned maintenance on the main RIPE Atlas backend database tomorrow (Tuesday, 16 July) starting at 08:00 UTC, 10:00 Amsterdam local time. We expect complete unavailability of the service for a short while and further intermittent delays during the day. During this time the website (UI and APIs) will not be responding (properly). This also means that requests for new measurements will be denied or delayed. Data from existing measurements will still be collected normally, though access to them will be impacted. Our apologies for the inconvenience. Regards, Robert Kisteleki -------------- next part -------------- An HTML attachment was scrubbed... URL: From camin at ripe.net Thu Jul 18 13:33:46 2019 From: camin at ripe.net (Chris Amin) Date: Thu, 18 Jul 2019 13:33:46 +0200 Subject: [atlas] Scheduled work on RIPE Atlas In-Reply-To: <0878C4F3-34BF-454D-A353-065784880700@akamai.com> References: <90f852c6-7f39-c019-399c-686f28b006d8@ripe.net> <9002861e-c226-a7ae-924d-d48e49f2285f@ripe.net> <0878C4F3-34BF-454D-A353-065784880700@akamai.com> Message-ID: <2865e0c0-467e-dee6-88a5-581a7eece4d5@ripe.net> Hi Grzegorz, Apologies for this, it was actually an unrelated issue to do with synchronizing certain DNS measurements. Those measurements should now work as normal. Regards, Chris Amin RIPE NCC On 18/07/2019 12:05, Ponikierski, Grzegorz wrote: > Hi! > > ? > > Does this maintenance was related with DNS measurements? I generated > today 60 DNS, got their IDs, I see in web UI that they are running but > when I want to open them or search for them I get nulls or messages like > "This measurement most probably does not exist (yet).". Can you for > example check measurement *22378601*? > > ? > > Regards, > > Grzegorz > > ? > > *From: *Robert Kisteleki > *Organization: *RIPE NCC > *Date: *Tuesday 2019-07-16 at 13:47 > *To: *"ripe-atlas at ripe.net" > *Subject: *Re: [atlas] Scheduled work on RIPE Atlas > > ? > > ? > > Dear All, > > ? > > The publicly visible part of this work finished around noon (local time) > > and all functions should be back to normal. > > ? > > Regards, > > Robert > > ? > > ? > > On 2019-07-15 12:00, Robert Kisteleki wrote: > > Dear RIPE Atlas users, > > We have planned maintenance on the main RIPE Atlas backend database > > tomorrow (Tuesday, 16 July) starting at 08:00 UTC, 10:00 Amsterdam local > > time. We expect complete unavailability of the service for a short while > > and further intermittent delays during the day. > > During this time the website (UI and APIs) will not be responding > > (properly). This also means that requests for new measurements will be > > denied or delayed. Data from existing measurements will still be > > collected normally, though access to them will be impacted. > > Our apologies for the inconvenience. > > Regards, > > Robert Kisteleki > > ? > > ? > From gponikie at akamai.com Thu Jul 18 14:24:09 2019 From: gponikie at akamai.com (Ponikierski, Grzegorz) Date: Thu, 18 Jul 2019 12:24:09 +0000 Subject: [atlas] Scheduled work on RIPE Atlas In-Reply-To: <2865e0c0-467e-dee6-88a5-581a7eece4d5@ripe.net> References: <90f852c6-7f39-c019-399c-686f28b006d8@ripe.net> <9002861e-c226-a7ae-924d-d48e49f2285f@ripe.net> <0878C4F3-34BF-454D-A353-065784880700@akamai.com> <2865e0c0-467e-dee6-88a5-581a7eece4d5@ripe.net> Message-ID: <3C814FDA-AAC9-4DF7-96FC-7C241DE89C8F@akamai.com> Works like magic. Thank you! Regards, Grzegorz From: Chris Amin Date: Thursday 2019-07-18 at 13:34 To: "ripe-atlas at ripe.net" Subject: Re: [atlas] Scheduled work on RIPE Atlas Hi Grzegorz, Apologies for this, it was actually an unrelated issue to do with synchronizing certain DNS measurements. Those measurements should now work as normal. Regards, Chris Amin RIPE NCC On 18/07/2019 12:05, Ponikierski, Grzegorz wrote: Hi! Does this maintenance was related with DNS measurements? I generated today 60 DNS, got their IDs, I see in web UI that they are running but when I want to open them or search for them I get nulls or messages like "This measurement most probably does not exist (yet).". Can you for example check measurement *22378601*? Regards, Grzegorz *From: *Robert Kisteleki > *Organization: *RIPE NCC *Date: *Tuesday 2019-07-16 at 13:47 *To: *"ripe-atlas at ripe.net" > *Subject: *Re: [atlas] Scheduled work on RIPE Atlas Dear All, The publicly visible part of this work finished around noon (local time) and all functions should be back to normal. Regards, Robert On 2019-07-15 12:00, Robert Kisteleki wrote: Dear RIPE Atlas users, We have planned maintenance on the main RIPE Atlas backend database tomorrow (Tuesday, 16 July) starting at 08:00 UTC, 10:00 Amsterdam local time. We expect complete unavailability of the service for a short while and further intermittent delays during the day. During this time the website (UI and APIs) will not be responding (properly). This also means that requests for new measurements will be denied or delayed. Data from existing measurements will still be collected normally, though access to them will be impacted. Our apologies for the inconvenience. Regards, Robert Kisteleki -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsommers at colgate.edu Mon Jul 22 00:16:02 2019 From: jsommers at colgate.edu (Joel Sommers) Date: Sun, 21 Jul 2019 18:16:02 -0400 Subject: [atlas] Question about built-in first/second hop latency measurements Message-ID: <9BAD5505-0D05-4F8C-9D55-0B0E281D8BE2@colgate.edu> Hello all, For the built-in latency measurements to first/second hops, my assumption has pretty much always been that these are done with hop-limited probes (i.e., with TTL or hop limit set to 1 or 2). Is that true, or are these measurements taken using ?direct? pings? Thanks! Joel From camin at ripe.net Mon Jul 22 13:24:48 2019 From: camin at ripe.net (Chris Amin) Date: Mon, 22 Jul 2019 13:24:48 +0200 Subject: [atlas] Question about built-in first/second hop latency measurements In-Reply-To: <9BAD5505-0D05-4F8C-9D55-0B0E281D8BE2@colgate.edu> References: <9BAD5505-0D05-4F8C-9D55-0B0E281D8BE2@colgate.edu> Message-ID: <02181ea2-8fa3-c231-847c-191fc40f985f@ripe.net> Hi Joel, Results from measurements 1 and 2 are really the first and second hops of a single traceroute measurement with a max_hops value of 2. Regards, Chris Amin RIPE NCC On 22/07/2019 00:16, Joel Sommers wrote: > Hello all, > > For the built-in latency measurements to first/second hops, my assumption has pretty much always been that these are done with hop-limited probes (i.e., with TTL or hop limit set to 1 or 2). Is that true, or are these measurements taken using ?direct? pings? > > Thanks! > > Joel > > > From furry13 at gmail.com Mon Jul 22 21:51:05 2019 From: furry13 at gmail.com (Jen Linkova) Date: Tue, 23 Jul 2019 05:51:05 +1000 Subject: [atlas] Feature Request to consider: DNS response IP header In-Reply-To: <4f48bcbd-839d-9883-76d3-23a86d9e8b8b@ripe.net> References: <4492177B-F513-440B-98B4-EB3D252BD0B9@akamai.com> <4f48bcbd-839d-9883-76d3-23a86d9e8b8b@ripe.net> Message-ID: Hi Philip, Sorry, I've realised I did not replied.. Actually I'd be very happy if I can get HopLimit/TTL field. On Sat, Jun 1, 2019 at 12:51 AM Philip Homburg wrote: > > On 2019/05/30 15:22 , Ponikierski, Grzegorz wrote: > > Can be useful to estimate proximity between probe and DNS and to detect > > nasty middle boxes. To limit overhead on Atlas side, IP header can be > > provided as raw data to decode on end-user side. > > As far as I know there is no option provided by the Linux kernel to > receive the original IP header with recvmsg. > > Fields that are returned by recvmsg, such as TTL, can be added without > to much trouble. I'll make a note to add that that at some point. > > Philip > -- SY, Jen Linkova aka Furry