 |
 |
There's one more thing that is strange -- most of the time intervals / windows has duration of 0s -- I suspect something is fishy here, meybe in setting of time-stamps themselves?. A bit more explicit printout (but the same can be seen in the old one, too): TTTT Shukaladunka N=91, from uaf-9.t2.ucsd.edu, seq=36 Window iB=0 iE=12 N=11 delta_t=0.000000 -- start = 2011-08-23 19:10:40 PDT Window iB=12 iE=32 N=19 delta_t=0.000000 -- start = 2011-08-23 19:13:00 PDT Window iB=32 iE=34 N=1 delta_t=0.000000 -- start = 2011-08-23 19:13:05 PDT Window iB=34 iE=53 N=18 delta_t=0.000000 -- start = 2011-08-23 19:15:10 PDT Window iB=53 iE=74 N=20 delta_t=0.000000 -- start = 2011-08-23 19:17:50 PDT Window iB=74 iE=90 N=15 delta_t=0.000000 -- start = 2011-08-23 19:19:30 PDT iB and iE are indices of window "brackets", N is number of inner packets within this window. Cheers, Matevz On 08/23/11 15:35, Matevz Tadel wrote: > Hi, > > I'm looking into details of monitoring traces ... and I suspect that the flush parameter is not doing what the docs say. > > E.g., I have: > xrootd.monitor all auth flush 30s mbuff 1472 window 5s dest files io info user xrootd.t2.ucsd.edu:9930 > and then I get a trace with the following windows: > TTTT Shukaladunka N=91, from uaf-4.t2.ucsd.edu, seq=239 > 0: win 1314136743 1314136743 > 9: win 1314136743 1314136818 > 21: win 1314136818 1314136973 > 40: win 1314136973 1314137233 > 59: win 1314137233 1314137548 > 79: win 1314137548 1314137783 > 90: win 1314137783 1314137783 > > The full message covers timespan of 1314137783 - 1314136743 = 1040s > Shouldn't this be limited to 30s? [I realize this is a bit excessive.] > > The message got sent because the size limit, 1472 bytes, was reached. > > Cheers, > Matevz