<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
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 class="moz-cite-prefix">On 3.10.21 at 13:03, Andrew Puckett
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:BLAPR09MB6881ACE234CCD6962D26967AC3AD9@BLAPR09MB6881.namprd09.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}div.WordSection1
{page:WordSection1;}</style>
<div class="WordSection1">
<p class="MsoNormal">Hi Ole, <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Andrew <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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 class="moz-txt-link-rfc2396E" href="mailto:sbs_daq-bounces@jlab.org"><sbs_daq-bounces@jlab.org></a> on behalf of Ole Hansen
<a class="moz-txt-link-rfc2396E" href="mailto:ole@jlab.org"><ole@jlab.org></a><br>
<b>Date: </b>Sunday, October 3, 2021 at 1:00 PM<br>
<b>To: </b><a class="moz-txt-link-abbreviated" href="mailto:sbs_daq@jlab.org">sbs_daq@jlab.org</a> <a class="moz-txt-link-rfc2396E" href="mailto:sbs_daq@jlab.org"><sbs_daq@jlab.org></a><br>
<b>Subject: </b>[Sbs_daq] Big endian raw data?<o:p></o:p></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"
moz-do-not-send="true">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<o:p></o:p></p>
</div>
</blockquote>
<br>
</body>
</html>