Low Latency, not fast but first

1.
Low Latency. 고빈도(High Frequency)라는 단어가 들어간 글들이 많이 사라졌지만 여전히 위력을 가지고 있는 단어는 Low Latency입니다. 한 때 고빈도와 저지연을 동전의 양면으로 애해했지만 기준이 다릅니다. 보통 Low Latency를 말할 때 시간을 잣대로 합니다. 그래도 밀리초, 마이크로초, 나노초와 같은 단위를 언급합니다. 이런 발상을 바꾸어 주는 글이 있습니다. 글 자체는 FPGA를 소개하는 평범한 글이지만 제목에 들어같 표현이 너무나 멋집니다.

Automated Trader에 실린 Is all trading now low latency?입니다. 알고리즘 트레이딩에서 중요한 것은 tick-to-trade latency(시세에 반응하여 체결이 이루어지는 시간)이라고 하면 Low Latency를 이용한 제품들의 평균 시간을 15-100 마이크로초라고 소개합니다.

In many cases, keeping the trading strategy current, updating the software and underlying algorithms, is as important as tick-to-trade latency. So, constantly running off to your network vendor of choice for bespoke updates to an FPGA is not exactly practical – and it is certainly far removed from the way that many trading firms operate (think ‘DevOps’).

This leaves the 99% of trades that still happen on servers running software-based algorithms.Trading rooms will still invest significant sums into low latency networking infrastructure: switches, network adaptors (NICs), transceivers and even specialist cabling. Latency is still an important issue; but it is on a different order of magnitude. Typical tick-to-trade times are between 15-100 microseconds.

There has been a race to eliminate as much of the latency as possible on the path outside the server. The more traditional switch vendors, namely Cisco and Juniper, have seen pressure from new entrants like Arista, Fujitsu, Mellanox and Metamako, which have a strong focus on latency. Equally, standard networking cards for servers have been replaced by supercharged NICs from the likes of Chelsio, Solar are, Mellanox and CSPi with their Myricom product line.

여기서 알파를 위해 발상의 전환을 하자고 하면서 다음과 같은 문장으로 low latency를 재해석합니다. “단지 빠르면 소용없다. 무조건 첫째가 되어야 합니다.” 라고 하면서 Queue Sequence의 중요성을 이야기합니다.

Tick-to-trade latency is not just about being fast. It’s about being first.

사실 ETF 차익거래를 했던 분들의 목표는 빠른 것이 아니라 첫번째였습니다. 그래야 목표한 수익을 얻을 수 있었기때문입니다.

2.
첫째가 되기 위해 매매시스템의 구조를 바꾸는 것도 한 방법입니다. 하지만 첫째는 아니지만 등외로 밀려나지 않기 위한 방법으로 현재의 구조를 최적화하는 것 또한 의미가 있습니다. 특히 소프트웨어 기반의 알고리즘인 경우입니다. 이와 관련하여 다양한 글들이 나왔고 저도 블로그에 올렸습니다. Cache Algorithm과 관련한 부분도 있었고 Inline과 관련한 부분도 있었습니다.

아래 글을 최근 고빈도매매가 번성하고 있는 인도개발자가 쓴 글입니다. 요지믄 소프트웨어로 개발할 때 유의할 점입니다. Context Switch는 OS와 네트워크카드를 튜닝할 때도 자주 등장합니다. Sequencial은 CPU Cache와 관련한 부분입니다.

Choose the right language
Keep it all in memory
Keep your hardware underutilized
Keep context switches to a minimum
Keep your reads sequential
Non blocking as much as possible
Async as much as possible
Parallelize as much as possible
What I’ve learned after coding for HFT and Low Latency Systems중에서

Mellanox가 발표한 The Next Frontiers for Low Latency Programmers은 Ethernet Card와 Multicore사이의 지연없이 데이타를 처리하는 방법을 소개합니다.

In order to maximize the utilization of their servers, and get the full return on the hardware investment, traders need to be able to bring data into to all cores, with the exact same latency, jitter, accuracy and reliability. In the past, bottlenecks in network adapter cards and the PCI bus did not allow this. Modern day network adapter cards, such as the Mellanox ConnectX®-4, include parallel pipelines for message handling, PCI connections that are 10x faster than the 10GbE network link (PCIe3x16 > 100Gb/s), and hardware based steering tables that allow direct steering of different flows to different CPU cores.

