 |
 |
Hi Andy, Thanks for the quick reply. I modified a little the configuration so that the flush is done after 30s and the window is 15s to show better the points 1) and 2). I did 4 consecutive xrdcp's. Nothing else was accessing the xrootd dataserver, so there were no interference and no parallel activity. I also attached the logs and binary dumps I obtained from my ML module. Andy Hanushevsky wrote: > The flush rule is approximate. From the attached file I could > potentially read that it was working as well as it wasn't. That's why I > need the binary dump. The reason I need the flush rule is that I would like to do a somewhat real-time analysis and reporting of the system's status. I cannot do this if I get the information about a session only when the buffer fills or when the user disconnects (I would have to keep the history for an undefinite time, update all of it whenever I receive a datagram and have a final result only when the system stops). If I would get this information at least after this flush period, that would be the history that I would have to keep and update. This way I could report all the values with a delay of flush period. > >> 2) "end of last window" == "start of this window" for each two >> consecutive window entries from the i/o trace. You can grep the attached >> file for WINDOW to see this. Is this correct? > > True, if both traces occured in parallel. Since xrootd is a parallel > server, multiple I/O events can occur in the same window but be reported > in separate packets. It's up to the collector to merge the information. From what I understand from the documentation, the events are grouped in windows, and a window is defined by two consecutive window entries. From what I get, it seems that the thisStartTime from the first window entry == lastEndTime from the second window entry, so the window size would be zero. Is this correct, considering that I have only one client running? .. trace events .. Reading Trace Message WINDOW: lastEND: Thu Apr 28 00:05:54 CEST 2005 thisSTART: Thu Apr 28 00:06:09 CEST 2005 .. more events .. WINDOW: lastEND: Thu Apr 28 00:06:09 CEST 2005 thisSTART: Thu Apr 28 00:06:24 CEST 2005 .. other events .. >> 4) I think that the number of bytes actually sent after a READ request >> could be more useful than the number of the requested bytes, in order to >> have a better precision when computing the total number of bytes sent to >> the clients by a xrootd dataserver. > > While this is true, it would seriously impact the server's performance. > In designing the monitoring, we made the concious choce to make > trade-offs to the benefit of the server's performance; even if that > meant reduced accuracy. This is how we can support such extensive > monitoring with only a small degradation in server performance (which in > a real sense provides more realistic information when monitoring is > enabled). However, I see that you keep and sum the exact number of bytes read or written by the client, so you do some operations... Anyway I could live with this :-) the first two points are more important. Cheers, Catalin.