 |
 |
Hi Matevz, -----Original Message----- From: Matevz Tadel Sent: Tuesday, June 21, 2011 10:19 PM To: xrootd-l Subject: cmsd report information - docs say servers will report their role as: <stats id="cmss"> - only "cms" gets actually sent. 2. The docs also mention "cmsc" that should describe the client -- what kind of client would that be? I also didn't grep it in the source. ***Thanks for pointing out the "bug". I will correct it. 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. 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). 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. Andy