- went through the current ideas. Last week we thought of a 32-bit seconds count, and a 16-bit subsecond count, 7 bits of which are the 100Hz Linux timer. The remaining bits are a serial number of the message within the same 1/100 of a second.
- Problems with this include: who decides when to timestamp things? Messages may languish in various FIFOs, or it may be a while before they get sent, etc.
- It's probably only really important to count when they are read from or written to the CAN driver; the can_rdr_wtr task can assign this. Everything else, within 1/100 of a second of when they first generated is probably good enough. Things will arrive out of order, we should expect it.
- Bart suggested a 100 Hz resolution real time timer, and a monotonically increasing serial number of some large number of bits, have it in one place and added along with the real time timer.
|32||Seconds since epoch|
|7||1/100 second Linux counter|
|25||FC sequence counter|
- The 32 + 7 bits can be determined from gettimeofday(2).
- The 25 bits need to be retrieved from a single source. I suppose a device driver needs to be written to do this.
--- 08 Jul 2003