[Sbs_daq] Big endian raw data?

[Andrew Puckett]

Hi Ole,

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?

Andrew

From: Sbs_daq <sbs_daq-bounces at jlab.org> on behalf of Ole Hansen <ole at jlab.org>
Date: Sunday, October 3, 2021 at 1:00 PM
To: sbs_daq at jlab.org <sbs_daq at jlab.org>
Subject: [Sbs_daq] Big endian raw data?
Hi guys,

Bradley reported a crash of the replay (actually in EVIO) with /adaq1/data1/sbs/grinch_72.evio.0 (see https://logbooks.jlab.org/entry/3916105).

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?

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.

Please explain.

Ole
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/sbs_daq/attachments/20211003/e5f46aa6/attachment.html>