1.
FIX Protocol이 ?Low Latency시대, 알고리즘 트레이딩의 시대에 어떻게 변화발전하고 있는지를 정리한 적이 있습니다.
이 때 몇 개 회사가 협의체를 만들어 High Performance FIX Messaging을 위한 작업을 한다는 소식을 전하였습니다. 모임을 만든지 얼마 지나지 않았는데 High Performance Interface Working Group이 첫번째 산출물을 내놓았다고 합니다. 아래가 결과물입니다.
2.
우선 시험을 위한 업무환경을 보면 시세데이타 처리와 주문데이타 처리를 FIX Protocol이 담당합니다. FIX 엔지는 상용제품과 오픈소스로 유명한 QuickFIX를 각각 사용하였습니다.
?
위의 그림이 시나리오입니다. 위의 보고서가 내린 결론은 다음과 같습니다.
1)Using a commercial FIX engine is 16 time faster than open source
2)The spread of the jitter was a narrow 2 micros for commercial engines and wide 50 micros otherwise.
3)Using Low Latency networking for non-LL code had no effect.
4)Well written Java code works as well as compiled native code.
“Low Latency를 이용한 매매를 하고자 한다면 사용제품을 선택하라”(^^)는 교훈일까요? 각자의 몫입니다. 제가 관심을 가진 부분은 위의 결과가 아니라 아래입니다.
Tuning the Network Interface Cards with kernel bypass technology improved the performance of both commercial engines and demonstrated a 50% reduction in latency. This translated into a round-trip saving in latency, which would have material impact on the trading strategy being executed. Engineering an integrated trading platform was proven to deliver incremental benefits in reducing overall latency.
보통 TOE=Hardware Acceleration을 판매하는 회사들은 TCP/IP환경이면 ?이익을 볼 수 있다고 광고를 합니다. 그런데 위의 결과는 다릅니다. 오픈소스인 QuickFIX/Java 혹은 QuickFIX/C++ 모두 TOE의 이익을 얻지 못했다고 합니다. 왜 그럴까요?
