The dive sample structure

Tomaz Canabrava tcanabrava at kde.org
Thu Apr 24 12:30:49 PDT 2014


On Thu, Apr 24, 2014 at 4:22 PM, Willem Ferguson <
willemferguson at zoology.up.ac.za> wrote:

> Here is a consensus structure after correcting my miscalculations and
> taking the comments of Linus and Thiago. Without using uint16 or uint8
> integers in some variables, the size of sample would be 64 bytes. By using
> fixed-width variables in some places the size is 48 bytes. I reckon this is
> meant as a compromise proposal that tries to conserve memory space but
> still maintains flexibility. Just to give a thumbsuck of the RAM
> implications of the size of sample: If there is a maniacal commercial diver
> out there who does 1000 dives of 5h (rebreather), the size of his/her dive
> log file could be in the order of 250 Mbytes in RAM (18000 samples/dive at
> a dive computer sampling rate around every 3 seconds for a rebreather,
> resulting in some Tbytes of xml on disk ). Without fixed-length variables,
> RAM utilisation would be towards 350 Mbytes.
>
> Changes to the composition of the sample structure needs to be a
> consultative decision because it is likely to influence many individuals
> coding Subsurface. Please look carefiully at the typedefs and structure. I
> hope there are not any remaining miscalculations.
>
> 1) Should one use the fixed-width integers (uint8 and uint16)?
>
> 2) If so, do the fixed-with fields have enough span for what could be
> encountered in real dives?
>
> As usual, I attach a PDF version of the code snippet.
>
> typedef struct        //unchanged depth_t
> {
>     int mm;
> } depth_t;
>
> typedef struct        // unchanged duration_t
> {
>     int seconds;
> } duration_t;
>
> typedef struct        // unchanged pressure_t
> {
>     int mbar;
> } pressure_t;
>
> typedef struct        // unchanged temperature_t
> {
>     int mkelvin;
> } temperature_t;
>
> typedef struct        // new type definition; type uint16_t
>  shortduration_t
> {
>     uint16_t seconds;
> } shortduration_t;
>
> typedef struct        // new type definition; type uint16_t  o2pressure_t
> {
>     uint16_t mbar;
> } o2pressure_t;
>
> typedef struct        // new type definition; type int16_t bearing_t
> {
>     int16_t degrees;
> } bearing_t;
>
> struct sample {                //TYPE        UNITS RANGE         BYTES
>     duration_t time;           //int        seconds (0-68yrs)       4
>     shortduration_t stoptime;  //uint16_t    seconds (0-18h)         2
>     shortduration_t ndl;      //uint16_t    seconds (0-18h)         2
>     depth_t depth;            //int          mm (0-2000km)      4
>     depth_t stopdepth;        //int          mm (0-2000km)      4
>     temperature_t temperature;//int         mdegrK (0-2MdegrK)     4
>     pressure_t cylinderpressure; //int       mbar (0-2Mbar)      4
>     pressure_t sensor;        //int          mbar (0-2Mbar)      4
>     pressure_t pdiluent;      //int          mbar (0-2Mbar)      4
>     o2pressure_t po2;         //uint16_t     mbar (0-65 bar)     2
>     o2pressure o2sensor[3];   //uint16_t     mbar (0-65 bar)     6
>     o2pressure setpoint       //uint16_t     mbar (0-65 bar)     2
>     bearing_t bearing;        //int16_t     degrees (-32k - 32kdegr)2
>     uint8_t cns;              //uint8_t       % (0-255%)       1
>     unint8_t heartbeat;       //uint8_t     beats/s (0-256)       1
>     bool in_deco;             //bool         y/n --          1
> };
>                                 Total size    47 bytes
>                                 (+1 byte for filling to 48?)
>                                 ( = next word boundary?)
> Kind regards,
> willem
>


If the reason to change the dive structure is to reduce the amount of
memory used, why we don't use lazy loading too?


>
>
>
>
>
>
>
> _______________________________________________
> subsurface mailing list
> subsurface at hohndel.org
> http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20140424/4c2a3ec2/attachment-0001.html>


More information about the subsurface mailing list