ProblemsWithTextBuffers

List of problems with text buffers

Transfer buffer full

This occurs when the VME crate boots and needs fixing.

• Get dumps of text buffer control structs (presumably the transfer buffer on the master) and see which element isn't reset as it should be on first boot.
• Maybe it's possible for the MDSP to recognise the transfer buffer full state and reset the slave again, or clear it's data structure?

PWP - I have recently (29/06/06) made some changes to the dsp code which may have solved this problem.

• The text buffers were cleared at sdsp boot, but after the first two places at which error messages may have been written to the buffer. Buffer clearance has now been moved before the first point at which a message may be written to the buffer.
• A flag is now set if, whilst writing to a buffer, it overflows.
• The SM used to transfer buffers between sdsp and mdsp no longer throws an error (and hangs) if it attempts to transfer a full or wrapped buffer. Instead it transfers as much text as possible before proceeding as normal, although an error message will still be issued.

Other ideas

• Todo: See if it is possible to remove the double read in RodModule wrt the text buffer handling -- depends on version of RodDaq? being used.
  • I've not managed to find this... [BJG]
  • I couldn't find it either - I'd guess it got lost at some point... [PWP]

• Todo: Streamline the "doTextBuffer" code -- perhaps remove the suspiciously precicely writes ...
• Possible todo, (most of these don't cut out any messages) reduce number of messages sent by DSP by removing
  • redundant debug messages no longer of use
  • "error messages that are not error messages"
  • anything that may be multiplied n-times, eg once per module or once per channel if it is likely to be of little use
    • Prime candidate: [ucid] is using CCODE rather than ASM for histogramming, repeated multiple times
  • otherwise keep as much as possible.

Not sure the following is true:

 * So text buffer readout has now been shown to be a bottleneck for full-crate 
 operation (seen when testing is cosmics run) -- this wasn't the case at 
 Oxford  (at least not frequently) so this is probably due to a combination of
  an increase in the number of messages being sent by the DSPs (Today's DSP 
 code differs from that use in Oxford Macro assembly) and the fact that the 
 text buffer readout method "doTextBuffer" in SctApi/Crate.cxx has become 
 slower recently as it has started to snoop in these buffers for information. 
 ** NB: At an early stage in Oxford the doTextBuffer method wrote every text 
 buffer to MRS as well as writing the log file. This was removed because it 
 was too verbose, not because it was causing stability problems. I don't 
 believe that a simple string comparison is going to make any significant 
 difference to the speed.