Timer resolution part 2
In a previous post I looked at the lowest practical resolution using the rdtsc instruction call.
What about more common or garden ways like clock_gettime() or even the humble gettimeofday()?
LibreOffice, OpenOffice conditional formatting
note to self for next time.
I needed to have a cell have a yellow or red background colour based on its contents. I also needed a second cell to go yellow or red, depending on whether the first was yellow or red.
Timing Precision under Linux
When you are after low latency, the first thing to examine are your measurement tools. How precise are the different ways of timing events? What is the maximum resolution you can reach?
On my celeron E3500 desktop I get a maximum resolution of 13118 +/- (3 sigma = 7262) picoseconds. (13+/-7ns).
On a server class system (Westmere X5650) the maximum resolution is 15000 picos, with no variance over the test.
linux syscalls on x86_64
This was going to be a post about the performance overhead of the linux syscall interface. However, things have changed a little since I last was seriously looking at the linux syscall interface while trying to figure out how to map the linux syscall interface to the VAX System Control Block. So this is the collection of notes I've made about how things work in more modern linux kernels.
Back then the intel version of Linux used the 0x80 software interrupt. In fact you can still find this if you look;
arch/x86/vdso/vdso32/int80.S
__kernel_vsyscall:
14.LSTART_vsyscall:
15 int $0x80
16 ret
(All kernel code fragments are from 2.6.39 on the excellent LXR here.)
Jumping ahead a little you can see that this has been buried away in a subdirectory called vdso, which stands for virtual dynamic shared object.
VDSO is one of the more interesting things from a performance and latency point of view. In fact if you look on a recent linux distro like ubuntu 10.04 (RedHat 5.4 is too old to have vdso) you'll see this strange entry in the link table for binaries;
atp@euston:~$ ldd /bin/true
linux-vdso.so.1 => (0x00007fff1afff000)
libc.so.6 => /lib/libc.so.6 (0x00007f5708905000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5708caf000)
Note how there is no file system reference. Thats because linux-vdso.so.1 is actually mapped by the kernel.
Linux Bridges, care and feeding.
The other day we hit an interesting "feature" in the linux bridge implementation.
On one of our KVM hosts, starting or stopping a virtual machine would take the host off the network, by changing its MAC address. Service was restored only by restarting the virtual machine, which would change the MAC back, or by waiting for arp caches to expire and refresh (which takes 2 hours on our firewall).
IP address conflict? No.
It was down to how the linux bridge code picks its MAC address, and how we configure our systems.
