1.
ZeroAOS시험중 가장 큰 부분은 ZTerminal입니다. 처음 구상했을 때 ZTerminal은 없었습니다. 속도가 중요한데 GUI를 사용할 이유가 없다고 판단했습니다. Linux의 curses를 이용하여 모니터링과 관리를 위한 Terminal프로그램을 개발하여 사용했습니다. 그렇지만 DMA가 특정한 트레이더가 아닌 리테일서비스로 발전하려면 반드시 GUI가 필요하다는 결론을 내릴 수 밖에 없었습니다.
GUI를 구성할 때 어떻게 할지가 이슈였습니다. HTS처럼 Request/Reply방식으로 서비스를 구성할지를 생각해보았습니다. 서버에 대한 부담을 최소화하고 ZTerminal을 통하여 트레이더가 자유롭게 의사결정을 할 수 있도록 하기 위하여 원천데이타를 주는 방식을 선택하였습니다. MOM을 놓고 보면 ZeroOMS나 ZTerminal은 똑같은 메시징클라이언트이도록 설계하였습니다.
ZTerminal은 가공한 시세데이타를 받지 않습니다. 시세분배시스템이 제공하는 체결과 호가를 그대로 받습니다. 또한 주문체결데이타도 FEP가 내려주는 데이타를 그대로 받습니다. 때문에 내부 데이타관리를 위하여 SQLite를 메모리방식으로 사용합니다. 여기서 한가지 선택을 하여야 했습니다. ZTerminal이 ZeroAOS에 접속했을 때 장중에 발생한 모든 데이타를 받아야 할지, 아니면 접속시점부터의 데이타를 받아야 할지를 결정하여야 했습니다. 시세와 주문체결을 나누었습니다. 시세는 접속시점의 데이타로, 주문체결은 장중 전체데이타로 정하였습니다. 장중 전체 데이타라고 하지만 트레이더에 따라 데이타량은 처차만별입니다. 하루 수만 건을 거래하는 고객과 수백 건을 거래하는 고객이 14:00에 접속했을 때 받을 데이타는 100배의 차이를 보입니다.
자동매매 전략을 개발하여 십만건 정도의 주문/체결데이타를 만들었습니다. ZTerminal을 이용하여 장중에 발생한 데이타를 받도록 했습니다. ZTerminal은 주문체결데이타를 받으면서 주문체결내역 및 포지션내역을 생성합니다. 단순한 데이타 수신이 아니라 데이타 처리까지를 포함합니다. 두가지 문제가 발생하였습니다.
첫째 데이타를 받는데 너무 오랜 시간이 걸립니다.Latency라고 할 수 있습니다.
둘째 데이타를 받는 동안 대역폭이 다 사용합니다. 다른 업무처리를 할 수 없습니다. Throughput입니다.
이것을 어떻게 해결할지를 놓고 고민을 하다 TCP Tuning을 하기로 하였습니다. 오늘의 주제인 윈도우OS의 TCP Tuning이 나오는 배경이 여기에 있습니다.
2.
HTS 클라이언트는 아무리 많은 데이타를 받아서 서버에서 데이타를 조절합니다. HTS API로 받은 데이타와 ZeroAOS API로 받는 데이타는 다릅니다. 그렇기 때문에 더 빨리, 더 많이 처리하여야 하는 이슈가 중요합니다. 알고리즘트레이딩교육중 제가 맡은 부분을 교육할 때 이런 말을 합니다.
“Linux와 윈도우를 놓고 고민하지 말라. 리눅스가 절대적으로 빠르다는 결과는 없다. 다만 리눅스가 잘 돌아가도록 만드는 전문가가 만을 뿐이다. 윈도우도 튜닝을 하면 리눅스이상의 성능을 낸다.”
그렇지만 저도 윈도우 튜닝을 해보지 않았습니다. 한참 HTS 서버를 개발할 때 AIX와 Solaris의 튜닝을 해본 경험뿐입니다. 흔히 윈도우를 사용하는 분들이 가끔 접하는 프로그램이 regedit입니다. Registry Editor의 약자로써 커널 패러매터를 변경하는 것을 도와주는 프로그램입니다. 실행해보면 수많은 값들이 나옵니다. 이 중에서 TCP/IP의 성능에 영향을 주는 것을 찾아서 변경해주어야 합니다. 출발는 구글링입니다.
먼저 TCP 성능에 영향을 주는 윈도우 레지스트리는 무엇인지를 알아보죠. 아래는 Windows 2012 Server의 레지스트리입니다. 윈도우 7과 비교하니 비슷합니다. OS마다 차이가 있으므로 사용하는 OS의 레지스트리를 따로 조사하여야 합니다.
Windows Sockets and DNS Registry Parameters
Windows XP용 TCP/IP 및 NBT 구성 매개 변수
머리가 아픕니다. 여러가지중 DefaultReceiveWindow와 DefaultSendWindow라는 값이 있습니다. 성능에 많은 영향을 주는 값들입니다. 이를 설명한 자료입니다.
TCPWindowSize defines the amount of receive data (in bytes) that can be buffered during a connection at TCP/IP layer. The sending host can send only that amount of data before it must wait for an acknowledgment and window update from the receiving host. Windows will self-tune the TCP window size if it’s not explicitly defined in registry.
DefaultReceiveWindow defines the default receive buffer in Socket layer. By default, it’s 8 KB. Programs based on Socket gets data from that buffer. When a program receives more data than this buffer is configured to hold, all data received up to this count must be transferred to the program before receiving continues. When this happens, an acknowledgement will be sent to the source machine.
What problem does the receive window solve?
TCPIP is a reliable network protocol where each packet sent is acknowledged by receiver, and if the sender doesn’t get the acknowledge packet back within a certain timeout, then it retransmits the original packet. But it is inefficient to wait for the acknowledge packet from the receiver before sending the next packet. The Receive WINdow(RWIN) solves the problem of the sender constantly waiting for the receiver acknowledge.How does receive window work?
The RWIN size specifies how much data, which can be sent to the receiver without getting an acknowledge from the receiver. This allows the sender to send several packets without waiting for acknowledge. It also allows the receiver to acknowledge several packets in one stroke.Why is the size of the receive window important?
If the RWIN is too large, then the sender will spend a lot of time resending the entire RWIN every time packet loss is detected by the receiver. This is especially important if on a high collision network like a 100 Mbit Ethernet HUB. If Selective Acknowledgment (SACK) is enabled then it should lessen the downside of a too large RWIN.If the RWIN is too small, then the sender will be blocked constantly because it fills out the RWIN with packets before receiver is able to acknowledge that it has received the packets.What is the proper size of the receive window?
The optimal RWIN is mainly dependent on two things:Latency: The time it takes for a network packet to reach destination and get a reply back (Also known as ping time). If the latency is high and the RWIN too small, then it can allow the sender of data to fill out the RWIN before any acknowledge packet is returned. The latency for a connection is dependent on how quick the sender and receiver(and routers in between) are able to handle packets. If reaching the bandwidth limit of the physical line, then the latency becomes high.
Bandwidth: The amount of data that can be sent within a given time. If the bandwidth is high and the RWIN is too small, then sender can fill out the RWIN too fast, before the receiver can acknowledge the received data. The max bandwidth for a connection is dependent on the lowest available bandwidth at sender and receiver(and routers in between). The max limit can also depend on the ISP capping, or by the receiving/sending application throttling the connection.
How to find the optimal receive window size with PING?
To use the PING (Packet InterNet Groper) tool to find the optimal RWIN Size, ping your ISP with the Max Transfer Unit(MTU) size (The -28 is because of the IP- and ICMP-Header which the PING tool adds.)
PING destination.address -f -l
-n 10 Then insert the values of your connection in this calculation :
Bandwidth(kbps) / 8 * Average Latency(MiliSec) = RWIN Size(Bytes)
Then round up the RWIN Size to a multiple of the Maximum Segment Size (MSS) which is equal the MTU Size subtracted the size of IP Header (20 Bytes) and TCP Header (20 bytes + ? bytes depending of options like timestamp being enabled). So if your MTU Size is 1500 then your MSS is usually 1460 (1448 if timestamp is enabled).
Finding the optimal TCPIP receive window size중에서
윈도우 이용자가 읽고 튜닝하려면 복잡합니다. 좀더 쉬운 것이 필요합니다. 그래서 한방에 쉽게 해결하는 것을 찾았습니다.(^^) SpeedGuide.net이라는 곳에서 제공하는 프로그램과 자료입니다. 아래는 튜닝하여야 하는 항목과 권고값을 정리해놓았습니다. 윈도우 XP와 윈도우 7의 경우 튜닝가능한 값이 많이 다릅니다. XP보다는 윈도우 7이 훨씬 다양합니다.
Windows 2k/XP – More Tweaks
Windows 7, Vista, 2008 Tweaks
위의 설정값을 Regedit로 하면 너무 힘듭니다. 그래서 TCP Optimizer라는 프로그램까지 제공하고 있습니다.
이를 윈도우7에서 실행하면 아래와 같은 화면입니다. 윈도우 XP일 경우 화면은 단순합니다
이상 자료를 이용하여 시험용 PC에 각각 튜닝하였습니다. 사양은 아래와 같습니다.
Notebook :Intel T2300 1.66Ghz Memory 2G 윈도우 7 32bit
조립PC : Pentium Dual Core E6300 2.8Gha 2G 윈도우 XP
윈도우가 제공하는 성능모니터로 확인해본 결과 가장 큰 차이는 대역폭입니다. 튜닝전일 경우 10M를 기준으로 약 3%를 전후를 사용했지만 튜닝후 50%를 넘는 대역폭을 사용합니다. 그만큼 데이타 처리도 빨라졌습니다. 윈도우 7이 제공하는 리소스모니터는 잘 만들었더군요. 이번에 처음 사용해보았습니다.
3.
이상의 결과를 놓고 일반화할 수 없습니다. 튜닝이란 정답이 없습니다. 환경이 다 다르기때문입니다. 그럼에도 윈도우도 튜닝할 수 있는 OS라고 생각하고 업무에 최적화하도록 노력했으면 합니다. HTS로 거래할 때 속도를 빠르게 하고자 할 때 OS Lateny 혹은 Application Latency를 줄이기 위해 레지스트리에 도전해보세요. 혹 API로 매매하더라도 마찬가지입니다.
최적화는 공짜로 얻어지지 않습니다. 시험과 시험끝에 얻어낸 결과입니다.
