Minutes for March 24, 2006

• lnx180c now has 1 GBit ethernet to public side in addition to existing ethernet to CESR
  • /nfs/cesr/instr is a 36GB mount point visible to the outside world
  • 2GB partition is exported to VMS
• Mike: Am fixing pointer problems which are causing segmentation faults in the fitting code
• Hubert:
  • Am writing design documents for the constants library and for the allocation manager
  • Had a meeting with Mark and Eugene on constants (ed. there will be one file per device, starting with the BSM)
• Mark: For the BSM23E, constants will need to be implemented in run code on lnx180c. The hardware for this BSM should be here by the end of next week and testing on the bench should start sometime in the week of April 3. During the bench test we will want to test the ethernet as well.
• Charlie: Have been working on current monitor programming for the BSM
• Tim: Have started to try to talk to the BSM DSP in the DAQlab through the ethernet, but it doesn't work yet.
• Jamie: Will be working on building new C code for the TS101, based on the code that was used in the CBPM system
• Jerry: Have been looking into bunch pushing at feedback, whereby potentially one would kick every bunch (14 ns spacing). Bob has a module that would have the capability to do this.
• Eugene: Have been working on optimizing the new controls code that reads out the FLM accumulator boards
• Discussion on the possibility of having independent access to about 10 global rates in the FLM accumulator:
  • Problem is that reading one rate from the accumulator takes 6 vxgetn's; this makes it slow as there are many more parameters to acquire than these global rates. Also, note that these global rates need to be acquired at high rates.
  • In theory the DSP could read the accumulator board and pass the data on in one block; in practice however, the DSP will be too busy with its main task (calibration monitoring) to garantee a sufficiently high update rate
  • Having an independent access to these global rates, e.g. by using the vector table would solve this problem and would make the controls code much simpler.
  • In the long term, having the ethernet would overcome the drawbacks of the xbus.