Stream Buffering : Buffer X [minutes/blocks] of stream data The stream buffer is an
important part of many of Scream's functions, and it's use and
implications should be well understood. In simple terms, it sets the
amount of memory used to buffer each stream. This buffer is used by
many parts of scream:
When a WaveView window needs to be re-drawn, only the data in
this buffer can be viewed. Similarly, when a status window is opened,
only the buffered status blocks will be displayed in the window.
The Auto-print facility of a WaveView window is, in effect, a re-draw of
the window to a printer device. This means that if you have, for example, an
auto-print set for every 2 hours, and a WaveView window with 2 hours width,
then you need to ensure you have AT LEAST 2 hours of stream buffering in
order for the auto-print to include all the data you want.
The display buffer is used to re-sort out-of-sequence data as it
arrives, and before it is written to file. Out of sequence data can
occur from network outages or from a digitizer in Adaptive mode.
If repeated data is received (e.g. duplicate network packets, or
a repeated replay), the Stream buffer ensures that duplicates are
recognised and discarded. If the data is not already in the stream
buffer, it will be written to file, with the risk of duplicating data
already on file.
The choice of setting for the stream buffer depends on several
parameters. The general rule is that you should select as large a value
as possible, without exceeding the memory limitations of the computer.
There are two different ways of expressing the buffering size: by time
in minutes, or by number of blocks.
minutes: for all streams, whether high sample rates or low, the
amount of history in the display buffer is fixed. Note that the amount
of memory used may vary during operation as the compressibility of the
data changes.
blocks: This offers more precise control over the amount of
memory used, as one block = 1Kb of memory (approximately). Therefore
the user can calculate the maximum buffer size based on memory
available and number of streams being received.
Note also that in block buffering mode, lower samplerate data, or
highly compressed data will have more time history in the buffer than
higher sample rate data. So, for example, you may only get 1 hour of
100sps data, but three days of 1sps data! This is a very good way of
being able to monitor high-frequency real-time data, but also monitor
long-period trends without a large memory requirement.