From: Frank Geurts (geurts_at_rice.edu)
Date: Fri Mar 07 2003 - 12:47:30 EST
Hi guys,
after the alleged tof problem this night I looked again through the
log files and could still see many, many very late l2 accepts. As you
know, TOF typically time-outs an L0 token if an L2-accept/abort has not
been received w/i 100ms. I think the following piece of the log file
(filtered for TOF only) might give you some better diagnostics.
(from the Thursday March 6)
[tof02 08:34:27] (getdata): WARNING: getdata.cxx [line 927]: time-out
for token 1998, lost a L2 Accept/Abort
[tof02 08:34:29] (getdata): WARNING: getdata.cxx [line 927]: time-out
for token 2080, lost a L2 Accept/Abort
[tof02 08:34:36] (getdata): WARNING: getdata.cxx [line 927]: time-out
for token 2348, lost a L2 Accept/Abort
[tof02 08:34:39] (getdata): WARNING: getdata.cxx [line 927]: time-out
for token 2469, lost a L2 Accept/Abort
[tof02 08:34:39] (getdata): WARNING: getdata.cxx [line 927]: time-out
for token 2468, lost a L2 Accept/Abort
[tof02 08:34:39] (getdata): WARNING: getdata.cxx [line 1539]: L2
Accept with L0 2465, L2 2469, LAMG 1, buffer 64
[tof02 08:34:39] (getdata): WARNING: getdata.cxx [line 1539]: L2
Accept with L0 2465, L2 2468, LAMG 1, buffer 65
and there is much more of that ... like two weeks ago you can clearly
see the L2 accepts coming in more than 100ms after the L0 while in the
mean time more L0s have already entered the system.
Tonko, can you remind me again what you do in STAR daq with those
events, do you keep 'm or kick 'm out?
There is little information in the startrg-hn group except for Hank's
trg nts 030306 ... any news on that?
> L2: Agree to test write changes, then connection to DAQ for BECM towers and then
> test aborts. ZM will finalize command and interface to daq with TL, then
> complete code for testing. ZM will work with JeffL to gresurrect and clarify
> connection to RTS GUI.
cheers,
-frank
This archive was generated by hypermail 2.1.4 : Thu Jul 24 2003 - 00:39:37 EDT