You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I will issue an RPC request and poll for a response before issuing the next one. After each request, I may sleep (or busy waiting) for a while (due to a rate limiter). However, as the waiting time becomes longer, the RPC request latency also increases, which is counterintuitive. Because the longer the wait time, the lighter the load, and the latency should not increase. What could be the root cause of this? And is there a way to fix it? Thanks!
The text was updated successfully, but these errors were encountered:
Hey! Does it happen even if you replace sleep with a busy-polling sleep? sleep usually does a context switch out of the process. If the sleep duration is long and the system is idle, DVFS might kick in and reduce CPU frequency. That might explain higher latency for requests after the sleep.
One possible workaround, as @anujkaliaiitd mentioned above, is using a busy loop instead of a sleep, although being inconvenient. I suspect it's because of some scheduling things but not very sure.
My client is written like this:
I will issue an RPC request and poll for a response before issuing the next one. After each request, I may sleep (or busy waiting) for a while (due to a rate limiter). However, as the waiting time becomes longer, the RPC request latency also increases, which is counterintuitive. Because the longer the wait time, the lighter the load, and the latency should not increase. What could be the root cause of this? And is there a way to fix it? Thanks!
The text was updated successfully, but these errors were encountered: