latest performance tests of QiuickFAST including OpenDDS

[Malcolm Spence]

We have now included a lot of new optimizations.

Yesterday (Jan 20th) we ran exactly the same tests as previous with
Arca and CME data.

We are now down to nanoseconds with Arca (and apparently Xetra if you
see Carlo's posting).

ARCA QuickFAST decode only: 0.65 us
CME QuickFAST decode only: 3.7 us

ARCA Across OpenDDS:
QuickFAST decode : 0.65 us
Conversion to simple application data type : 2 us
UDP Write data type across OpenDDS (same host) : 25 to 31 us
TCP Write data type across OpenDDS (same host) : 34 to 37 us

Total UDP Latency : 30 to 34 us
Total TCP Latency : 37 to 40 us

Throughput (30,545 ARCA messages in 650,000 us) : 47,000 ARCA
messages/sec

CME Across OpenDDS:
QuickFAST decode : 3.7 us
Conversion to simple application data type : 10 to 11 us
Conversion/split into sequence application type : 80 to 90 us
UDP Write data type across OpenDDS (same host) : 48 to 56 us
TCP Write data type across OpenDDS (same host) : 51 to 59 us

Total UDP Latency, simple CME message : 64 to 69 us
Total TCP Latency, simple CME message : 66 to 75 us

Total UDP Latency, split sequence CME message : 128 to 133 us
Total TCP Latency, split sequence CME message : 137 to 146 us

Throughput (9999 CME messages in 725,000 us) : 13,700 CME
messages/sec

We have not, as of yet, done anymore tuning on OpenDDS we are doing
some standardized testing of OpenDDS to compare it with commercial
messaging systems. We suspect we are already faster than them based on
some spot testing. When we get those numbers we will get a sens of
what we might be able to do.

In specialized circumstances, such as market data distribution, there
are options open to us that with a general set of tests might not
appear to be meaningful. We need a good set of baseline performance
tests first. then we can fine tune to leverage the domain aspects.

The good news is that for the most part, end to end, open source
solutions can provide you with less than 100 microseconds from feed to
trader eyeballs. That is pretty good considering the data distribution
framework is very application developer friendly, (i.e. above socket
level and does not drop packets).

regards Malcolm

PS another QuickFAST user in Europe is getting around 600 nanoseconds
per message on XETRA.

OCI St. Louis

[Malcolm Spence]

Just some new data. We made improvements which resulted in CME data
being processed about 40% faster.

We are now down at 2.7 microseconds per message on 3 GHz box.

thanks and regards Malcolm

Director of Business Development
OCI St. Louis MO USA
www.ociweb.com
TEL: 1-314-590-0206

[Malcolm Spence]

sorry for the typo we are now 30% faster.

[Hei Chan]

Hi Malcolm,

Thanks for sharing the numbers, and they look good.

I (like others I believe) would like to know whether they were generated with GenericMessageBuilder and one of the decoders (e.g. SynchronousDecoder and MulticastDecoder) or you guys used a customized decoder and message builder.

Thanks in advance.


Cheers,
Hei

--
You received this message because you are subscribed to the Google Groups "quickfast_users" group.
To post to this group, send email to quickfa...@googlegroups.com.
To unsubscribe from this group, send email to quickfast_use...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/quickfast_users?hl=en.