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/ripe-atlas@ripe.net/
[atlas] Encouraging people to upgrade software probe versions
- Previous message (by thread): [atlas] Encouraging people to upgrade software probe versions
- Next message (by thread): [atlas] Encouraging people to upgrade software probe versions
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Lukas Tribus
lukas at ltri.eu
Mon Jan 30 18:24:30 CET 2023
On Mon, 30 Jan 2023 at 17:34, Ernst J. Oud <ernstoud at gmail.com> wrote: > > Lukas, > > Keep in mind that - as I experienced - any VM or Docker container introduces > some problems, such as higher latency. My CentOS VM has 2 ms. higher > latency in the first hop compared to a v5 probe on the same fiber. Any virtualization may introduce variables, any WAN circuit, any Firewall and any NAT device. Whether the ATLAS SW probe runs as a "native install" on a virtualized VM managed by you, or whether the ATLAS SW probe runs in a VM managed by RIPE doesn't make a difference in your latency deviation example. We need to stomach 2 ms of deviation if we want to allow SW probes, the alternative is to go HW only. > And a bug in Docker causes traceroute to fail. Docker is probably not the way to go, containers make it more easy to install, but I don't think a container can trigger its own upgrade. > So a hardware or a native install of a software probe is the best way to go. I disagree, unmaintained and unsupported probe installation can never be the way to go. Lukas
- Previous message (by thread): [atlas] Encouraging people to upgrade software probe versions
- Next message (by thread): [atlas] Encouraging people to upgrade software probe versions
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]