Re: [Quickfix-developers] Latency & Quickfix/J

[Oren M. <or...@qu...>]

QuickFIX comes with a setting to use TCP_NODELAY.  Steve, do you know if 
this configuration has been carried over to QuickFIX/J?  I didn't see it 
in the documentation.

--oren

Ian Johnson wrote:

> Version 1.0.0 b2 (Jan 06)
>  
> Hi,
>  
> Does anyone know how i might control TCP options and/or buffering in 
> Quickfix/J? I realise that the current version is implemented over 
> netty and I don't know how/if it can be configured. Options i am 
> interested in are send/receive buffering and TCP_NODELAY.
>  
> I understand that incorrect use of these options can affect throughput 
> adversely, but i am trying to address latency of updates at lower 
> message volumes.
>  
> Does anyone have any other suggestions of where latency in message 
> transmission and/or reception can be addressed?
>  
> An example of the scale of my problem is that i am experiencing 
> "jitter" in messages (MarketDataIncrementalRefresh) sent fairly 
> constantly.
>  
> At rates of 15-20 msg/sec (around 3-4k bytes per second), the jitter 
> is 2-300ms.
> At rates of 60-70 msg/sec (around 12-15k), the jitter is still 100+ ms
>  
> Its not until throughput increases significantly that the latency 
> becomes less significant
> (2-250 msg/sec), the jitter is < 50ms
>  
> I am using enhanced Java 1.5 precision timers, so timings have 
> granularity of better than 1 ms (my measurement threshold)
>  
> I have implemented SystemTimeSource to use System.nanoTime() (with 
> mods) and time the SendingTime FIX stamp (with ms) to received delay. 
> The absolute delay is not relevant (due to mismatched clocks) -  i am 
> just looking at the variation in delay from msg to msg. 
>  
> The server/client are in US/UK, and normal ping times between them are 
> approx 80ms (and pretty solid), available bandwidth is up to 1Mb.
>  
> Does anyone have any experience of how this jitter will be affected by 
> SSL tunnelling (stunnel). I don't have control over the sender but can 
> affect "tuning" of stunnel parameters at either end.
>  
>  
>