<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I believe there are byte-swapping routines available in the DAQ libraries which allow to put the bytes in the right state and be consistent. But the DAQ expert needs to make this happen. Below is a snippet of an email from Dave Abbott about a year ago when
I was having some trouble, which I think is relevant.. Dave is a good person to ask. Can ask Bryan Moffit or Alexandre, too.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
---------------------- snippet of email from Dave Abbott ------------------------</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="margin:0px;font-size:12pt;color:black;background-color:rgb(255, 255, 255)">The CODA data files are written from a Java Event Builder. JAVA is inherently Big Endian. The EVIO</span>
<div style="margin:0px;font-size:12pt;color:black;background-color:rgb(255, 255, 255)">
files will be by default in big endian.<br>
</div>
<div style="margin:0px;font-size:12pt;color:black;background-color:rgb(255, 255, 255)">
<br>
</div>
<div style="margin:0px;font-size:12pt;color:black;background-color:rgb(255, 255, 255)">
However, ALL Banks of User data - created in your readout list - will NOT be swapped. They will stay</div>
<div style="margin:0px;font-size:12pt;color:black;background-color:rgb(255, 255, 255)">
whatever Endian it was when it was written.<br>
</div>
<div style="margin:0px;font-size:12pt;color:black;background-color:rgb(255, 255, 255)">
<br>
</div>
<div style="margin:0px;font-size:12pt;color:black;background-color:rgb(255, 255, 255)">
Typically the ROC will run in Linux on Intel which is Little Endian. Therefore the Data banks you create will stay</div>
<div style="margin:0px;font-size:12pt;color:black;background-color:rgb(255, 255, 255)">
little endian. However the Bank headers will be swapped to be compatible with the rest of the CODA file.<br>
</div>
<div style="margin:0px;font-size:12pt;color:black;background-color:rgb(255, 255, 255)">
<br>
</div>
<div style="margin:0px;font-size:12pt;color:black;background-color:rgb(255, 255, 255)">
An even more confusing possibility is that you might do a DMA from the VME bus into a CODA data Bank.</div>
<div style="margin:0px;font-size:12pt;color:black;background-color:rgb(255, 255, 255)">
The VME bus is Big endian. Therefore the data from the VME bus will stay Big endian in this bank.<br>
</div>
<div style="margin:0px;font-size:12pt;color:black;background-color:rgb(255, 255, 255)">
<br>
</div>
<div style="margin:0px;font-size:12pt;color:black;background-color:rgb(255, 255, 255)">
Our general rule for CODA 3 is that for purposes of DAQ we will not touch (or modify) the User's data in any way.</div>
<span style="margin:0px;font-size:12pt;color:black;background-color:rgb(255, 255, 255)">We will only modify the EVIO headers to match the endianess of whatever System writes the file.</span><br>
</div>
<div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="Signature">
<div>
<meta content="text/html; charset=UTF-8">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p style="margin-top: 0px; margin-bottom: 0px;margin-top:0; margin-bottom:0"><br>
</p>
</div>
</div>
</div>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Sbs_daq <sbs_daq-bounces@jlab.org> on behalf of Ole Hansen <ole@jlab.org><br>
<b>Sent:</b> Sunday, October 3, 2021 1:06 PM<br>
<b>To:</b> Andrew Puckett <puckett@jlab.org>; sbs_daq@jlab.org <sbs_daq@jlab.org><br>
<b>Subject:</b> Re: [Sbs_daq] Big endian raw data?</font>
<div> </div>
</div>
<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 class="x_moz-cite-prefix">On 3.10.21 at 13:03, Andrew Puckett wrote:<br>
</div>
<blockquote type="cite">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>
<!--
@font-face
{font-family:"Cambria Math"}
@font-face
{font-family:Calibri}
p.x_MsoNormal, li.x_MsoNormal, div.x_MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif}
a:link, span.x_MsoHyperlink
{color:blue;
text-decoration:underline}
span.x_EmailStyle18
{font-family:"Calibri",sans-serif;
color:windowtext}
.x_MsoChpDefault
{font-size:10.0pt}
div.x_WordSection1
{}
-->
</style>
<div class="x_WordSection1">
<p class="x_MsoNormal">Hi Ole, </p>
<p class="x_MsoNormal"> </p>
<p class="x_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?</p>
<p class="x_MsoNormal"> </p>
<p class="x_MsoNormal">Andrew </p>
<p class="x_MsoNormal"> </p>
<div style="border:none; border-top:solid #B5C4DF
1.0pt; padding:3.0pt 0in 0in 0in">
<p class="x_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="x_moz-txt-link-rfc2396E" href="mailto:sbs_daq-bounces@jlab.org">
<sbs_daq-bounces@jlab.org></a> on behalf of Ole Hansen <a class="x_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="x_moz-txt-link-abbreviated" href="mailto:sbs_daq@jlab.org">sbs_daq@jlab.org</a>
<a class="x_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?</span></p>
</div>
<p class="x_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</p>
</div>
</blockquote>
<br>
</div>
</body>
</html>