07.05.2015 Views

Hardware and Software Requirements - Trading Technologies

Hardware and Software Requirements - Trading Technologies

Hardware and Software Requirements - Trading Technologies

SHOW MORE
SHOW LESS

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.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!