From jerome.benoit at grenouille.com Mon Jun 11 02:33:55 2012 From: jerome.benoit at grenouille.com (=?ISO-8859-1?B?Suly9G1l?= Benoit) Date: Mon, 11 Jun 2012 02:33:55 +0200 Subject: [atlas] Feature-suggestion: "round-robin" probes In-Reply-To: <20120509233225.35568b93@nemesis.grenouille.com> References: <19F54F2956911544A32543B8A9BDE07505A6A9@NICS-EXCH.sbg.nic.at> <4F9A7E73.2040604@sidn.nl> <20120504231732.007ad2cd@nemesis.grenouille.com> <4FA4FF57.7050104@ripe.net> <20120505164343.3b3e2fc4@nemesis.grenouille.com> <4FA7BCDE.1060905@ripe.net> <20120507214423.5b08f0f3@nemesis.grenouille.com> <4FAA36E6.6060101@ripe.net> <20120509233225.35568b93@nemesis.grenouille.com> Message-ID: <20120611023355.51e49113@nemesis.grenouille.com> On Wed, 9 May 2012 23:32:25 +0200 J?r?me Benoit wrote: > > > > We have this as internal documentation, but it should be published > > some time. > > > > Let me known when the dust has settled and RIPE publish them. > > > > For API and JSON syntax standardisation, the first step is to > > > write the specifications we(grenouille.com) plan to use and Atlas > > > use and plan to use, then discuss and factor out the best of > > > each. We have some writings but most of them are in French :) > > Yes. > > Great. We're going to translate some already written and document the > whole architecture in details. > First draft online : http://doc.grenouille.com/index.en.html I know, there's still a lot of TODO :) Regards, -- J?r?me Benoit aka fraggle La M?t?o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From abarcomb at ripe.net Mon Jun 18 14:01:35 2012 From: abarcomb at ripe.net (Ann Barcomb) Date: Mon, 18 Jun 2012 14:01:35 +0200 Subject: [atlas] Changes to RIPE Atlas raw data structures Message-ID: <4FDF189F.6070204@ripe.net> Hi, We are planning on updating RIPE Atlas probe firmware, which will lead to some changes in the raw data structures. An article about this has been posted on Labs: https://labs.ripe.net/Members/emileaben/ripe-atlas-data-structure-changes We don't plan to announce these changes to this list in the future, because this list is for a more general audience and this information may not be of general interest. Instead, we have created an RSS feed for these types of announcements: https://atlas.ripe.net/atlas/feed/ Kind Regards, Ann -- Ann Barcomb RIPE NCC Community Builder http://www.ripe.net Measurements Community Building +31 20 535 4444 From kix at kix.es Mon Jun 18 18:36:02 2012 From: kix at kix.es (Rodolfo kix Garcia) Date: Mon, 18 Jun 2012 18:36:02 +0200 Subject: [atlas] Changes to RIPE Atlas raw data structures In-Reply-To: <4FDF189F.6070204@ripe.net> References: <4FDF189F.6070204@ripe.net> Message-ID: <6cd732c9f8214d36aa3363e31391a3a0@kix.es> El 18.06.2012 14:01, Ann Barcomb escribi?: > Hi, > > We are planning on updating RIPE Atlas probe firmware, which will > lead > to some changes in the raw data structures. An article about this > has > been posted on Labs: > > > https://labs.ripe.net/Members/emileaben/ripe-atlas-data-structure-changes > > We don't plan to announce these changes to this list in the future, > because this list is for a more general audience and this information > may not be of general interest. Instead, we have created an RSS feed > for these types of announcements: > > https://atlas.ripe.net/atlas/feed/ > > Kind Regards, > Ann Hi Ann, thanks for your information. If you can, please continue sending this announces to this mail list, because IMO the mail list has low traffic and this announces are interesting. Thanks kix. -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ From bo.sixten.staahle at uni-c.dk Mon Jun 18 19:10:52 2012 From: bo.sixten.staahle at uni-c.dk (Bo =?utf-8?Q?St=C3=A5hle?=) Date: Mon, 18 Jun 2012 19:10:52 +0200 Subject: [atlas] Changes to RIPE Atlas raw data structures In-Reply-To: <6cd732c9f8214d36aa3363e31391a3a0@kix.es> References: <4FDF189F.6070204@ripe.net> <6cd732c9f8214d36aa3363e31391a3a0@kix.es> Message-ID: <20120618171052.GD2649@uni-c.dk> On Jun 18 18:36, Rodolfo kix Garcia wrote: > thanks for your information. If you can, please continue sending > this announces to this mail list, because > IMO the mail list has low traffic and this announces are interesting. > +1 or 3 actually ;-) Regards, Bo Sixten St?hle Mail: Bo.Staahle at uni-c.dk Tel: +45 3587 8265 - Mob: +45 2921 6751 - Home Office: +45 3694 7417 From rsmithy at cluenet.org Mon Jun 18 19:32:16 2012 From: rsmithy at cluenet.org (Richard Smith) Date: Mon, 18 Jun 2012 18:32:16 +0100 Subject: [atlas] Fwd: Changes to RIPE Atlas raw data structures References: <20120618171052.GD2649@uni-c.dk> Message-ID: Excuse the double email, but +1 as well ;) Rich Smith Begin forwarded message: > From: Bo St?hle > Date: 18 June 2012 18:10:52 GMT+01:00 > To: ripe-atlas at ripe.net > Subject: Re: [atlas] Changes to RIPE Atlas raw data structures > > On Jun 18 18:36, Rodolfo kix Garcia wrote: >> thanks for your information. If you can, please continue sending >> this announces to this mail list, because >> IMO the mail list has low traffic and this announces are interesting. >> > > +1 or 3 actually ;-) > > Regards, > Bo Sixten St?hle > Mail: Bo.Staahle at uni-c.dk > Tel: +45 3587 8265 - Mob: +45 2921 6751 - Home Office: +45 3694 7417 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsmithy at cluenet.org Mon Jun 18 19:31:28 2012 From: rsmithy at cluenet.org (Richard Smith) Date: Mon, 18 Jun 2012 18:31:28 +0100 Subject: [atlas] Fwd: Changes to RIPE Atlas raw data structures References: <20120618171052.GD2649@uni-c.dk> Message-ID: Begin forwarded message: > From: Bo St?hle > Date: 18 June 2012 18:10:52 GMT+01:00 > To: ripe-atlas at ripe.net > Subject: Re: [atlas] Changes to RIPE Atlas raw data structures > > On Jun 18 18:36, Rodolfo kix Garcia wrote: >> thanks for your information. If you can, please continue sending >> this announces to this mail list, because >> IMO the mail list has low traffic and this announces are interesting. >> > > +1 or 3 actually ;-) > > Regards, > Bo Sixten St?hle > Mail: Bo.Staahle at uni-c.dk > Tel: +45 3587 8265 - Mob: +45 2921 6751 - Home Office: +45 3694 7417 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank at villaro-dixon.eu Mon Jun 18 21:38:45 2012 From: frank at villaro-dixon.eu (Frank Villaro-Dixon) Date: Mon, 18 Jun 2012 21:38:45 +0200 Subject: [atlas] Fwd: Changes to RIPE Atlas raw data structures In-Reply-To: References: <20120618171052.GD2649@uni-c.dk> Message-ID: <4FDF83C5.20101@villaro-dixon.eu> On 18. 06. 12 19:32, Richard Smith wrote: > Excuse the double email, but +1 as well ;) > > Rich Smith > > > Begin forwarded message: > >> *From:* Bo St?hle > > >> *Date:* 18 June 2012 18:10:52 GMT+01:00 >> *To:* ripe-atlas at ripe.net >> *Subject:* *Re: [atlas] Changes to RIPE Atlas raw data structures* >> >> On Jun 18 18:36, Rodolfo kix Garcia wrote: >>> thanks for your information. If you can, please continue sending >>> this announces to this mail list, because >>> IMO the mail list has low traffic and this announces are interesting. >>> >> >> +1 or 3 actually ;-) >> >> Regards, >> Bo Sixten St?hle >> Mail: Bo.Staahle at uni-c.dk >> Tel: +45 3587 8265 - Mob: +45 2921 6751 - Home Office: +45 3694 7417 >> Last spam ;) : +1 Cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Tue Jun 19 00:18:13 2012 From: randy at psg.com (Randy Bush) Date: Tue, 19 Jun 2012 07:18:13 +0900 Subject: [atlas] Changes to RIPE Atlas raw data structures In-Reply-To: <20120618171052.GD2649@uni-c.dk> References: <4FDF189F.6070204@ripe.net> <6cd732c9f8214d36aa3363e31391a3a0@kix.es> <20120618171052.GD2649@uni-c.dk> Message-ID: >> thanks for your information. If you can, please continue sending this >> announces to this mail list, because IMO the mail list has low >> traffic and this announces are interesting. > +1 or 3 actually ;-) +1 randy, who knows rtt, but what is rss? From abarcomb at ripe.net Tue Jun 19 10:26:09 2012 From: abarcomb at ripe.net (Ann Barcomb) Date: Tue, 19 Jun 2012 10:26:09 +0200 Subject: [atlas] Fwd: Changes to RIPE Atlas raw data structures In-Reply-To: References: <20120618171052.GD2649@uni-c.dk> Message-ID: <4FE037A1.7050202@ripe.net> It seems pretty clear that you'd like the updates on firmware changes here as well, so we will continue to post them here as well as on the RSS feed. Thanks for letting us know! - Ann From randy at psg.com Wed Jun 20 09:11:43 2012 From: randy at psg.com (Randy Bush) Date: Wed, 20 Jun 2012 16:11:43 +0900 Subject: [atlas] probe resolution, overhead, or ...? Message-ID: we want to use atlas probes in an experiment. being prudent (you can tell it was not i), we decided to try to get some basic calibration. one run was just on a local LAN. three hosts on the same gige switch o probe 2285 o psg.com, a not very fancy or fast freebsd 9 box with intel/pro1000 gige ports o bbgp.psg.com, a funky older freebsd 9 box with bge gige probe 2285 pinging bbgp.psg.com, average RTT: 1.5606994382 [0], number of pings: 356*3 psg.com pinging bbgp.psg.com, average RTT: 0.253424332344 [0], number of pings: 674 has anyone done similar probe calibration experiments? does anyone have any clue as to why the difference? randy [0] - my favorite precision joke A gentleman accosts a guard in the museum and asks, "How old is that mummy?" The guard responds, "I believe it is 2005 years old." The gentleman asks "Why that particular age, 2005?" The guard responds "Well, I was told it was 2000 years old when I started work here five years ago." From philip.homburg at ripe.net Wed Jun 20 10:48:48 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 20 Jun 2012 10:48:48 +0200 Subject: [atlas] probe resolution, overhead, or ...? In-Reply-To: References: Message-ID: <4FE18E70.30605@ripe.net> On 6/20/12 9:11 , Randy Bush wrote: > we want to use atlas probes in an experiment. being prudent (you can > tell it was not i), we decided to try to get some basic calibration. > one run was just on a local LAN. > > three hosts on the same gige switch > o probe 2285 > o psg.com, a not very fancy or fast freebsd 9 box with intel/pro1000 > gige ports > o bbgp.psg.com, a funky older freebsd 9 box with bge gige > > probe 2285 pinging bbgp.psg.com, average RTT: 1.5606994382 [0], number > of pings: 356*3 > > psg.com pinging bbgp.psg.com, average RTT: 0.253424332344 [0], number of > pings: 674 > > has anyone done similar probe calibration experiments? does anyone have > any clue as to why the difference? > > Just to confirm my suspicion, I tried to other way around: This is an old AMD64 running FreeBSD pinging an Atlas probe on the same LAN: $ ping 130.37.15.50 PING 130.37.15.50 (130.37.15.50): 56 data bytes 64 bytes from 130.37.15.50: icmp_seq=0 ttl=64 time=2.515 ms 64 bytes from 130.37.15.50: icmp_seq=1 ttl=64 time=0.913 ms 64 bytes from 130.37.15.50: icmp_seq=2 ttl=64 time=0.915 ms 64 bytes from 130.37.15.50: icmp_seq=3 ttl=64 time=0.929 ms And this is the same FreeBSD box pinging a Celeron 766 MHz, running a micro kernel operating system, also on the same LAN: $ ping prism PING prism.hq.phicoh.net (130.37.15.36): 56 data bytes 64 bytes from 130.37.15.36: icmp_seq=0 ttl=96 time=0.364 ms 64 bytes from 130.37.15.36: icmp_seq=1 ttl=96 time=0.210 ms 64 bytes from 130.37.15.36: icmp_seq=2 ttl=96 time=0.211 ms 64 bytes from 130.37.15.36: icmp_seq=3 ttl=96 time=0.214 ms This does not involve any of the Atlas software, just the ucLinux kernel running on the probe. My conclusion is: probes are just very slow. They are fine for measuring multi millisecond delays on WAN links but not for sub-millisecond delays on local links. From steliosm at gmail.com Wed Jun 20 11:04:07 2012 From: steliosm at gmail.com (Stelios M.) Date: Wed, 20 Jun 2012 12:04:07 +0300 Subject: [atlas] probe resolution, overhead, or ...? In-Reply-To: <4FE18E70.30605@ripe.net> References: <4FE18E70.30605@ripe.net> Message-ID: Hello Philip. Ping relies heavily on the system's CPU. That is why it is considered unreliable for measuring when you are pinging CPU loaded machines/devices. The CPU on the probe is a n ARM7TDMI running at 55MHz, based on information from this link: http://www.digi.com/products/wireless-wired-embedded-solutions/solutions-on-module/digi-connect/digiconnectme#specs Regards, Stelios Mersinas On Wed, Jun 20, 2012 at 11:48 AM, Philip Homburg wrote: > On 6/20/12 9:11 , Randy Bush wrote: > >> we want to use atlas probes in an experiment. being prudent (you can >> tell it was not i), we decided to try to get some basic calibration. >> one run was just on a local LAN. >> >> three hosts on the same gige switch >> o probe 2285 >> o psg.com, a not very fancy or fast freebsd 9 box with intel/pro1000 >> gige ports >> o bbgp.psg.com, a funky older freebsd 9 box with bge gige >> >> probe 2285 pinging bbgp.psg.com, average RTT: 1.5606994382 [0], number >> of pings: 356*3 >> >> psg.com pinging bbgp.psg.com, average RTT: 0.253424332344 [0], number of >> pings: 674 >> >> has anyone done similar probe calibration experiments? does anyone have >> any clue as to why the difference? >> >> >> Just to confirm my suspicion, I tried to other way around: > > This is an old AMD64 running FreeBSD pinging an Atlas probe on the same > LAN: > $ ping 130.37.15.50 > PING 130.37.15.50 (130.37.15.50): 56 data bytes > 64 bytes from 130.37.15.50: icmp_seq=0 ttl=64 time=2.515 ms > 64 bytes from 130.37.15.50: icmp_seq=1 ttl=64 time=0.913 ms > 64 bytes from 130.37.15.50: icmp_seq=2 ttl=64 time=0.915 ms > 64 bytes from 130.37.15.50: icmp_seq=3 ttl=64 time=0.929 ms > > And this is the same FreeBSD box pinging a Celeron 766 MHz, running a > micro kernel operating system, also on the same LAN: > $ ping prism > PING prism.hq.phicoh.net (130.37.15.36): 56 data bytes > 64 bytes from 130.37.15.36: icmp_seq=0 ttl=96 time=0.364 ms > 64 bytes from 130.37.15.36: icmp_seq=1 ttl=96 time=0.210 ms > 64 bytes from 130.37.15.36: icmp_seq=2 ttl=96 time=0.211 ms > 64 bytes from 130.37.15.36: icmp_seq=3 ttl=96 time=0.214 ms > > This does not involve any of the Atlas software, just the ucLinux kernel > running on the probe. > > My conclusion is: probes are just very slow. > > They are fine for measuring multi millisecond delays on WAN links but not > for sub-millisecond delays on local links. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carsten at schiefner.de Wed Jun 20 10:55:53 2012 From: carsten at schiefner.de (Carsten Schiefner) Date: Wed, 20 Jun 2012 10:55:53 +0200 Subject: [atlas] Changes to RIPE Atlas raw data structures In-Reply-To: <6cd732c9f8214d36aa3363e31391a3a0@kix.es> References: <4FDF189F.6070204@ripe.net> <6cd732c9f8214d36aa3363e31391a3a0@kix.es> Message-ID: <4FE19019.8020507@schiefner.de> Hi Ann, On 18.06.2012 18:36, Rodolfo kix Garcia wrote: >> We don't plan to announce these changes to this list in the future, >> because this list is for a more general audience and this information >> may not be of general interest. Instead, we have created an RSS feed >> for these types of announcements: >> >> https://atlas.ripe.net/atlas/feed/ > > thanks for your information. If you can, please continue sending this > announces to this mail list, because > IMO the mail list has low traffic and this announces are interesting. what Rodolfo said. Best, Carsten From philip.homburg at ripe.net Wed Jun 20 11:29:17 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 20 Jun 2012 11:29:17 +0200 Subject: [atlas] probe resolution, overhead, or ...? In-Reply-To: References: <4FE18E70.30605@ripe.net> Message-ID: <4FE197ED.9030809@ripe.net> On 6/20/12 11:04 , Stelios M. wrote: > > > Ping relies heavily on the system's CPU. That is why it is > considered unreliable for measuring when you are pinging CPU loaded > machines/devices. The CPU on the probe is a n ARM7TDMI running at > 55MHz, based on information from this link: > http://www.digi.com/products/wireless-wired-embedded-solutions/solutions-on-module/digi-connect/digiconnectme#specs > > Probes contain a Lantronix Xport Pro, which has a MC68000 compatible processor. Probes are mostly idle, though some jitter is to be expected from interference between measurements. I have to admit that we never investigated the extent of the jitter problem. From mark at santcroos.net Wed Jun 20 11:43:52 2012 From: mark at santcroos.net (Mark Santcroos) Date: Wed, 20 Jun 2012 11:43:52 +0200 Subject: [atlas] probe resolution, overhead, or ...? In-Reply-To: <4FE197ED.9030809@ripe.net> References: <4FE18E70.30605@ripe.net> <4FE197ED.9030809@ripe.net> Message-ID: On Wed, Jun 20, 2012 at 11:29 AM, Philip Homburg wrote: > I have to admit that we never investigated the extent of the jitter problem. Maybe the RIPE NCC could investigate the idea of creating a worldwide network of high accuracy measurement nodes. Time stamping could happen at (network) hardware level (or alternatively at kernel level) and the time source could be GPS. Oh wait :-) From randy at psg.com Wed Jun 20 13:01:09 2012 From: randy at psg.com (Randy Bush) Date: Wed, 20 Jun 2012 20:01:09 +0900 Subject: [atlas] probe resolution, overhead, or ...? In-Reply-To: <4FE18E70.30605@ripe.net> References: <4FE18E70.30605@ripe.net> Message-ID: > My conclusion is: probes are just very slow. yes, it seems they are a bit slow. now that we know, we can calibrate our experiments to account for that. > They are fine for measuring multi millisecond delays on WAN links but > not for sub-millisecond delays on local links. some experiments care about jitter. we are seeing variance noticeably greater than bsd boxen. @stelios: yes icmp goes the slow path. but atlas has a very constrained measurment model, and it seems to be pretty much based on icmp. randy From philip.homburg at ripe.net Wed Jun 20 13:22:17 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 20 Jun 2012 13:22:17 +0200 Subject: [atlas] probe resolution, overhead, or ...? In-Reply-To: References: <4FE18E70.30605@ripe.net> Message-ID: <4FE1B269.1010306@ripe.net> On 6/20/12 13:01 , Randy Bush wrote: > >> They are fine for measuring multi millisecond delays on WAN links but >> not for sub-millisecond delays on local links. > some experiments care about jitter. we are seeing variance noticeably > greater than bsd boxen. Obviously the current Atlas probes will be worse than just about anything running on older Intel boxes. At the moment we don't have engineering targets for jitter. But it is certainly worth putting on the wish list. That requires some kind of project description, i.e. what kind of variance are you trying to measure and what kind of jitter is the probe allowed to have before the measurement is spoiled. Keeping jitter low conflicts with doing many experiments on a single underpowered probe. So it won't be easy. > > @stelios: yes icmp goes the slow path. but atlas has a very constrained > measurment model, and it seems to be pretty much based on icmp. > > I could be wrong, but as far as I know, routers don't have any kind of 'ping' feature in the fast path. But if you have suggestions for protocols that work better than ICMP ECHO then please let us know. As far as I know, a dedicated (x86) box that just acts as a ping target is best for round trip latency measurements. From randy at psg.com Wed Jun 20 13:32:06 2012 From: randy at psg.com (Randy Bush) Date: Wed, 20 Jun 2012 20:32:06 +0900 Subject: [atlas] probe resolution, overhead, or ...? In-Reply-To: <4FE1B269.1010306@ripe.net> References: <4FE18E70.30605@ripe.net> <4FE1B269.1010306@ripe.net> Message-ID: > As far as I know, a dedicated (x86) box that just acts as a ping > target is best for round trip latency measurements. that is what we are doing, though a collection of targets across a topology. though using the data plane to measure the control plane, one of our often played songs. so changes in rtt are critical. but, like good little nerds, we are trying to calibrate the meters before we use them in a real experiment. don't get me wrong. for something the size of my thumb, the atlas probes are cute. and we hope they will be useful. but knowing the limits and accuracy of one's tools is a critical part of good research. randy