[Greg McKaskle]

The log file is not written out in the high priority timed loop. I try to keep that loop lean. It is done where we receive the status packets. What is logged is mostly the status info anyway. I have characterized the control packet loop with high CPU, but not the status or logging loop. The statistics on packet loss and latency are going to lag a bit just because of how they are measured and reported. The events tend to be even more lagged because they are often timeouts. But I have never seen a file where I thought the CPU usage messed up the data. If the DS doesn't have data for a time period, it replicates the new packet to fill in the void. So I would suspect that high packet loss would have flat spots for everything else and high bars for the packets.

The new format has version 1 and the trace bits are shifted down. Earlier in this thread, it shows a simple diagram that indexes the bits from the i8. It throws away the first two bits. We thought we were going to add more info and I modified code to prep. The result of that was that the bits are now packed starting at bit 0.

The dsevents file has the same header and then each event/warning is a timestamp and a LVString. The LVString is not NULL terminated, but is an i32 count of bytes followed by the bytes. The strings are possibly encoded a bit with <> tags, depending on who is sending the data to the DS.

Greg McKaskle