banburybill
commented
4 years ago To really do this properly, we need to record two times, the recording start time and the recording end time. These need to be in the C-DNS at the per-block level, otherwise we break the ability to 'merge' C-DNS files.
In practice, in a situation with a continuously running compactor, just recording the time the block was closed - which compactor means the timestamp of the data that provoked compactor into deciding to start a new block or file - gives us the block end time. Apart from the start of recording, during continuous recording the start point of a new block will be that first piece of data, and so we will have an accurate measure of the time period covered by a block - it will be the earliest timestamp in the block to the block end time. Similarly, only the last block recorded (when compactor was interrupted) would lack an end time.
Better, though, would be also to record the start time (perhaps only if different to the earliest time). This would be wall clock time when compactor started running. A final end time could also be recorded, being the wall clock time when compactor was halted.
It would be useful to be able to calculate the average rate of packet reception from the information in .info. However, we can't do that without knowing the length of time the file was capturing for. We can't simply look at the first and last records; the first may have the time the file was opened (have to check that), but the last does not tell you when the file was closed, only when the last packet was received. A very different thing.