quickfix-users

[Quickfix-users] excessive latency of sendToTarget

[Joachim W. <joa...@ia...>]

Greetings,

we plan to use quickfix on the client side, and have implemented a small 
prototyp. We have no significant experience with quickfix.

When testing the prototype, we noted that the call to 
FIX::Session::sendToTarget() takes extremely long - we typically see 
latencies starting at 25ms (sic!) up to >100ms. Milliseconds. We would 
expect latencies clearly below 1ms.

This is
- with the ordermatch test market at the other end
- all running locally on a unloaded high-end 8-core machine
- latest quickfix release

Any idea what's wrong here?

  thanks, Joachim

Re: [Quickfix-users] excessive latency of sendToTarget

[Kenny S. <ks...@co...>]

We typically see latencies around 100us for a new order single message
without any repeating groups.  How are you measuring latency?

--
Kenny Stone
Connamara Systems, LLC


On Fri, Feb 18, 2011 at 8:37 AM, Joachim Worringen <
joa...@ia...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Greetings,
>
> we plan to use quickfix on the client side, and have implemented a small
> prototyp. We have no significant experience with quickfix.
>
> When testing the prototype, we noted that the call to
> FIX::Session::sendToTarget() takes extremely long - we typically see
> latencies starting at 25ms (sic!) up to >100ms. Milliseconds. We would
> expect latencies clearly below 1ms.
>
> This is
> - with the ordermatch test market at the other end
> - all running locally on a unloaded high-end 8-core machine
> - latest quickfix release
>
> Any idea what's wrong here?
>
>  thanks, Joachim
>
>
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>

Re: [Quickfix-users] excessive latency of sendToTarget

[Joachim W. <joa...@ia...>]

Am 18.02.2011 16:42, schrieb Kenny Stone:
> We typically see latencies around 100us for a new order single message
> without any repeating groups.  How are you measuring latency?

For this testing, plain simple, using Intel's ThreadBuildingBlocks, like:

tbb::tick_count ticks = tbb::tick_count::now();
FIX::Session::sendToTarget(newOrderSingle);
std::cerr << (tbb::tick_count::now() - ticks).seconds() << std::endl;

This timing mechanism (w/o printing, of course) works very well in other 
places reporting with nanosecond-resolution, and I don't suspect this 
being a problem here.

The newOrderSingle is plain simple as well:

         FIX42::NewOrderSingle newOrderSingle(
             FIX::ClOrdID( fixInfo->ClOrdID ),
             FIX::HandlInst( '1' ),
             FIX::Symbol( fixInfo->Symbol ),
             FIX::Side( fixInfo->Side ),
             FIX::TransactTime(),
             FIX::OrdType( fixInfo->OrdType )
         );

         newOrderSingle.set( FIX::OrderQty( fixInfo->OrderQty));
         newOrderSingle.set( FIX::TimeInForce( fixInfo->TimeInForce));
         newOrderSingle.set( FIX::Price( fixInfo->Price));
         newOrderSingle.getHeader().setField(FIX::SenderCompID( 
fixInfo->SenderCompID));
         newOrderSingle.getHeader().setField(FIX::TargetCompID( 
fixInfo->TargetCompID));

Thus, how could we collect orders of magnitude for the latency?

  Joachim

Re: [Quickfix-users] excessive latency of sendToTarget

[Joachim W. <joa...@ia...>]

Am 18.02.2011 17:06, schrieb Joachim Worringen:
> Thus, how could we collect orders of magnitude for the latency?

Maybe the transaction are all logged synchronously to disk (would be NFS 
in this case). Need to check this...

  Joachim

Re: [Quickfix-users] excessive latency of sendToTarget

[martin <cra...@gm...>]

Joachim Worringen <joachim.worringen@...> writes:

> 
> QuickFIX Documentation: 
http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> Am 18.02.2011 17:06, schrieb Joachim Worringen:
> > Thus, how could we collect orders of magnitude for the latency?
> 
> Maybe the transaction are all logged synchronously to disk (would be NFS 
> in this case). Need to check this...
> 
>   Joachim
> 
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> 

Hello, did you figure this out?
We did profiling on our own app and found out that this function takes about 70-
80% of total time.
Would be very interested to find what you have uncovered. We are looking to 
modify quickfix as first step.
thanks
martin
(you can email me direct at crabapple (at) gmail)

Re: [Quickfix-users] excessive latency of sendToTarget

[Joachim W. <joa...@ia...>]

Am 18.02.2011 17:19, schrieb Eugene Krel:
> If you are using a filestore on RH, NFS could be slowing you down:
>
> http://www.quickfixengine.org/forum/comments.php?DiscussionID=189&page=1#Item_2
> <http://www.quickfixengine.org/forum/comments.php?DiscussionID=189&page=1#Item_2>

For the record: this assumption could be confirmed. Setting 
FileStorePath to a local directory resulted in latencies of around 50us 
for this setup.

  thanks, Joachim