Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NodeLatencyStats API should use metav1.MicroTime instead of metav1.Time for send / receive timestamps #6571

Open
antoninbas opened this issue Jul 29, 2024 · 0 comments
Labels
area/api Issues or PRs related to an API. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.

Comments

@antoninbas
Copy link
Contributor

The API currently uses metav1.Time to represent timestamps:

// The timestamp of the last sent packet.
LastSendTime metav1.Time `json:"lastSendTime,omitempty" protobuf:"bytes,2,opt,name=lastSendTime"`
// The timestamp of the last received packet.
LastRecvTime metav1.Time `json:"lastRecvTime,omitempty" protobuf:"bytes,3,opt,name=lastRecvTime"`

That means that when the timestamps are marshalled, "second-level" precision is used, which reduces the usefulness of the timestamps. In a cluster with low latency, we will typically end up with the same values for LastSendTime and LastRecvTime. These timestamps are not very important in themselves, and the latency data is provided by LastMeasuredRTTNanoseconds. The main reason to have these timestamps is to detect that a peer has stopped responding to probes.

In a future version of the API, we should consider updating the type for these timestamps to metav1.MicroTime, in which case they would be marshalled with "microsecond-level" precision.

@antoninbas antoninbas added area/api Issues or PRs related to an API. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. labels Jul 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api Issues or PRs related to an API. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.
Projects
None yet
Development

No branches or pull requests

1 participant