<div dir="auto"><div>I think we might be able to choose. <div dir="auto"><br></div><div dir="auto">Though now we use mostly intel CPU unless it breaks any software sounds like little endian would be more efficient. Not sure endianness of VTP, it is an ARM processor is it Big Endian ?</div><div dir="auto"><br></div><div dir="auto">Alexandre</div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 3, 2021, 13:06 Ole Hansen <<a href="mailto:ole@jlab.org">ole@jlab.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
Maybe our various front-ends differ in endianness, so we write
mixed-endian data?!? That would be disastrous since it is not
supported by EVIO. A file can only be one or the other—a very binary
view. (I guess EVIO was written before we became diversity-aware ;)
).<br>
<br>
Ole<br>
<br>
<div>On 3.10.21 at 13:03, Andrew Puckett
wrote:<br>
</div>
<blockquote type="cite">
<div>
<p class="MsoNormal">Hi Ole, <u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">This is interesting. The GRINCH data are
being read out by the new VETROC modules, I don’t know if they
differ from the other modules in terms of “endian-ness”. Maybe
a DAQ expert can weigh in here?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Andrew <u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Sbs_daq
<a href="mailto:sbs_daq-bounces@jlab.org" target="_blank" rel="noreferrer"><sbs_daq-bounces@jlab.org></a> on behalf of Ole Hansen
<a href="mailto:ole@jlab.org" target="_blank" rel="noreferrer"><ole@jlab.org></a><br>
<b>Date: </b>Sunday, October 3, 2021 at 1:00 PM<br>
<b>To: </b><a href="mailto:sbs_daq@jlab.org" target="_blank" rel="noreferrer">sbs_daq@jlab.org</a> <a href="mailto:sbs_daq@jlab.org" target="_blank" rel="noreferrer"><sbs_daq@jlab.org></a><br>
<b>Subject: </b>[Sbs_daq] Big endian raw data?<u></u><u></u></span></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hi guys,<br>
<br>
Bradley reported a crash of the replay (actually in EVIO) with
/adaq1/data1/sbs/grinch_72.evio.0 (see
<a href="https://logbooks.jlab.org/entry/3916105" target="_blank" rel="noreferrer">https://logbooks.jlab.org/entry/3916105</a>).<br>
<br>
When digging into the cause of this crash, I discovered that
these raw data are written in big-endian format. How can this
be? I thought the front-ends are Intel processors. Are we
taking data with ARM chips that are configured for big-endian
mode? Is this a mistake, or is there some plan to it?<br>
<br>
These big-endian data have to be byte-swapped when processing
them on x86, which is what all our compute nodes run. That's a
LOT of work. It leads to significant and seemingly completely
unnecessary overhead. I.e. we're burning CPU cycles for
nothing good, it seems.<br>
<br>
Please explain.<br>
<br>
Ole<u></u><u></u></p>
</div>
</blockquote>
<br>
</div>
_______________________________________________<br>
Sbs_daq mailing list<br>
<a href="mailto:Sbs_daq@jlab.org" target="_blank" rel="noreferrer">Sbs_daq@jlab.org</a><br>
<a href="https://mailman.jlab.org/mailman/listinfo/sbs_daq" rel="noreferrer noreferrer" target="_blank">https://mailman.jlab.org/mailman/listinfo/sbs_daq</a><br>
</blockquote></div></div></div>