1.
몇 일전 코스콤의 신정보분배시스템을 다루었습니다. 이 때 시세시스템도 Latency에 관심을 가져야 한다고 했습니다. 이와 관련하여 재미있는 자료를 하나 소개합니다.
미국 주식거래소인 BATS의 자료입니다. 얼마전 BATS는 Low Latency와 관련된 Feed Service를 공개하였습니다. Market Data Feed처럼 Latency와 관련된 정보를 제공하는 데이타포맷입니다.
Latency 측정방법은 Order to Quote Latency입니다. BATS가 주문을 접수한 후 호가시세로 전송될 때까지의 시간입니다. 제공하는 정보는 다음과 같습니다.
Begin Time Number of milliseconds from midnight Eastern Time.
End Time Number of milliseconds from midnight Eastern Time.
Count Count of orders used in calculation of all other metrics from Beg in Time to End Time.
Minimum Minimum order processing latency from Begin Time to End Time in seconds.
Maximum Maximum order processing latency from Begin Time to End Time in seconds.
Average Average order processing latency from Begin Time to End Time in seconds.
Standard Deviation Standard deviation of sample.
2.
이상을 근거로 BATS가 발표한 Latency정보입니다.
이중에서 코스콤의 시세배분시스템과 관련잉 있는 Order To Quote Latency를 살펴보도록 하죠.
Average 182 microseconds
80% of orders within 185 microseconds
99% of orders within 242 microseconds
99.9% or orders within 491 microseconds
몇 번 Latency 모니터링을 이야기할 때 강조하였지만 메시징의 품질은 평균값이나 최저값이 아닙니다. 99.9%의 메시지가 어느 정도에 처리되는가 하는 점입니다. PITCH포맷으로 멀티캐스팅되는 시세가 491 마이크로초이내에 처리된다는 뜻입니다.
또다시 느낍니다. KRX의 Order To Quote Latency는 얼마인가요? 시세배분시스템을 새로이 구축하면 지연이 줄어드나요? 정성적인 목표가 아니라 정량적인 목표가 나왔으면 합니다.
3.
어떤 트레이더가 자신들이 원하는 하드웨어 및 네트워크 사양이라는 것을 보내왔습니다.? 자세히 들여다 보았습니다.? Intel Xeon 3.6GHz를 사용하는 CPU가 12코어이고 메모리는 72G입니다. Infiniband 스위치를 도입하자고 하고 있습니다. 첫 인상은 “빠른 것을 모아 놓으면 빨라진다는 생각을 하는구나” 였습니다.
과연 그럴까요? 어제도 썼지만 레이턴시를 좌우하는 열쇠는 매우 다양합니다. 레이턴시 측정을 위한 표준적인 방법이 없으면 서로 다른 잣대로 자신들의 숫자를 말하고 영업을 합니다. 미국에서 이런 경우가? 있다고 합니다.
If firms agree to adopt a standard, it would eliminate situations where one organization might be measuring latency from the dirty side of their firewall, while a competitor measures it from the outbound-side of its exchange gateway inside its firewall, Young adds.
그래서 미국을 중심으로 FIX내에 IPL이라는 워킹그룹을? 만들어 표준작업을 하고 있습니다.
As more firms publish their latency performance numbers to their clients, firms are drowning in data that is difficult, or impossible, to benchmark accurately.
“Some firms have been creative with their latency by citing the latency for specific tasks, such as order validation, without including other relevant latencies like order translation,” says Lime’s Jacobs. “If it takes 100 microseconds to translate the order and then another 50 microseconds to translate it again into the appropriate exchange protocol, who cares if order validation takes 5 microseconds when the entire latency path could?be around 200 microseconds?”
One of the major issues facing brokers and exchanges is where to place the starting blocks and finishing line when it comes to measuring latency. Throughout the entire trade lifecycle there are a number of milestones they could use, such as when a quote is generated, when an investor processes the quote and turns it into a trading decision, when the broker receives the trade message and sends it to the market via the appropriate exchange gateway, and then when it hits the matching engine to when a match is made and an order acknowledgement is sent back via a similar route.
“When it comes to sending orders, there are a lot of assumptions about latency,” says Lime’s Jacobs. “Is it referring to when the customer contemplates sending the order or when the exchange receives the order? When discussing latency, one needs to define what components of the latency chain are being discussed.”
Striving for Standards중에서
우리나라 DMA영업을 하는 분들도 비슷합니다.
전산실에서 작성한 자료를 토대로 “우리는 1마이크로초”, “우리는 10마이크로초”,”우리는 700나노초”라는 식으로 영업을 합니다. 조그만 아는 사람이면 기준들이 다 다릅니다는 것을 압니다. 측정방법도 다 다릅니다. 소프트웨어로 로그를 남긴 다음 시간계산을 할 듯 합니다. 오차가 너무 큽니다.? 그래서 표준이 필요하고 측정을 위한 시스템이 필요합니다.
