Implement End-to-End Latency Measurement for All IPC Mechanisms

[dustinblack]

The current benchmark suite measures latency by timing the duration of the send() system call. This is not a
true measure of IPC latency; it primarily reflects the time it takes to copy data from the user-space buffer
into the kernel's buffer. This metric is misleading and not comparable to standard IPC benchmarks, which
measure the full transit time of a message.

To provide accurate and comparable results, we must refactor the measurement methodology to calculate the true
end-to-end latency: the total time elapsed from the moment a message is sent by one process to the moment it is
received by another.

Proposed Solution

The latency measurement logic should be re-architected across all IPC mechanisms to follow this sequence:

1. Modify the Message Struct: Add a new field to the Message struct to carry a high-resolution timestamp (e.g.,
   timestamp_ns: u64).

2. Sender-Side Logic (Parent Process):

   • Just before sending a message, the sender will capture a high-resolution timestamp.
   • This timestamp will be embedded into the new timestamp_ns field of the Message struct.
   • The message is then sent as usual.

3. Receiver-Side Logic (Child Process):

   • Immediately upon receiving a message, the receiver will capture its own high-resolution timestamp (t_end).
   • It will then extract the sender's timestamp (t_start) from the message.timestamp_ns field.
   • The true end-to-end latency will be calculated as latency = t_end - t_start.

4. Data Recording:

   • This newly calculated latency value is what will be recorded by the MetricsCollector and written out via
     the streaming output channels (--streaming-output-csv/--streaming-output-json).
   • The old logic of timing the send() call must be removed entirely.

Acceptance Criteria

• The Message struct is updated with a new field to carry a u64 timestamp.
• The sender logic for all IPC mechanisms is updated to populate this timestamp field before every send
  operation.
• The receiver logic for all IPC mechanisms is updated to calculate the end-to-end latency based on the
  received timestamp.
• The MetricsCollector and ResultsManager are updated to record this new, correctly calculated latency
  value.
• The previous latency measurement code, which timed the duration of the send() call, is completely removed.
• The benchmark runs to completion for all mechanisms, producing and recording the new end-to-end latency
  values.

Context

This is a high-priority task (P0) that is essential for the validity of the benchmark suite.

This task is critically dependent on the completion of the multi-process refactoring (Issue
#74). The logic described here must be implemented within the new parent/child process
structure established by that task.