|
|
|
Back
Midas
Rome
Roody
Rootana
|
| Midas DAQ System |
Not logged in |
 |
|
|
 20 Sep 2006, Stefan Ritt, Suggestion, Increase of maximum event size
|
 20 Sep 2006, Stefan Ritt, Suggestion, Increase of maximum event size
| |
27 Sep 2006, Konstantin Olchanski, Suggestion, Increase of maximum event size
| |
28 Sep 2006, Stefan Ritt, Suggestion, Increase of maximum event size
|
|
|
Message ID: 309
Entry time: 28 Sep 2006
In reply to: 308
|
| Author: |
Stefan Ritt |
| Topic: |
Suggestion |
| Subject: |
Increase of maximum event size |
|
|
| K.O. wrote: | Now, we have per-buffer tunable size (see message
https://ladd00.triumf.ca/elog/Midas/283) and in the long run, I would prefer the
compiled-in limit to go away: already all memory is allocated dynamically and
the MAX_EVENT_SIZE is only useful as kind of a sanity check against frontend
misconfiguration or against malformed events.
If MAX_EVENT_SIZE goes away, the maximum event size becomes limited by the
largest SysV shared memory segment permitted by Linux (via sysctl kernel.shmmax).
To go beyound the limit on SysV shared memories, on can use mmap() based shared
memory: this is limited by available RAM+swap (and disk space for the
.SYSTEM.SHM file). Current MIDAS system.c has an experimental implementation of
mmap() shared memory, but AFAIK it has not been used in any production system, yet. |
MAX_EVENT_SIZE is also used for the RPC layer, since the receiving buffer must hold at
least one event. It is right that this can and should be made dynamically. Concerning
the shared memory there is the problem that it cannot be increased when any program is
running and attached to the shared memory, so it can only be defined at startup of the
first program creating the shared memory.
The sanity check in the frontend is done against max_event_size defined in frontend.c which can be smaller than MAX_EVENT_SIZE (some front-ends have limited memory).
So I agree that this issue may need revision, maybe something for me next visit  |