Hardware and Software Requirements - Trading Technologies
Hardware and Software Requirements - Trading Technologies
Hardware and Software Requirements - Trading Technologies
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Table 1:<br />
Registry Setting TT Machine Description<br />
DisableTaskOffload<br />
IgnorePushBitOn<br />
Receives<br />
TcpAckFrequency<br />
SynAttackProtect<br />
TcpTmedWaitDelay<br />
TCPWindowSize<br />
Server Machines<br />
Server Machines,<br />
Client Machines<br />
Server Machines<br />
Remote Hosts,<br />
WAN Routers<br />
Remote Hosts,<br />
WAN Routers<br />
Remote Hosts,<br />
WAN Routers<br />
This toggles checksum offloading. In general, offloading<br />
the checksum calculation to the device driver is<br />
supposed to free up the OS from doing the work; therefore,<br />
making the process more efficient. TT has tested<br />
this, <strong>and</strong> it shows that leaving the OS to do the work is<br />
actually faster <strong>and</strong> more efficient.<br />
This allows any incoming packets without Push Bit set<br />
to be treated as though they were sent that way. This<br />
makes the application more efficient by h<strong>and</strong>ling fragments;<br />
for example, say a 1500 byte packet turns up.<br />
Normally TCP would hold this until it receives what it<br />
assumes to be the end of the stream, or a packet with<br />
Push Bit set. This adds latency <strong>and</strong> can stall the application<br />
from h<strong>and</strong>ling the data because it is now waiting<br />
on the OS to pass it up. With this setting, TT's application<br />
can dissect the 1500 byte packet sent out - say 10<br />
prices - but retain a small fragment while waiting for<br />
the next packet to arrive. This means that data is send<br />
all the time, making it a more consistent flow.<br />
To make better use of the b<strong>and</strong>width the Nagle Algorithm<br />
is used. This means that it accumulates data until<br />
it receives an ACK from the receiving side; however, if<br />
delayed ACKs are turned on, it can create an even<br />
greater latency in sending <strong>and</strong> receiving data.<br />
This closes half open TCP connections faster so a SYN<br />
attack cannot create a resource failure.<br />
This decreases the time wait state for a closed TCP session.<br />
Normally the system takes three (3) minutes to<br />
recover the resource, but this can be set to 30 seconds.<br />
This allows us to set the size of the TCP receive window<br />
to suit the b<strong>and</strong>width of the line. This is now normally<br />
set in the TTM config file.