--------------------------------------------------------------------------
I've been trying to do some homework on the readout issues so that we
have some good numbers to use when we discuss our options. I'm not sure
that we can have an effective video meeting yet- I think we should work
out some things first; RZL, the master of stops is at GS and DM, the
stopper of muons is going back soon.
If the VMV readout (= the accurate term for the "VIC" bus we have set up)
is too slow, then should we go back to local intelligence? I'm working on
some numbers. First, it is possible to Block Transfer (BLT) from the WFD
to Local Intelligence at 10 MB/s. This rate is for dumb readout where
you pass data as fast as possible- no calculations!
One scenario would be as follows: BLT a large portion of the time/disc
section from the wfd to the local computer. Then read through this data
and find the boundary of the time window. Now we know exactly what range
of data to transfer to the remote uVaX. To be safe, the initial transfer
might be 3 times larger than the average 1 ms worth of data. Assuming
3300 bytes/ms of waveform data. The initial transfer of 3 x 3300 / 2
bytes will take 475 us. I wrote a test program and found that the search
through local memory will take 2100 us. Now we know the exact limits of
our data and we can do a dumb transfer to the uVaX at perhaps 1 Mb/sec
(3150 us). Unfortunately, the total time is 3150+2100+475 us, for an
effective transfer rate of .6 Mb/sec. This is not much better than doing
the time calculation as you transfer data (.54 Mb/sec) and I have not
added in overheads. I welcome anyone to check these measurements.
This would be more interesting if we could do a BLT transfer to the uVaX.
Unfortunately, the KAV-30 does not support block transfer. Francesco
made an interesting suggestion: let the wfd crate local computers take
over as VMV masters and BLT into the KAV-30 memory (now a slave). I am
not sure what this speed might be (don't expect 10 Mb/s!). This is a
possibility to consider, but it has significant complexity and would
take some serious study to prove its value. I can't help but note the
irony of putting all the fast computing power in the slave crates
rather than replace the slow KAV30. But that is a VaX vs other issue
that is problematic to address.
If there is the possibility that the master system will be updated,
then it may be worth it for us to purchase VIC-8251 rather than VIC-8250.
These support the full VIC protocol (not the VMV subset) and can do
pipelined transfers. They cost an extra $1K per module; the speedup
would only be realized if the system crate also had VIC8251 and
something more modern than a KAV30. This is my understanding.
In the meantime, we are proceeding with the base system. Ash has been
making tests at Gran Sasso and has modified the readout routines to
use a time-window that starts at t > 0. He used a trigger and fixed
delay to verify that the windowed readout was indeed centered over
the signal data. We are now discussing how to implement this in
a more final version of the readout. This is intimately related to
the output of Rongzhi's Stop Manager; RZL is at GS and is assisting
in this matter.
My revised budget numbers continue to indicate that we will have to
build fewer cards. This would put the horizontal fan-in at 4:1.
I am not aware of any internal study which proves that we need
2:1. Of course it is preferable. Feedback is welcome.
That is all for now.
----------------------------------------------------------------------------