 |
 |
Hi Catlin, Found the source of the zero packet length problem It has to do with type casts and the order in which you put things in network byte order. The fix will be in the next test release. If you want a patch ahead of time, I can give you one. Let me know. Thanks for bringing the problem to our attention. Andy ----- Original Message ----- From: "Catalin Cirstoiu" <[log in to unmask]> To: "Andy Hanushevsky" <[log in to unmask]> Cc: <[log in to unmask]>; "Jacek Becla" <[log in to unmask]> Sent: Wednesday, April 27, 2005 3:52 PM Subject: Re: xrootd monitoring > 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. >