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

Added delay before reporting and enforced a minimum interval of 10s #6608

Conversation

Yushmanth-reddy
Copy link

Solves #6570

I tried to set min pingInterval to be 10s and introduced a delay before reporting the nodeLatencyStats.

seeking your guidance in resolving this issue and looking forward to your feedback on the proposed changes

@@ -444,11 +455,17 @@ func (m *NodeLatencyMonitor) monitorLoop(stopCh <-chan struct{}) {
case <-tickerCh:
// Try to send pingAll signal
m.pingAll(ipv4Socket, ipv6Socket)
// Introduce a delay to allow for response processing
time.Sleep(time.Duration(m.reportInterval / 2))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A sleep is blocking and is definitely not the right approach for a select-based loop like this one.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks,removed the sleep block.

Comment on lines 213 to 216
var pingInterval time.Duration
if nlm.Spec.PingIntervalSeconds < MinReportIntervalSeconds {
pingInterval = time.Duration(MinReportIntervalSeconds) * time.Second
} else {
pingInterval = time.Duration(nlm.Spec.PingIntervalSeconds) * time.Second
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please read the original issue carefully. The MinReportIntervalSeconds value should not impact how frequently ICMP probes are sent (we should still honor the value configured through nlm.Spec.PingIntervalSeconds). This change should be about decoupling the "ping" operation and the "reporting" operation. One possible approach would be to have 2 different tickers in the monitorLoop function, and perhaps ensuring there is some jitter (for reporting?) in case the ping period and the reporting period are the same.

@Yushmanth-reddy
Copy link
Author

@antoninbas tried to decouple by adding 2 tickers. But I didn't add jitters as of now.

Copy link
Contributor

@antoninbas antoninbas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unit tests are needed to validate this change

ipv6ProtocolICMPRaw = "ip6:ipv6-icmp"
protocolICMP = 1
protocolICMPv6 = 58
MinReportIntervalSeconds = 10
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is no need to export this constant

also it feels like this could be typed as a duration: const minReportInterval = 10*time.Second

if pingInterval < MinReportIntervalSeconds*time.Second {
m.reportInterval = MinReportIntervalSeconds * time.Second
} else {
m.reportInterval = pingInterval
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe as a "cheap" alternative to jitter, we could set this to m.reportInterval = pingInterval + 1*time.Second instead? This way we could ensure that the 2 tickers don't tick in lockstep.

@antoninbas
Copy link
Contributor

@Yushmanth-reddy any update regarding this PR?

@Yushmanth-reddy
Copy link
Author

Sorry for the delay @antoninbas. I've decided to close this pull request for now. I feel that I need to take some more time to better understand the project. Once I'm confident, I'll revisit and solve issues.
Thank you for your time and feedback during the process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants