atp

I recently wanted to use flowtype.js with wordpress to create a liquid layout for the text as well as the images. Integrating it required a bit of research into how to load javascript into wordpress the 'correct' way. Here's how it fits together.

While investigating a different issue, I found myself looking again at accurate timing with the rdtsc instruction
to read the processor's Time Stamp Counters. I last blogged about this when looking at the jitter caused by system calls to the linux kernel, and things have changed quite a lot. This post is the result of my trip around this particular block again.

So, going back and fixing up auth on our few remaining older systems (centos 5, not internet facing) came across the error below. Solution was beautifully non obvious, so it goes here in the external memory pack.

yum --enablerepo=my-repo-x86_64  list updates
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: a.centos.mirror
 * epel: another.centos.mirror
 * extras: and.a.further.centos.mirror
 * updates: centos-updates.co.uk
my-repo-x86_64                                                                                                                                                       | 2.9 kB     00:00     
my-repo-x86_64/primary_db                                                                                                                                            | 7.1 kB     00:00     
http://myreposerver.internal.domain/my-repo/repodata/7d1016c9fcac64ee6c0fe9b5b\
 58ed1e791dae601b1b0be13ea8af523761fbabd-primary.sqlite.bz2: [Errno -3] \
 Error performing checksum
Trying other mirror.
my-repo-x86_64/primary_db                                                                                                                                            | 7.1 kB     00:00     
Error: failure: repodata/7d1016c9fcac64ee6c0fe9b5b58ed1e791dae601b1b0be13ea8af5\
  23761fbabd-primary.sqlite.bz2 from my-repo-x86_64: [Errno 256] \
  No more mirrors to try.

Do not pass go. Do not collect your new sssd binaries.

This caused me to waste 1/2 an hour or so this morning. It also needed some quite precise google-fu to uncover the solution. I'm bound to forget this and am likely to need it again so it's going here. I'm not sure how most of the zillions of "upload multiple files with php" tutorials out there work, because none of them seem to mention this.

I was doing multiple file uploads in php, and finding that although you submit multiple files with a multipart/form-data encoding type (and can see multiple files being submitted in chrome devtools), php was only reporting the last one in the list of uploaded files in $_FILES. Very annoying.

We were tracing a problem with occasional latency spikes on one of our systems the other day. The cause was rather unusual.

The write load was not high, being a few megabytes per second at peak on an otherwise completely idle disk. We checked for the usual hardware issues; cache batteries, failing disks as well as other programs writing to that disk, but came up empty.  Fairly regularly we saw a write latency of up to 40ms. Occasionally we'd see more spikes at an increased frequency of occurrence. We discovered that sometimes the latency spikes clustered - so it looked like there was bimodal behaviour.

Our investigation showed we were waiting on writes to the page_cache whilst allocating buffer_head structures. Here's what we found out.

In 2011 I put out an example php class that could be used to talk to the LMAX API protocol. It was incomplete and for illustrative purposes only. It remains that way. Over the years however there have been some improvements and it can now be used for placing, closing and cancelling orders. I've made the latest version available on github, just in case the handful of people who have contacted me over the years about it find it useful to have the latest version. 

Here is the lmax-php-api github repo. As well as the original ticker app, there's a small example web app that shows how to get and handle position state events, as well as the example that forms the rest of the post. 

Its not under active development. Its not supported, and should not be used for real trading - its purely an educational tool. However if you send me a patch I'll probably add it in.

I took the time to start using Mike's HDR histogram port to C the other day. It was pretty painless to use, once I'd overcome a couple of initial problems. One of which is that the C compiler I have on CentOS 6.4 was too old. So I came up with a workaround for older compilers/machines. 

HDRHistogram is Azul's high dynamic range histogram. The readme on github explains what it is. Suffice it to say that I'm in the process of dumping the various implementations of histogram code I've evolved over the years in favour of this for latency and performance management.

Some of these are hard to google for and I've used more than once now, so to save time I'm bookmarking them here.

1. Setting watch points in gdb
2. Displaying the whole string in gdb
3. Setting gdb to break at a particular file/line
4. Setting the coredump limit of a running process to catch a core

None of this is rocket science, but still useful.