Hi Andy,

Thanks for your answers.

On 06/22/11 15:35, Andrew Hanushevsky wrote:
> 3. The 'r' contributions from all servers connected to this manager (all read-only,
> so no write ops) sum up to '4058'. So, what is really the meaning of 'sel.t' and
> 'sel.r' then?
> 
> With time, both 'sel.r' and 'sel.t' grow, but the difference changes (in my case
> it got smaller which seems strange).
> ***The deviation between (r+w) vs t is noted in the manual. 't' represents all
> selections, whether they yield a result or not.  The 'r' and 'w' represent only
> those selections that actually yielded a result. So, one should expect that the
> divergence would get smaller over time.

Sorry, where in what manual? I sense I'm missing something important about cmsd
here :)

> What happens if a server disconnects and then re-connects? Will there be a
> discontinuity of some kind in those numbers? Or will the manager cmsd just keep
> the host identification and reuse it when the server comes back up?
> ***The answer is yes but only if the server reconnects within its "drop" window
> (by default, 10 minutes).

OK, makes sense, I was just restarting some servers and numbers kept growing.

> 4. After writing all this ... is anybody actually using this? What would be a
> reasonable thing to store into MonALISA (or equivalent)? Is cmsd ever the
> bottleneck / problematic part?
> ***No one but you at the moment because these values were not available nor
> documented until just recently. In general, the cmsd has never been an issue
> since it has such low over head. But, one person's "no issue" is another
> person's view of neglect. I suspect that the only thing you would want is the
> number of times a host is selected for redirection. I think that Brian would be
> interested in how well server redirection shares are actually met.

Yup, that was why I started looking into this ... but, if I understand
correctly, this only works for meta-managers and Brian is in control of the only
one we have.

Cheers,
Matevz