I've been in the HFT business for a double digit number of years. Prior to that, an SA on many Unix(es), routers, switches, etc. I've built a few things in my career and made some of them go fast. In my experience, 20 mikes flash to bang is very fast. It can be done, but it is far harder than anyone who only has a theoretical knowledge of the subject thinks. We can throw around things like FPGA, RDMA, zero locking, kernel bypass, no alloc, etc. all day long and sound smart. Now, go do it. And when you can't, go learn how. And once you spent years figuring it all out see if you want to sell that skill for a measly buck fifty. And btw, 20 mikes doesn't just take a good programmer. It takes someone with expertise and in-depth understanding of many other things than just writing efficient code. Good luck.
Perhaps you havn't been there - or maybe you are right now. There's a lot of hard IT work in that job that is largely unrewarded. And there is similar pay doing easier IT work or quant modelling / microstructure analysis. My point is that the guy who makes things "fast", does not generally get a piece of the upside. That job has nothing to do with trading, and does not lead to a trading role.
You do not understand the business. Think very carefully about every sentence you wrote. There is a mistake somewhere, that is a big hint. Get back to me when you realize your error.
Yup - would be curious about that detail as well. Are we talking internal latency or round trip latency? Measurements taken where exactly?
Quite irrelevant at that numbers - the ballpark is the same. This is pure HFT "speed race". Do not be smart, be first - if you are there is money to be won. This is where words like "ivy bridge is awesome" are funny. Because it is not about them being good - it is about your box being faster than anyone else who ALSO can order a computer online.
It's only trivial these days because a lot of the libraries abstract away the kernel bypass. Back in the day, I wrote my own drivers to map card memory to user space, isolated the CPU, and burned a core polling card ring buffers. It was non-trivial work in the past, because you were rummaging through kernel code trying to track changes to how things worked with the various PCI boards and various chipsets, grappling with the mechanics of the NAPI poll loop. Subtle shifts in kernel code or new features in new kernels would require updates and maintenance, and you also had the problem of downstream developers not liking your interface. And there was a learning curve too, like figuring out that certain systems calls (if you weren't polling) would lock certain code paths, etc. Now, it's common. I still think people architect these things incorrectly and there's a lot of room for improvement, but I feel as if the reward for doing these types of things correctly is too low. If you move up the stack and start using quantitative methods to both compensate for latency and discover alpha, the pay off is far more than if you gun for every last microsecond. It's questionable whether many traders even appreciate the sort of grueling work that goes into that kind of hackery. ... Just my 2 cents.
Disagree on that part. For at least one of the exchanges in OPs list I am very doubtful that you can achieve round trip latencies as envisaged by OP (unless something has changed exchange side from late last year when we got some ballpark numbers from the exchange tech reps).