Open Stack

On 03/24/2014 07:23 PM, Yuriy Taraday wrote:
> On Mon, Mar 24, 2014 at 9:51 PM, Carl Baldwin <carl at ecbaldwin.net
> <mailto:carl at ecbaldwin.net>> wrote:
>
>     Don't discard the first number so quickly.
>
>     For example, say we use a timeout mechanism for the daemon running
>     inside namespaces to avoid using too much memory with a daemon in
>     every namespace.  That means we'll pay the startup cost repeatedly but
>     in a way that amortizes it down.
>
>     Even if it is really a one time cost, then if you collect enough
>     samples then the outlier won't have much affect on the mean anyway.
>
>
> It actually affects all numbers but mean (e.g. deviation is gross).


Carl is right, I thought of it later in the evening, when the timeout
mechanism is in place we must consider the number.

>
>     I'd say keep it in there.

+1 I agree.

>
>     Carl
>
>     On Mon, Mar 24, 2014 at 2:04 AM, Miguel Angel Ajo
>     <majopela at redhat.com <mailto:majopela at redhat.com>> wrote:
>      >
>      >
>      > It's the first call starting the daemon / loading config files, etc?,
>      >
>      > May be that first sample should be discarded from the mean for
>     all processes
>      > (it's an outlier value).
>
>
> I thought about cutting max from counting deviation and/or showing
> second-max value. But I don't think it matters much and there's not much
> people here who're analyzing deviation. It's pretty clear what happens
> with the longest run with this case and I think we can let it be as is.
> It's mean value that matters most here.

Yes, I agree, but as Carl said, having timeouts in place, in a practical
environment, the mean will be shifted too.

Timeouts are needed within namespaces, to avoid excessive memory
consumption. But it could be OK as we'd be cutting out the ip netns
delay.  Or , if we find a simpler "setns" mechanism enough for our
needs, may be we don't need to care about short-timeouts in ip netns
at all...


Best,
Miguel Ángel.


>
> --
>
> Kind regards, Yuriy.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>