Performance: Minimum Latency
We define a “latency envelope” within our ticker plant technology. This is the total time it takes for a message to be sent from its originating source (e.g. an exchange or ECN) to the customer’s application. Within this latency envelop, we are capable of measuring and monitoring sub-latencies at every hop within the latency envelop. We even measure latency as messages are processed inside our middleware infrastructure processes and within customer applications. For example, we measure the time the message is received by our API used by the customer’s application, to the time the customer’s application processes the message. These are all included as sub-latencies within the entire message envelop. Our system therefore exposes both the end-to-end latency, as well as very granular hop-by-hop latency. This gives us and our customers a clear understanding of what their latency profile is and where and how best to correct or improve it. 
Messages take no more than 2 hops between any two applications in the system (including getting data through customer firewalls and routers), and individual applications are isolated from having to process unnecessary message traffic. Through this approach, our latency standard is less than one millisecond from Timestamp A (live feed or feed simulator) to Timestamp B (client application) at full volume throughput. We often record less than 500 microseconds for tailor subscriptions.
However latency is meaningless without reliability: what good is low latency if the data is unreliable? Our system achieves the delivery of reliable data with the lowest latency and highest throughput of any system available. With mandates such as RegNMS and requirements for full depth of book data, latency is meaningless without reliability. Our system achieves the delivery of reliable data with the lowest latency and highest throughput of any system available.
Probably the most important aspect contributing to our low end-to-end latency and high reliability record across our system is its “flat” virtual session architecture. Messages take no more than 2 hops between any two applications in the system, and yet individual applications are isolated from having to process unnecessary message traffic. This allows applications in the system to receive the data they are interested in faster than some vendor’s solutions that force all subscribing applications to processes all data on the wire, only to filter out and finally get the data they have interest in. Nack storms are also avoided, increasing throughput and eliminating undue latency that is caused by some vendor’s solutions.
Included in the TPS+Plus product suite are a combination of real-time administrative components and SNMP utilities that provide an extensive range of operational management capabilities. These capabilities include: interoperable subscription and contribution utilities, administrative agents, administrative desktop applications, standard SNMP publication, and more.
Each TPS+Plus component publishes extensive status and statistical information providing broad metrics of each running application and the system in general. These metrics are published through administrative agents that run alongside each application and are monitored through a common point of access using the IT Administrative Desktop (ITAD) – an application with an easy-to-use GUI that lets a system administrator view the entire system and drill down to view specific statistics for any individual component. Metrics are also published to MIBs and Traps for use with standard SNMP utilities.
Through the administrative agents, the IT Administrative Desktop, and SNMP MIBS and Traps, operators can be notified in real-time of any interruption of feed service, infrastructure disconnections, component failures, capacity warning, latency thresholds, and other critical events occurring in the system. InfoDyne has also assisted customers by providing component execution and monitoring scripts that report problems through e-mail, SMS, and other mechanisms.