HFT [High Frequency Trading] Breaks Speed-of-Light Barrier, Sets Trading Speed World Record.
Adds a new unit of time measurement to the lexicon: fantasecond.

On September 15, 2011, beginning at 12:48:54.600, there was a time warp in the trading of Yahoo! (YHOO) stock. HFT has reached speeds faster than the speed-of-light, allowing time travel into the future. Up to 190 milliseconds into the future, or 0.19 fantaseconds is the record so far. It all happened in just over one second of trading, the evidence buried under an avalanche of about 19,000 quotes and 3,000 individual trade executions. The facts of the matter are indisputable. Based on official UQDF/UTDF exchange timestamps, there is unmistakable proof that YHOO trades were executed on quotes that didn’t exist until 190 milliseconds later!

Millions of traders depend on the accuracy of exchange timestamps — especially after bad timestamps were found to be a key factor in the disastrous market crash known as the flash crash of May 2010. …

The lowly time-stamp. Not rocket science. Not crucial like price, right? What’s to get wrong? An exchange with unlimited resources couldn’t mess up like that, could it? (Assuming the analysis is correct.)

As a software builder, I wonder how did it happen?

It probably wasn’t buggy code: unit tests are good, but more of them probably won’t catch this one.

Was it sheer load? It wasn’t the highest overall traffic they experienced:

The chart below shows quote message rates for UQDF and multicast line #6 which is the line that carries YHOO quotes. … Although traffic from YHOO was a significant percentage of all traffic on UQDF, it was not high enough to indicate any problems. Note the much higher surge on the right side of the chart; there weren’t any known problems at that time in YHOO.

So the system would pass a generic stress test. Yet still allow this.

Maybe the system was stressed in some unexpected way. This stress’ profile wasn’t predicted, characterized, mitigated. The system design didn’t account for it.

A multi-tasking operating system is likely part of the picture. Maybe another task was started that tied up crucial resources, even just CPU. Maybe not even a lot of resources, or not for very long. A multi-tasking operating system is geared to never say “enough.” Another task in the CPU’s ready queue? No problem. Out of RAM? Swap some to disk: user programs can’t even tell!

Information hiding gets us off the “honors system” with memory usage. But in the time domain, you’re still very much on the honors system: no one can make you complete your task in a given time. In fact, any innocuous-looking call can have any amount of code hiding deep inside it.

You can make a user wait for a tenth of a second or more and still seem really responsive. (Think “garbage collection.”) But a real-time data feed won’t wait. It’s a different ball-game.

Maybe we’re just seeing a hardware limitation hit. Maybe the best machines money can buy just can’t keep up with certain kinds of volume. There’s no guarantee they can.

Interesting stuff. Hat’s off to the author for such a detailed analysis.

Via ZeroHedge.

All are super-cool. But all are also astonishingly divergent in their approach to many of the details. So much so that one has to learn each one separately. My wife (an Android user) picks up my (webOS) phone and gets frustrated with it.

I find this particularly surprising since we’ve been making “intuitive” Graphical User Interfaces for a generation now, with standards that have been around nearly that long.

I’m sure they’ll converge again before too long, as (hopefully) the best ideas are adopted broadly.

Notice the giant Download button on the right. That’s really an ad for who-knows-what. To download ClamWin, you want the much-smaller download menu item on the left.

Caveat emptor.

As complexity grows, paths (through the software) and combinations of paths not often taken now fire. We spend a lot of time and energy controlling and predicting what will happen, but our best efforts aren’t always up to it.

Hats off to Amazon for publishing their detailed finding.

And it’s very cool. Your calendar magically sync’s with the web, available wherever you go.

What’s not to like?

Two decades ago, we touted the LAN. Sit down at any computer in the enterprise, log on and do your work. Super-cool.

Then we rely on the LAN, and when it’s down, lots of expensive people are sitting around.

Now when “the cloud” is down we get the same thing. And, yes, the cloud does go down.

As mysterious and cantankerous as the LAN could be, the cloud is more so. More out of one’s control. Makes me nervous. Am I being curmudgeonly or prudent?

And though it’s cool that the apps are free, how much leverage do we have over Google to keep it all humming, or fix it fast when it breaks?

If you’re a developer, consider screen height a limited, precious resource. Conserve it. Trade width for height. Kill height cruft. (Can I coin that?)

Button bars: traditionally horizontal at the top of the app. Can you make it vertical, to the left or right?

Even the traditional menu bar (“File Edit View … Tools Window Help”) crowds you down by its height.

Case study: Amazon’s Instant Video in Internet Explorer. IE adds menu items and multiple button bars at the top. Then amazon’s web-site adds its headers across the top. The video winds up a tiny fraction of its potential size, squeezed by all the height cruft. Not to blame Amazon: there’s a “full screen” button, and F11 in IE takes away a bunch of stuff (if you know about it).

The lesson: when every layer adds its own, it compounds.

Software developers take heed.

As a user, there’s lots you can do to conserve height.

Did you know you can put the Windows task bar to the left or right? I put mine to the left, as narrow as possible. You lose a little of the icons’ descriptions, but mousing over gives them back. It flushes out some bugs, too: some programs start in the upper left corner, winding up under the task bar. (To move the task bar, put the mouse on the middle top edge and drag it to the middle left.)

Most software today lets you move menu bars, and the best ones let you dock them to the left or right, making them vertical. Very nice, though they can truncate text menus. Your word processor has several: don’t live with them crowding you. It’s worth retraining your eye to work with them vertically. (Convince your complaining co-workers, too.)

For working with source code, height is particularly valuable. Source-code flows down, and seeing more at once is better. I have a two-monitor set-up on my desk-top, and my cheap, last-generation NVidia video card lets me turn one monitor sideways. A $40 monitor stand and you’re in business. This has been an indispensable productivity boost for me. Don’t work with all horizontal monitors.

When looking at code, can you bump your font-size down one? You’ll see a lot more.

Update. I promise I’m not making this up: one day after this pontification a client passes along a request to do exactly this: rearrange things to conserve screen height in a program I wrote a couple years ago. File this under eerily prescient or physician heal thyself?

Here’s another to add to the mix: Cake. And this brief intro on the Boost-interest digest makes the pitch.

No makefile at all. You put compiler flags right in the source code, and it walks your source, looking for special comments and using some naming conventions.

I like the idea of compiler flags in the source. Source-code attributes like dllimport and pragma comment(lib…) prove that’s useful.

You need g++ and make (behind the scenes), so that constrains its user base. Will the naming conventions be too restrictive? It uses a global configuration (in /etc/), but I can envision wanting a project-specific common configuration file, too, being the control freak I am. Will it accommodate?

Put it on your watch list.

It’s Google Street View inside the prominent museums of the world, with high-resolution images of each work.

What a great concept! Hat’s off to them.

I’ve been through Amsterdam three times (stop-overs to other destinations), and never got to see either the Rijksmuseum or the Van Gogh Museum. I look forward to exploring them here.

I hope and expect that this will increase museum traffic.

Since hacking pushes one towards paranoia, let’s go there for a minute.

An attacker being able to change source-code in any SourceForge repository, bypassing change-logs and hacking files’ time-stamps, could introduce compromised source-code to a lot of open-source projects that touch on security. The commercial packages that rely on them multiplies that compromise up by who-knows-how-much.

Wow. Ugly.