Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Measuring Latency in Linux (2014)

btorpey.github.io

Post reply on HN
Print view View original

31–37 of 37 posts

Re: Measuring Latency in Linux (2014)

#31

Post by dirtydroog »

thedance wrote: post #11
cataphract wrote: post #10

I don't think his comment about CLOCK_MONOTONIC_RAW being slow to query applies anymore. It used to be slow because it was not implemented in the vDSO library and so it included the overhead of a syscall. But there was a big vDSO refactoring that landed on 5.3 that I think fixed this problem. Edit: found the patchset. In includes benchmarks for several architectures as well: https://lore.kernel.org/linux-arm-kernel/2…

It's a fun fact that on cloud VMs (AWS, etc) vDSO gettime doesn't exist, so if you rely on vDSO to make time measurement free, it's not.

About a year ago I was writing a personal profiling framework in C++. To test it I profiled how long it took to get the time and if it was scalable (multiple threads making the same call don't interfere) ran it on Windows, and a Linux guest on a Windows host, and an AWS instance. Your post finally explains why the AWS graphs were all over the place!

Re: Measuring Latency in Linux (2014)

#34

Post by ggm »

pepemon wrote: post #32
ggm wrote: post #22

How does VM affect this? How does KVM affect this? How does Docker on KVM affect this? How does Hypervisor affect this? Add "... for a given network driver, e2e, measured RTT.."

How can Docker affect this if it doesn't add any overhead?

Who said it doesn't add any overhead?

Re: Measuring Latency in Linux (2014)

#35

Post by vlovich123 »

coder543 wrote: post #14
vlovich123 wrote: post #8

Earlier quoted context omitted.

How does scheduling a timer to go off at 3pm this Saturday work?

That’s a hard question regardless of programming language. One commonly referenced YouTube video about time that explains why this is hard: https://youtu.be/-5wpm-gesOY A reasonable first approximation of a solution would be to just check every second (or minute, or hour, depending on requirements) whether the current system time is later than the scheduled time for any pending events. Then you probably want to make…

No, you say "sleep until 3pm on saturday" you don't predict anything. The OS computes an exact value to wake up in when you arm. If that clock then jumps forwards or backwards or does anything weird you then recompute the expiry timeout for that timer. You can't do this in app-space but AFAIK all OSes provide a facility for you to do so.

https://developer.apple.com/documentation/dispatch/1420517-d... http://man7.org/linux/man-pages/man2/clock_nanosleep.2.html

Re: Measuring Latency in Linux (2014)

#36

Post by vlovich123 »

krenel wrote: post #9
vlovich123 wrote: post #8

Earlier quoted context omitted.

How does scheduling a timer to go off at 3pm this Saturday work?

Well, the parameter of a Timer is of type Duration: A Duration represents the elapsed time between two instants as an int64 nanosecond count. The representation limits the largest representable duration to approximately 290 years. Which is not really good because we have to calculate the time between now() and Saturday. If "wall time" changes, the scheduler will not be triggered when expected. In that case I would no…

Operating systems spend a lot of time designing APIs for you to deal with time correctly. The approach you've described is a limitation in Go, not inherent in general software development.

http://man7.org/linux/man-pages/man2/clock_nanosleep.2.html https://developer.apple.com/documentation/dispatch/1420517-d...

OS timers when given a wall-clock expiry will do the right thing when the system wall-clock jumps.

Re: Measuring Latency in Linux (2014)

#37

Post by pepemon »

ggm wrote: post #34
pepemon wrote: post #32

Earlier quoted context omitted.

How can Docker affect this if it doesn't add any overhead?

Who said it doesn't add any overhead?

Well, cgroups work like that. No overhead. Your systemd services are sliced under cgroups. Where have you seen the overhead?
Post reply on HN