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/mat-wg@ripe.net/
[mat-wg] RIPE Atlas / UDM as a replacement for TTM
- Previous message (by thread): [mat-wg] RIPE Atlas / UDM as a replacement for TTM
- Next message (by thread): [mat-wg] RIPE Atlas / UDM as a replacement for TTM
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Philip Homburg
pch-ripeml-1a at u-1.phicoh.com
Mon Jun 18 16:23:19 CEST 2012
In your letter dated Mon, 18 Jun 2012 15:53:26 +0200 you wrote: >I've been told that UDMs in Atlas "can do what I need" (use RIPE >measurements to prove to our customers that our Internet reachability >is good). It might, but I find it surprising painful, as I can only >request pings from "10 probes at a time" in the UDM - and for reasonable >accuracy, we'd need something of at least the size of TTM (100+ probes), >or *better*, as we know that individual Atlas probes are not expected >to have the same network stability as a TTM box ("always up. ALWAYS!") - >setting up 30 or more individual UDMs to get 150 clients each to ping our >two TTM boxes is... not the way to go. These limits are supposed to be there temporary. They are there mainly to avoid a rush from probe hosts with losts of credits to overload the system. Ultimately, the idea is that should be able to spend the credits you have. If you want your limits raised, just ask. >Second, I'm a bit confused how to automatedly download the .json-format >UDM results - while I'm logged in, clicking on the link gives me a nice >.json download, but when using the same link with wget, I get a login >page. I'm not overly willing to download 30 UDM result files manually >every day - so there must be some way to use "wget" etc. to get these >data files... any hints on that? > >Example link: https://udm01.atlas.ripe.net/atlas/udm_download.json?attach=1&ms >m_id=1002000&y=2012&w=25 There is an example at the bottom of <https://atlas.ripe.net/doc/api> that explains how to go past ripe-access in python. >Third, we still need reasonable ping targets in our network, that >are sort of "not under our control" (to meet the goal of "the RIPE NCC >does these measurements, they are neutral, so we're not faking anything >here") It is not clear to me how a ping target in your network can fake anything. A probe in your network is a different story, but a target? Probes just report how quickly and reliably they can access the target. If have no idea how you could fake that by controlling the target. >- and that are not part of the normal network churn that >www.space.net or one of our routers might have. So far we use the TTM >boxes for that - but they might die of old age some day... Which brings >back the topic of the Atlas Anchor boxes... any news on that? I leave it to somebody else to comment on the anchor boxes. They will come, but when and where, I have no idea.
- Previous message (by thread): [mat-wg] RIPE Atlas / UDM as a replacement for TTM
- Next message (by thread): [mat-wg] RIPE Atlas / UDM as a replacement for TTM
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ mat-wg Archives ]