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.
>
>
>
|
