<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:14pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Dear Hans,</p>
<p><br>
</p>
<p>I updated the NURDLIB, but the new flag is not recognized. <br>
</p>
<p><br>
</p>
<p></p>
<div>10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' }<br>
5: config/keyword.c:20: .Invalid keyword "dactl".<br>
5: config/keyword.c:20: .Calling abort()...</div>
<br>
<p></p>
<p>Do I also need to recompile DRASI or R3BFUSER?</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>Best greetings</p>
<p>Günter<br>
</p>
<p><br>
</p>
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag von Hans Toshihide Törnqvist <hans.tornqvist@chalmers.se><br>
<b>Gesendet:</b> Freitag, 19. Januar 2024 16:31:37<br>
<b>An:</b> Discuss use of Nurdlib, TRLO II, drasi and UCESB.<br>
<b>Betreff:</b> Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Dear Günter,<br>
<br>
I have implemented the dactl switch in 'mcal_daq_merge', so in main.cfg:<br>
<br>
GSI_VETAR {<br>
dactl = false<br>
direct = false<br>
}<br>
<br>
I do not know how the names of the Etherbone libraries (e.g. cherry and <br>
enigma) relate to the driver. If the dactl file is not available, we <br>
just have to skip dactl accesses and not allow the direct readout path.<br>
<br>
Have a good weekend you too!<br>
<br>
Best regards,<br>
Hans<br>
<br>
On 2024-01-19 15:22, Weber, Guenter Dr. wrote:<br>
> Dear Hans,<br>
> <br>
> <br>
> with the help of Hċkan, I managed to get the VULOM running. So, we are <br>
> back to starting the DRASI. There we encountered first the fact that in <br>
> main.cfg a BARRIER is now required between the initialization of all <br>
> modules (before there was only a single BARRIER command in the whole <br>
> main.cfg.<br>
> <br>
> <br>
> Now, we are again encounter the VETAR error message. See below:<br>
> <br>
> <br>
> 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: <br>
> 56583).<br>
> Thread has no error buffer yet...<br>
> CPUS: 1<br>
> delay: 1<br>
> 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: <br>
> 56583).<br>
> Thread has no error buffer yet...<br>
> HOST: RIO4-MCAL-1<br>
> Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal]<br>
> 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 <br>
> (eth1).<br>
> 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = <br>
> 0x19000000, 1 consumers.<br>
> 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT)<br>
> 10: lwroc_net_io.c:167: Started server on port 56583 (data port 50126).<br>
> client union size: 244 208 188 508 640 204 204 => 640<br>
> 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: <br>
> /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583<br>
> 10: lwroc_main.c:706: Log message rate limit not in effect.<br>
> 10: lwroc_readout.c:112: call readout_init...<br>
> 10: lwroc_thread_util.c:117: This is the triva control thread!<br>
> 10: lwroc_thread_util.c:117: This is the net io thread!<br>
> 10: lwroc_thread_util.c:117: This is the slow_async thread!<br>
> 10: lwroc_thread_util.c:117: This is the data server thread!<br>
> 10: lwroc_message_internal.c:472: Message client connected!<br>
> 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) <br>
> [192.168.1.1].<br>
> 10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET)<br>
> 10: lwroc_triva_control.c:418: Minimum event time <br>
> ctime(5000)+1*rd(688)+3*wr(634)+fctime(1000)=8590 ns (116.414 kHz)<br>
> 10: lwroc_triva_state.c:1486: (Re)send ident messages...<br>
> 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1<br>
> 9: lwroc_triva_control.c:507: TEST: GO<br>
> 10: lwroc_triva_control.c:725: RUN: RESET<br>
> 10: lwroc_triva_control.c:729: RUN: MT=14<br>
> 9: lwroc_triva_control.c:737: GO (1 good test triggers done) (max <br>
> 116.4 kHz)<br>
> 10: lwroc_triva_readout.c:376: Trigger 14 seen.<br>
> 10: config/config.c:181: Will try default cfg <br>
> path='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default', can be set with NURDLIB_DEF_PATH.<br>
> 10: config/parser.c:287: Opened <br>
> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' {<br>
> 10: config/parser.c:299: Closed <br>
> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' }<br>
> 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 <br>
> (IN_READOUT). EC: 1<br>
> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0.<br>
> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting...<br>
> 10: config/parser.c:287: Opened './main.cfg' {<br>
> 10: config/config.c:1299: .Global log level=verbose.<br>
> 10: config/parser.c:287: .Opened <br>
> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' {<br>
> 10: config/parser.c:299: .Closed <br>
> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' }<br>
> 10: config/parser.c:287: .Opened <br>
> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' {<br>
> 10: config/parser.c:299: .Closed <br>
> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' }<br>
> 10: config/parser.c:287: .Opened <br>
> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' {<br>
> 10: config/parser.c:299: .Closed <br>
> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' }<br>
> 10: config/parser.c:287: .Opened <br>
> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vetar.cfg' {<br>
> 10: config/parser.c:299: .Closed <br>
> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vetar.cfg' }<br>
> 10: config/parser.c:287: .Opened <br>
> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' {<br>
> 10: config/parser.c:299: .Closed <br>
> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' }<br>
> 10: config/parser.c:287: .Opened <br>
> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' {<br>
> 10: config/parser.c:299: .Closed <br>
> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' }<br>
> 10: config/parser.c:287: .Opened <br>
> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' {<br>
> 10: config/parser.c:299: .Closed <br>
> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' }<br>
> 10: config/parser.c:287: .Opened <br>
> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' {<br>
> 10: config/parser.c:299: .Closed <br>
> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' }<br>
> 10: config/parser.c:287: .Opened <br>
> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' {<br>
> 10: config/parser.c:299: .Closed <br>
> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' }<br>
> 10: config/parser.c:299: Closed './main.cfg' }<br>
> 10: crate/crate.c:347: crate_create {<br>
> 10: crate/crate.c:673: crate_create(MCAL) }<br>
> 10: crate/crate.c:899: crate_init(MCAL) {<br>
> 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM.<br>
> LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC)<br>
> 10: crate/crate.c:923: .Slow-init module[1]=GSI_VETAR.<br>
> 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Gsi Etherbone <br>
> /sys/class/vetar/vetar0/dactl: Failed dactl fopen: No such file or <br>
> directory.<br>
> 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Calling abort()...<br>
> <br>
> We are sure that the right NURDLIB path is used and also DRASI is <br>
> started in the correct folder.<br>
> <br>
> <br>
> What we found in the enironment variables are two lines, where 'white <br>
> rabbit' is mentioned. As I understand, this is connected to the VETAR2 <br>
> module.<br>
> <br>
> <br>
> LD_LIBRARY_PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/lib:/mbsusr/mbsdaq/mbsrun/whiterabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib<br>
> PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/bin:/bin:/bin/ces:/usr/bin:/mbsusr/mbsdaq/bin:/usr/local/bin:/usr/bin/X11:/etc:/usr/etc:.:/mbsusr/mbsdaq/tools<br>
> <br>
> Maybe, it is necessary to update something there?<br>
> <br>
> <br>
> Anyway, if you have now a switch in NURDLIB to deal with old software <br>
> for the VETAR, then we should proceed with removing NURDLIB and getting <br>
> the newer version, right?<br>
> <br>
> <br>
> <br>
> <br>
> Many thanks and have a nice weekend!<br>
> <br>
> <br>
> <br>
> <br>
> Best greetings<br>
> <br>
> Günter<br>
> <br>
> <br>
> <br>
> <br>
> ------------------------------------------------------------------------<br>
> *Von:* subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag von <br>
> Hans Toshihide Törnqvist <hans.tornqvist@chalmers.se><br>
> *Gesendet:* Donnerstag, 18. Januar 2024 13:28:36<br>
> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr.<br>
> *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, <br>
> TRLOII, DRASI, etc. were updated<br>
> Dear Günter,<br>
> <br>
> It looks like either the Vetar driver failed, or the fw/driver is old<br>
> and nurdlib expects a file that didn't exist a while back. If it's the<br>
> latter I can add a switch to ignore this file, it's not critical for<br>
> readout and is used to enter a faster readout mode.<br>
> <br>
> Which version of nurdlib is this? The files and line numbers don't match<br>
> with what I see in the source code, and the last time gsi_etherbone.c<br>
> changed was early last year.<br>
> <br>
> The message "Could not open so-and-so" should be for the device, e.g.<br>
> /dev/pcie_wb0. This is used for the readout.<br>
> <br>
> The dactl file should fail with "Failed dactl fopen".<br>
> <br>
> To summarise, I would suggest to make sure that the correct nurdlib and<br>
> r3bfuser are executed by the DAQ scripts. Meanwhile I will prepare a<br>
> switch to ignore the dactl file which could anyhow be useful for old<br>
> configurations, and to clean up the Etherbone error messages.<br>
> <br>
> Best regards,<br>
> Hans<br>
> <br>
> On 2024-01-18 11:29, Weber, Guenter Dr. wrote:<br>
>> Dear friends,<br>
>> <br>
>> <br>
>> I now started the DAQ and it looks like there is a problem with the <br>
>> VETAR2 module. Attached please find the output once the DAQ is started <br>
>> on the RIO4.<br>
>> <br>
>> <br>
>> Here ist the error message:<br>
>> <br>
>> <br>
>> 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866)<br>
>> 11: a:1: .Gsi Etherbone init_slow { <br>
>> (module/gsi_etherbone/gsi_etherbone.c:110)<br>
>> 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No <br>
>> such file or directory.<br>
>> (module/gsi_etherbone/gsi_etherbone.c:120)<br>
>> 5: a:1: ..Calling exit(EXIT_FAILURE)... <br>
>> (module/gsi_etherbone/gsi_etherbone.c:120)<br>
>> <br>
>> How to proceed?<br>
>> <br>
>> <br>
>> <br>
>> Many thanks and best greetings<br>
>> Günter<br>
>> <br>
>> <br>
>> <br>
>> <br>
>> ------------------------------------------------------------------------<br>
>> *Von:* subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag von <br>
>> Hċkan T Johansson <f96hajo@chalmers.se><br>
>> *Gesendet:* Dienstag, 16. Januar 2024 19:20:54<br>
>> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.<br>
>> *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, <br>
>> TRLOII, DRASI, etc. were updated<br>
>> <br>
>> On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote:<br>
>> <br>
>>> <br>
>>> Dear friends,<br>
>>> <br>
>>> <br>
>>> I am just trying to figure out how all the various scripts/commands work<br>
>>> together for setting up our DAQ system. Maybe, you can help to clearify some<br>
>>> things.<br>
>>> <br>
>>> <br>
>>> <br>
>>> - master.bash<br>
>> <br>
>> This would be intended to run on the readout board (RIO). The other<br>
>> scripts below is for the PC.<br>
>> <br>
>>> <br>
>>> source ../env/env.sh<br>
>>> ./trloii_setup.sh<br>
>>> # gdb --args \<br>
>>> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \<br>
>>> --label=MCAL1 \<br>
>>> --triva=master,fctime=10,ctime=50 \<br>
>>> --log-no-rate-limit \<br>
>>> --server=drasi,dest=lyserv \<br>
>>> --buf=size=400Mi \<br>
>>> --max-ev-size=0x1000000 \<br>
>>> --subev=crate=1,type=20,subtype=2,control=9,procid=1 \<br>
>>> --eb=lyserv \<br>
>>> "$@"<br>
>>> <br>
>>> In the first line some environment variables are set. The second line tells<br>
>>> the VULOM4 how to operate (i. e. selection from modes of operation defined<br>
>>> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is there<br>
>>> somewhere an explanation of the purpose of all these settings?<br>
>> <br>
>> The drasi command line options should be described here:<br>
>> <br>
>> <a href="http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html">http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html</a>
<br>
> <<a href="http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html">http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html</a>><br>
>> <<a href=""></a>http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html <br>
> <<a href="http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html">http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html</a>>><br>
>> <br>
>> (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.)<br>
>> <br>
>> The TRLO II setup file (vulom.trlo) is worse in terms of documentation.<br>
>> The format as such is hopefully rather straightforward. A description is<br>
>> here: <a href="http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html">http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html</a>
<br>
> <<a href="http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html">http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html</a>><br>
>> <<a href=""></a>http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html <br>
> <<a href="http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html">http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html</a>>> .<br>
>> The actual meaning is more complex, the TRLO II description can be found<br>
>> here:<br>
>> <br>
>> <a href="http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html">
http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html</a> <br>
> <<a href="http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html">http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html</a>><br>
>> <<a href=""></a>http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html
<br>
> <<a href="http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html">http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html</a>>><br>
>> <br>
>> (left pane), which just is a colourised version of this:<br>
>> <a href="http://fy.chalmers.se/~f96hajo/trloii/description.txt">http://fy.chalmers.se/~f96hajo/trloii/description.txt</a>
<br>
> <<a href="http://fy.chalmers.se/~f96hajo/trloii/description.txt">http://fy.chalmers.se/~f96hajo/trloii/description.txt</a>><br>
>> <<a href=""></a>http://fy.chalmers.se/~f96hajo/trloii/description.txt <br>
> <<a href="http://fy.chalmers.se/~f96hajo/trloii/description.txt">http://fy.chalmers.se/~f96hajo/trloii/description.txt</a>>><br>
>> <br>
>> It does not describe the .trlo file as such, but what the gateware tries<br>
>> to achieve.<br>
>> <br>
>>> And what is in the last line? I never came accross "$@" before.<br>
>> <br>
>> That would be all the (non-shifted, i.e. not removed) options given to the<br>
>> script itself, i.e. master.bash.<br>
>> <br>
>>> - eb.bash<br>
>>> <br>
>>> ../drasi/bin/lwrocmerge \<br>
>>> <br>
>>> --label=MCAL_EB \<br>
>>> --merge-mode=event \<br>
>>> --server=trans,flush=1 \<br>
>>> --server=stream,flush=1 \<br>
>>> --buf=size=1600Mi \<br>
>>> --max-ev-size=20Mi \<br>
>>> --eb-master=rio4-mcal-1 \<br>
>>> --file-writer \<br>
>>> --drasi=rio4-mcal-1<br>
>>> <br>
>>> What is the purpose of this command?<br>
>> <br>
>> This runs an 'event builder' on the PC. Not strictly needed, but this<br>
>> way, the RIO only ever needs to send data once, to this event-builder<br>
>> (EB). File writing, and streaming of on-line data is then handled by this<br>
>> process. It is cheaper to have better network cards and so on in a plain<br>
>> PC.<br>
>> <br>
>>> Why are values for buffer size and max<br>
>>> event size different then in the command before?<br>
>> <br>
>> The nomenclaturure is unfortunately a bit convoluted below with ucesb<br>
>> regards 'buffer size'. The --buf in the two commands above give the size<br>
>> of the memory used to buffer data inside the process, and depends on how<br>
>> much memory each machine has. The --max-ev-size tells how large each .lmd<br>
>> event can be. The --max-ev-size configured in the event builder needs to<br>
>> be as large as the sum of all event sources it has. I.e. should be able<br>
>> to be the same as in your single source above.<br>
>> <br>
>> In the readout itself, any event that is read out cannot be larger than<br>
>> this. If it is, then the DAQ will report a fatal failure.<br>
>> <br>
>>> - fanout.bash<br>
>>> <br>
>>> #!/bin/bash<br>
>>> while :<br>
>>> do<br>
>>> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \<br>
>>> stream://localhost \<br>
>>> --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001<br>
>>> sleep 5<br>
>>> done <br>
>>> <br>
>>> This looks like setting up a connection point to the outside world, right?<br>
>> <br>
>> Yes. It accepts connections and will serve them data for online analysis.<br>
>> <br>
>> stream://localhost tells it where to read data (here the PC itself where<br>
>> it is running). Using the 'stream' protocol, which esentially is just raw<br>
>> LMD events. (As is the 'transport protocol'.) That will be served on the<br>
>> default port used for the stream server set up by the EB above.<br>
>> <br>
>> --server is then the server that accepts connections, and serves data on<br>
>> another port (8001).<br>
>> <br>
>>> And we find the third (random?) value for a buffer size.<br>
>> <br>
>> That bufsize is actually the LMD buffer size used by the stream server.<br>
>> The corresponding value in the readout and EB is set implicitly from the<br>
>> maximum event size...<br>
>> <br>
>>> - rate.bash<br>
>>> <br>
>>> ../drasi/bin/lwrocmon --rate rio4-mcal-1<br>
>>> <br>
>>> Ok, this I understand. We can look the DAQ over the shoulder and see what<br>
>>> the thing is doing in terms of number of trigger events, transported data,<br>
>>> etc.<br>
>> <br>
>>> - log.bash<br>
>>> <br>
>>> ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost<br>
>>> <br>
>>> This is also easy to understand.<br>
>> <br>
>> :-)<br>
>> <br>
>> Then also try to do (on the PC)<br>
>> <br>
>> drasi/bin/lwrocmon --tree rio4-mcal-1 localhost<br>
>> <br>
>> which would show a 'tree-view' monitoring of the running system.<br>
>> <br>
>> <br>
>> Cheers,<br>
>> Hċkan<br>
>> <br>
> -- <br>
> subexp-daq mailing list<br>
> subexp-daq@lists.chalmers.se<br>
> <a href="https://lists.chalmers.se/mailman/listinfo/subexp-daq">https://lists.chalmers.se/mailman/listinfo/subexp-daq</a>
<br>
> <<a href="https://lists.chalmers.se/mailman/listinfo/subexp-daq">https://lists.chalmers.se/mailman/listinfo/subexp-daq</a>><br>
> <br>
-- <br>
subexp-daq mailing list<br>
subexp-daq@lists.chalmers.se<br>
<a href="https://lists.chalmers.se/mailman/listinfo/subexp-daq">https://lists.chalmers.se/mailman/listinfo/subexp-daq</a><br>
</div>
</span></font>
</body>
</html>