Re: [Quickfix-developers] Latency & Quickfix/J
Brought to you by:
orenmnero
|
From: Oren M. <or...@qu...> - 2006-01-24 19:05:14
|
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. > > > |