John, Jim.. All:
From a purely technologically-oriented and admittedly selfishly-driven set of needs, there are many synergies that can be leveraged from HFT's ascension that are external to the financial machinations supported by it, just as the technology that was used in my first handheld calculator made by Bowmar was an offshoot of NASA's moon mission. These synergies are both timely for priming and adding a certain level of bulk for the justification of an ecosystem (bringing it to scale), which will increasingly be needed for the next round of architectural contractions in general. We are seeing this need for architectural contraction, marked by closer proximity of clients and servers, and even peer-to-peer designs, taking place all around us today.
We see it in the need for microgrids, in order to avoid the waste heat that is dissipated over long transmission lines on the larger, national grid; in residential neighborhoods where hybrid fiber-wireless (HFW) architectures will support a proliferation of smaller cell sites in still-unimagined ways that will foster frequency-reuse resulting in higher speeds and performance for individual end users; in areas where being geographically closer to market centers and user populations (as in this case of HFT) means vastly improving competitive edge, such as the "search" model where every millisecond of additional delay encountered by end users can be equated to millions of dollars of lost revenue; in video distribution and caching, the list is long.
In general, the more distant a real-time application target entity tends to be from the supplicant, the more network costs (in all forms, both performance-wise and dollar-wise) are incurred.
This by no means suggests that the so-called "follow-the-sun" model of locating data centers in regions of the globe where renewable energy is plentiful is no longer valid, since there will always be enough 'batch' type work to keep those data centers humming for ages to come. What I'm suggesting, however, is that data centers that are located in Iceland and the Sahara Desert will have very little beneficial effect in the delivery of real time applications going forward, with the obvious exception of inhabitants of those areas, and the world is becoming increasing 'real-time,' not batch.
There's a great deal of rethinking taking place at this time with respect to best-efforts at various layers of the stack, in particular the need to provide timing and synchronization (as opposed to Ethernet's characteristic asynch delivery of frames) in connection with some forms of super-high speed Ethernet beyond 10Gbps, and new modes of testing and parameterization of performance criteria, and much more, that have all been moved along rather swiftly by the pursuit of optimal HFT facilities during the past twenty years (the last two years in particular). All of these applications that appear to be limited to HFT are now beginning to dovetail very nicely with the other areas I cited above.
HFT and Cloud Computing (a term that I use very loosely here, for obvious reasons, but at some point requires its own thread AGAIN), while different, are nevertheless on a collision course. Comparable skills and technological gadgetry will be required for virtual desktop infrastructure (VDI) and where optimizing latency between domains of a cloud fabric is seen as crucial, especially when one considers that those domains might in actuality be located continents apart, demands it, and there will be lots of places going forward where these virtualized substitutions for copper cage-like constructs will apply.
Just a few thoughts that I've been mulling since aladin's original reply to me, and now, in connection with Jim's observations as well, which I began jotting down last night but aborted midstream. Debt paid.
FAC
------ |
