<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:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Dear Joern,</p>
<p><br>
</p>
<p>that could explain it. I'll have a brief look at the documentation later this week.</p>
<p>Thank you for investigating!</p>
<p><br>
</p>
<p>Cheers,</p>
<p>-- Martin<br>
</p>
</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>From:</b> Adamczewski-Musch, Joern Dr.<br>
<b>Sent:</b> Monday, January 20, 2025 9:43:29 AM<br>
<b>To:</b> Bajzek, Martin<br>
<b>Subject:</b> Re: lwrocmerge stream server problem coupled with Go4</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Dear Martin,<br>
<br>
thank you for this request.<br>
<br>
From the error message in the Go4 debug output, it seems that the event <br>
that Go4 receives from your stream or transport server implementation <br>
does not like the event type in the header<br>
<br>
(please see<br>
<a href="https://github.com/gsi-ee/go4/blob/c7bbf7a991e6794637f116ef2b3c26b6446ae1da/Go4EventServer/TGo4MbsSource.cxx#L231">https://github.com/gsi-ee/go4/blob/c7bbf7a991e6794637f116ef2b3c26b6446ae1da/Go4EventServer/TGo4MbsSource.cxx#L231</a>)<br>
<br>
The TGo4MbsSource currently does accept MBS events of types 10 or 4 only.<br>
<br>
This event type is set in the event header field s_ve10_1.i_type (in Go4 <br>
the event header is passed to fxEvent by f_evt_get_event() of the <br>
underlying MBS event api).<br>
<br>
In your case, Go4 finds 0 as i_type value and thus rejects it.<br>
<br>
So either your drasi server does not fill the i_type correctly when <br>
sending the event buffer, or the first data in the received buffer do <br>
not contain an event structure, but something else that Go4 does not <br>
understand, as it always expects it as s_ve10_1.<br>
<br>
Maybe this helps to debug the issue.<br>
<br>
<br>
Cheers,<br>
<br>
Joern<br>
<br>
<br>
<br>
<br>
<br>
On 1/17/25 16:53, Bajzek, Martin wrote:<br>
> Dear Jörn,<br>
> <br>
> <br>
> there's a small issue with Go4 (version 603-00), where if the Go4 <br>
> analysis connects to a client (transport or stream),<br>
> <br>
> spawned from a drasi process, and not MBS, or UCESB/MREV, then the <br>
> following error happens:<br>
> <br>
> <br>
> > GO4-*> Analysis loop is starting...<br>
> > GO4-*> MBS source:: First event = 0 step = 0<br>
> ><br>
> > GO4-d> !!! Mbs Source -- ERROR: Unknown event type 0 !!!<br>
> <br>
> In gdb I see only:<br>
> <br>
> Catchpoint 1 (exception thrown), 0x00007ffff72a90a1 in __cxa_throw () <br>
> from /lib/x86_64-linux-gnu/libstdc++.so.6<br>
> (gdb) bt<br>
> #0 0x00007ffff72a90a1 in __cxa_throw () from <br>
> /lib/x86_64-linux-gnu/libstdc++.so.6<br>
> #1 0x00007ffff7ee4865 in TGo4MbsSource::BuildMbsEvent(TGo4MbsEvent*) () <br>
> from /cvmfs/eel.gsi.de/debian12-x86_64/go4/603-00/lib/libGo4Analysis.so<br>
> #2 0x00007ffff7ee42c7 in TGo4MbsSource::BuildEvent(TGo4EventElement*) <br>
> () from /cvmfs/eel.gsi.de/debian12-x86_64/go4/603-00/lib/libGo4Analysis.so<br>
> <br>
> I'm forwarding Haakan's ideas, maybe you would know why is this a case?<br>
> <br>
> -- Martin<br>
> <br>
> ------------------------------------------------------------------------<br>
> *From:* Håkan T Johansson <f96hajo@chalmers.se><br>
> *Sent:* Friday, January 17, 2025 3:50:48 PM<br>
> *To:* Bajzek, Martin<br>
> *Cc:* Klenze, Philipp; Hubbard, Nicolas James Dr.; <br>
> subexp-daq@lists.chalmers.se<br>
> *Subject:* Re: lwrocmerge stream server problem coupled with Go4<br>
> <br>
> Dear Martin,<br>
> <br>
> Does it work to connect the go4 to a transport server?<br>
> <br>
> (The protocols are very similar, the only on-wire difference is actually<br>
> that a stream server sends back a request to get a new block of data every<br>
> time. but drasi does not care about that, it just sends data anyhow, and<br>
> eats whatever garbage (request) the consumer is sending to it).<br>
> <br>
> Both transport and stream protocols start by sendsing a 16-byte 'info'<br>
> header to the client. This I have abused a bit to send some additional<br>
> information about port mapping. This may actually be only in the stream<br>
> case and not in the transport case, since there the data transmission<br>
> starts without any further request, such that I cannot play that trick.)<br>
> <br>
> It may be that go4 does not like that abuse. However, those port map<br>
> tricks were first done in ucesb, so should be the same. So that is a bit<br>
> of a wonder then...<br>
> <br>
> Other test: can you use a plain go4 ('empty' equivalent) and see if that<br>
> is willing to eat the data from drasi? If not, we have source so can<br>
> debug...<br>
> <br>
> Hmm, the drasi '--server' option has the 'forcemap' option, but that would<br>
> surely not help. One could implement a 'nomap' ('noportmap') option to<br>
> turn these tricks off, if they turn out to be the issue. That then leads<br>
> to the fun with 'port-in-use', but that's another story...<br>
> <br>
> What may then be nicer to use is (if transport protocol works) to just use<br>
> a transport server, but on another port. And tell that --server to be<br>
> 'nohold'. That is then the equivalent of a transport server in that it<br>
> does not hinder the DAQ if it does not keep up.<br>
> <br>
> I'm Cc'ing the subexp-daq@lists.chalmers.se also, as this info may be<br>
> useful for someone else. (And also that this might be a point that could<br>
> use better documentation... A small protocol description...)<br>
> <br>
> Cheers,<br>
> Håkan<br>
> <br>
> <br>
> <br>
> On Fri, 17 Jan 2025, Bajzek, Martin wrote:<br>
> <br>
>> <br>
>> Dear Haakan,<br>
>> <br>
>> <br>
>> there's an issue if a Go4 client connects to a stream server from drasi<br>
>> timeorderer (lwrocmerge executable).<br>
>> <br>
>> The client connects successfully but throws some error (can't debug with<br>
>> -ggdb3, as the build is not ours) on the very first event.<br>
>> <br>
>> Says that something is wrong with the event source.<br>
>> <br>
>> <br>
>> However, if I spawn] a UCESB intermediary:<br>
>> <br>
>> ./empty/empty stream://daq --server=stream<br>
>> <br>
>> <br>
>> Then everything works fine..<br>
>> <br>
>> <br>
>> Could this be that the LMD packets in lwrocmerge stream server are different<br>
>> than in the UCESB empty server?<br>
>> <br>
>> If not, what would be the suspect?<br>
>> <br>
>> <br>
>> Cheers,<br>
>> <br>
>> -- Martin<br>
>> <br>
>> <br>
>><br>
<br>
-- <br>
/////////////////////////////////////////////////////////////////////<br>
// Dr. J"orn Adamczewski-Musch (J.Adamczewski@gsi.de)<br>
// GO4 project team / data processing group Tel: +49-6159-71-1337<br>
// Experiment Electronics department (EEL) FAX: +49-6159-71-2986<br>
////////////////////////////////////////////////////////////////////<br>
// GSI Helmholtzzentrum f"ur Schwerionenforschung GmbH<br>
// Planckstraße 1<br>
// D-64291 Darmstadt, Germany<br>
// www.gsi.de<br>
//<br>
// Commercial Register / Handelsregister:<br>
// Amtsgericht Darmstadt, HRB 1528<br>
// Managing Directors / Gesch"aftsf"uhrung:<br>
// Prof. Dr. Thomas Nilsson<br>
// Dr. Katharina Stummeyer<br>
// J"org Blaurock<br>
// Chairman of the Supervisory Board / Vorsitzender des Aufsichtsrates:<br>
// Ministerialdirigent Dr. Volkmar Dietz<br>
<br>
</div>
</span></font>
</body>
</html>