Showing posts with label High frequency trading. Show all posts
Showing posts with label High frequency trading. Show all posts

Sunday, 13 April 2014

Why providing low latency is more challenging than providing scalability

Response time and capacity are the two fundamental indicators of software performance.In industry like finance low latency has a lot of value for the traders. High frequency trading which drives large percentage of trades in many markets requires very fast trading software that can react to market depth in microseconds or nanoseconds. Read about low latency challenges in finance industry here.

Performance challenges in the web technologies is more on scalability side.In trading software where we are looking at milliseconds, microseconds in the web world even 250 milliseconds is good enough as response time for end users. Even in the web world people want low service time at server side as high service time indirectly means low capacity but they wont care much if 50-100 milliseconds are added by Internet.

Why providing low latency is more challenging ?
Problem of scalability was solved with load balancing and horizontal scaling. Although there are technical challenges but a load of million of users can be distributed on thousands of serves and with proper design of software, load balancing and capacity planning.

Latency is the sum of time spent in all activities required to do some work.The time may be spent on CPU or in waits. Basic service time is the latency in which the request does not have to wait in the queue before being serviced. At very high capacity utilization the response time may be 10-100 times the basic service time if the utilization is high due to queuing. So the first important step is to have good capacity planning to manage the response time.If you get this wrong than even achieving a very low basic service time latency will be practically wasted.

Lets say you are able to achieve it and still want lower latency what do you do? Now that you know you have right load balancing and appropriate capacity utilization so that  response time is around basic service time mostly except for bursts.We now focus on reducing the basic service time.

Two basic things that can reduce the basic service time are
  • Better algorithms
  • Parallelism
here again not many problems have high parallelism. If you want even lower latency what do you do? To understand this we need to discuss what are the sources of latency and how industry is addressing these sources. I will discuss them in my posts in future. At a very basic level you need reduce the number of steps to complete the task or find a way to reduce the cost of steps. There are fundamental limits to reduction in number of steps or reduction of cost of a single step. Even if we look at hardware for example RAM, the increase in size and bandwidth over time has been significant but reduction in latencies is much less comparatively.

Comparing performance optimization and road travel
If you compare performance optimization to the road travel. you can achieve higher capacity by adding more lanes to the road. Here basic service time is the time to travel when road is completely empty. Your latency or time to travel increases if there is lot of traffic on the road which is like high latency due to high capacity utilization.Now if you want to reduce the time from the basic service time or time to travel on empty road, what can you do. Either you can find a shorter path or you need faster driving speed. There are limits to both of them. you cannot reduce the distance between two points beyond the shortest distance. You can not keep increasing the speed beyond a point. Similarly when reducing latency beyond a point it becomes more and more difficult. Industry is hacking into OS, libraries,network, switches hardware to reduce the sources of latencies but reducing it further is becoming more and more difficult and expensive. There are market gateways that can provide market update from wire to app memory in 1 microseconds. a single memory fetch from RAM can take 40 to 100 nano seconds so you can imagine you will exceed this latency even if you do 10 memory fetches.

Saturday, 7 July 2012

Low Latency Arms Race

Electronic exchanges and algorithmic trading have made low latency a big business. At all levels servers, switches, network, OS, applications etc there is a race to achieve lower and lower latencies.  A 1-millisecond advantage in trading applications can be worth $100 million a year to a major brokerage firm(ref). This was an estimate in 2007. In 2012 people are talking in terms of microseconds and nanoseconds.
For same trading strategy, market and instrument, competing algotrading software in two trading firms, the firm that gets the market data first and executes its order first in the market will beat the other firm in trading profits. 
Not all financial IT products require ultra low latencies, for example back office products for fees calculations etc no one cares about latencies, while front office products like market gateways have very "low latency" reqirements. The latency requirements for a product is derived from the business context.


Even for the front office products requirements for institutional investors and high frequency trading are quite different. For long term investment  to create a large position institutional invester may choose to use algorithmic trading to break large orders into small trades but here instead of market orders, limit orders will be used to buy at desired price. Order is late or fast does not matter much.

In the middle are short term manual traders. Minimum human reaction time to read a market depth and click a trade is between 100 - 250 milliseconds. So a normal trader will not try to aggress market opportunities that vanish in milliseconds but will trade on strategies that will be from minute to hours to a day to multiple days. So 1 millisecond here or there is not a big deal 

At the other extreme high frequency trading(HFT) is all about speed. HFT employs computerized algorithms to analyze incoming market data and implement proprietary trading strategies. High-frequency traders compete on a basis of speed with other high-frequency traders. By 2010 high-frequency trading accounted for over 70% of equity trades in the US (ref). One of the HFT strategy is to exploit arbitraging price discrepancies in some particular security trading simultaneously in different markets. This requires ultra low latencies and between the competing firms one with the lowest latency will win.

"Trading mostly with their owners money,they scoop up hundreds or thousands of shares in one transaction,only to offload them less than a second later before buying more.They can move millions of shares around in minutes,earning a 10th of a penny off each share.As a group,they earned $12.9 billion in profit in the past two years,according to the TABB Group,a specialist on the markets.TABB expects their earnings to slow this year as Wall Streets big brokerage firms fight back with their own faster computerised trading" NY Times 10 Oct 2011

With these kind of stakes there are big budgets and many buyers for low latency products.

Two important latencies are market data latency and order to market latency. The market data latency includes time from event in exchange till data is available to algotrading software or visible to human on trading GUI. This will include latencies on wire(exchange to trading center), latencies of internet gateway, latencies of switches/hub, latencies of router. At software level latencies of middleware, OS context switches, protocol libraries like FIX, TCP latencies etc will come into picture. 

Distance between algorithmic trading server and market exchange is a very important factor. There is roughly a delay of 5 microseconds per KM in fiber optic cable. If trading center is 200 km away 1 millisecond delay will be added to latencies
Co-Location is used to solve this problem.Trading firms can place computers containing their trading algorithms in special data centers close to or in the exchange. CME Co-Location Services is one example of Co-Location provided by exchange. 

Providing lower latency is a much bigger challenge than providing higher throughput. Over past few decades the bandwidth and size of RAM has increased exponentially but the latencies of RAM have decreased linearly. Even for very high end servers and fast RAM the latencies of memory access is 30 to 100 nanoseconds.Low latency requirements are nearly approaching hardware limits.

Quoting Kevin Slavin

"It takes you 500,000 microseconds just to click a mouse. But if you’re a Wall Street algorithm and you’re five microseconds behind, you’re a loser."