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
|