Re: [atlas] Turris Omnia as probe Platform?
What you want from the probe is predictability in the form of minimal jitter and possibly some calibration (to equate latency). IF the Turris people can run the Atlas code with some sort of real-time scheduling then it is going to be OK as a probe. Can they? If it is a process competing with whatever else the router might be doing at the time then I agree, it wouldn’t be suitable as a probe for things that involve precise time measurements, although they could still run the set of measurements for which precise timing is not necessary (routing, DNS, etc). In the Atlas probe all software is under control of one party and *I guess* doesn’t interfere with the rest of the software running on them. The criteria should be reproducibility of the experiment, not whether it is a VM or something else. Just my opinion Joao > On 05 Dec 2015, at 17:27, Gert Doeringwrote: > > > On Fri, Dec 04, 2015 at 11:30:34PM +0100, Daniel Suchy wrote: >> I don't fully agree here. There're always so many things, which may >> involve measurement realiability just on first from the probe. You >> always believe, that "hardware" probe is more reliable. Not, it isn't - >> current probe itself is quite cheap piece of not-so-powerfull hardware. >> And if someone want's to trick measurement, he can - there're so many >> ways. You don't have any kind of control on network behind the probe - >> and that's more important part in terms of reliable measurements... > > The thing is "we perfectly well know the characteristics of the measuring > device". Everything deviating from the norm will be caused by the network, > not "something in the VM environment". > >> Many thing are going virtual around us (even on high-end routing >> platforms). Virtualised probe can be more reliable in terms of computing >> power compared to small TP-Links & so-on. > > Computing power is totally unimportant as compared to reproduceability > of a given measurement on a given probe. > > Of course a VM is more powerful than either of these probes, but does this > make it more suitable to be part of Atlas? I say no, because for a > measurement platform, "raw power" is not the key issue. > > Gert Doering >-- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AGVorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [atlas] Turris Omnia as probe Platform?
Hi! On Sat, Dec 5, 2015 at 6:02 PM, João Damaswrote: What you want from the probe is predictability in the form of minimal jitter and possibly some calibration (to equate latency). IF the Turris people can run the Atlas code with some sort of real-time scheduling then it is going to be OK as a probe. Can they? It depends on what level of control you need. The board will be supported by vanilla Linux kernel (we are almost there). So you/we can compile in whatever is needed. The hardware should be more than enough for routing (=processing input IRQs from NICs and forwarding) and almost everything else can be prioritized. But I suppose we need to discuss that into more detail to address all possible interactions. Is there some documentation of kernel tuning in the current probes? And the probe could perform self-tests periodically and disable itself either temporarily or permanently if the router fails the test. If it is a process competing with whatever else the router might be doing at the time then I agree, it wouldn’t be suitable as a probe for things that involve precise time measurements, although they could still run the set of measurements for which precise timing is not necessary (routing, DNS, etc). In the Atlas probe all software is under control of one party and *I guess* doesn’t interfere with the rest of the software running on them. I personally (though I am the Turris kernel guy) think that we can cooperate on determining interactions and tune the basic system for the probe, if needed. But I suppose that we won't be shipping the routers with the probe turned on by default anyway. From my point of view it would make sense to do more general work in this direction. It boils down to the question whether we can have the probe in form of a daemon? Of course there have to be some requirements for reliable operation, that can be enforced on the OS side and checked on the daemon side. But it does not make sense to think of them if the software probe is still deemed undesirable. Is it? Tomas
Re: [atlas] Turris Omnia as probe Platform?
On Fri, Dec 04, 2015 at 11:30:34PM +0100, Daniel Suchy wrote: > I don't fully agree here. There're always so many things, which may > involve measurement realiability just on first from the probe. You > always believe, that "hardware" probe is more reliable. Not, it isn't - > current probe itself is quite cheap piece of not-so-powerfull hardware. > And if someone want's to trick measurement, he can - there're so many > ways. You don't have any kind of control on network behind the probe - > and that's more important part in terms of reliable measurements... The thing is "we perfectly well know the characteristics of the measuring device". Everything deviating from the norm will be caused by the network, not "something in the VM environment". > Many thing are going virtual around us (even on high-end routing > platforms). Virtualised probe can be more reliable in terms of computing > power compared to small TP-Links & so-on. Computing power is totally unimportant as compared to reproduceability of a given measurement on a given probe. Of course a VM is more powerful than either of these probes, but does this make it more suitable to be part of Atlas? I say no, because for a measurement platform, "raw power" is not the key issue. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 smime.p7s Description: S/MIME cryptographic signature