Re: [atlas] Turris Omnia as probe Platform?

2015-12-05 Thread João Damas
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 Doering  wrote:
> 
> 
> 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?

2015-12-05 Thread tomas . hlavacek

Hi!

On Sat, Dec 5, 2015 at 6:02 PM, João Damas  wrote:
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?

2015-12-05 Thread Gert Doering

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