다만 자세한 소개는 웨비나를 통해 하겠다고 합니다.(^^) 아래가 주제입니다. 위의 글을 보면 신청할 수 있습니다.

Hardware and software approaches for achieving low latency data transfers
Operating system tuning examples to reduce jitter and increase platform stability
Programming examples of modern APIs that address latency, jitter, bandwidth, message rate, and CPU utilization
Practical approaches for instrumenting and monitoring low latency platforms

3.
low latency와 다른 주제이지만 알고리즘개발에 중요한 부분이 있습니다. 알고리즘인 소프트웨어가 이상동작을 할 경우 결과는 막대한 손실입니다. 단위시험이나 통합시험을 찾아낼 수 있는 결함도 있지만 확률상 쉽지 않은 결함도 존재합니다. 이런 오류를 최소화하기 위해 적용하는 방법이 보안코딩(Secure Coding)입니다. 국내의 경우 행정안정부가 소프트웨어 개발보안(시큐어 코딩) 관련 가이드을 만들어서 배포하고 있습니다. 금융회사가 발주한 SI프로젝트의 경우 대부분 위의 가이드라인을 준수합니다. 물론 약간 변형합니다. 알고리즘을 개발할 때 직접 적용할 수 없더라도 한번쯤 읽어보시길 바랍니다. 개발언어별로 가이드라인이 있습니다. 아래는 총론입니다.

Download (PDF, 48.78MB)

좀더 실질적인 가이드라인은 NASA의 코딩규칙이 아닐까 합니다. 자세한 내용은 원문을 참조하세요.

Rule No. 1 – Simple Control Flow
Rule No. 2 – Fixed Upper Bound for Loops
Rule No. 3 – No Dynamic Memory Allocation
Rule No. 4 – No Large Functions
Rule No. 5 – Low Assertion Density
Rule No. 6 – Declare Data Objects at Smallest Level of Scope
Rule No. 7 – Check Parameters and Return Value
Rule No. 8 – Limited Use of Preprocessor
Rule No. 9 – Limited Use of Pointers
Rule No. 10 – Compile all Code
NASA’s 10 Coding Rules for Writing Safety Critical Program중에서

4.
2016년 8월 금융위원회가 파생상품시장 활성화방안을 내놓는다고 합니다. 정책적 전환을 할지, 아니면 시늉만 할지 알 수 없습니다만 변화가 있을 듯 합니다. 다시금 Low Latency에 대한 관심이 높아질까요?

금융위는 최근 한국거래소 금융투자협회 등 업계로부터 파생상품시장 활성화를 위한 의견을 수렴해 이르면 다음달 종합대책을 발표할 예정이다. 금융위 관계자는 “파생시장이 함께 크지 않고는 현물시장 거래나 주가지수 수준도 현재 수준에서 크게 향상되기는 어렵다”며 “3분기 중 파생시장 활성화 대책을 내놓을 계획”이라고 말했다.

금융위는 △선물·옵션 기본예탁금(3000만원) 완화 △주가연계워런트(ELW) 호가제출 규제 완화 △우정사업본부 파생상품 차익거래 시 거래세(0.3%) 면제 등을 주요 안건으로 올려놓고 검토작업을 벌이고 있다. 이 밖에 파생상품 거래 안정성 제고 차원에서 △손실제한형 상장지수증권(ETN) 도입 △파생 거래정보저장소 도입 등도 포함될 것으로 알려졌다.

주요 안건 가운데 일단 선물·옵션 예탁금을 1500만원 선으로 낮추는 방안이 유력한 것으로 알려졌다. 1996년 파생상품시장 도입 이후 선물·옵션 예탁금은 최저 500만원에서 최고 3000만원 사이를 오갔다. 2013년까지 1500만원이던 선물·옵션 예탁금은 2014년부터 선물이 3000만원, 옵션이 5000만원으로 올랐다. 예탁금 인상이 거래에 미치는 영향은 컸다. 일평균 30조원 수준이던 선물 거래대금은 2014년 이후 18조~19조원으로 줄었고, 옵션 일평균 거래대금도 1조원 이상에서 7000억원대로 급락했다.ELW와 관련해서는 유동성공급자(LP)인 증권사의 호가제출 제한이 일부 완화될 전망이다.
선물·옵션 기본 예탁금 3천만원→1500만원으로중에서

Leave a Comment

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

이 사이트는 스팸을 줄이는 아키스밋을 사용합니다. 댓글이 어떻게 처리되는지 알아보십시오.