<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@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;}
/* Style Definitions */
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;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<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 <sbs_daq-bounces@jlab.org> on behalf of Ole Hansen <ole@jlab.org><br>
<b>Date: </b>Sunday, October 3, 2021 at 1:00 PM<br>
<b>To: </b>sbs_daq@jlab.org <sbs_daq@jlab.org><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">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>
</body>
</html>