Forums  > Software  > to my high freak friends.  
     
Page 1 of 1
Display using:  

Nonius
Founding Member
Nonius Unbound
Total Posts: 12699
Joined: Mar 2004
 
Posted: 2016-07-13 16:32
listening to events on orders from exchanges or brokers.

a. async Task.
b. some sort of Polling.

compare, contrast, whats better bruvs.

Chiral is Tyler Durden

Nonius
Founding Member
Nonius Unbound
Total Posts: 12699
Joined: Mar 2004
 
Posted: 2016-07-13 17:14
at the phrog shop everything was a long poll. they might be right, as much as I hate phrogs. I did try async it seems ok. a guy told me it's slow.

Chiral is Tyler Durden

ax


Total Posts: 74
Joined: Jul 2007
 
Posted: 2016-07-13 23:07
I was unaware that anyone polls at least in there own program; they might be using select,poll,epoll, ... from a library.

indiosmo


Total Posts: 9
Joined: Jun 2011
 
Posted: 2016-07-22 22:20
Depends on your needs.

Blocking and interrupts are expensive, so for absolute low latency you can spin on a non-blocking socket, but that will require 100% of one core.

If latency is not that important then async is just fine.

Nonius
Founding Member
Nonius Unbound
Total Posts: 12699
Joined: Mar 2004
 
Posted: 2016-07-25 13:51
thanks indiosmo.

maybe I'll try spinning on a non-blocking socket.

right now, I've got an async Task that it is collecting order event messages from kdb and adding to a concurrent queue, and another async Task that's blasting out the queue items to some delegates. what's weird is it works for the first 10 to 20 messages then nothing happens, ie, the task that is managing the blasting out of queue items is doing nothing. I put a break point inside the await and it's not even getting hit.

anyway, just trying out something different.

Chiral is Tyler Durden

Lebowski


Total Posts: 66
Joined: Jun 2015
 
Posted: 2016-07-25 16:41
May not be exactly what you're asking about and my guess is given our differing degrees of experience you likely know this, but what you're (@nonius) attempting to do sounds like an application of the observer pattern. If you create an observer right at the layer your feed is coming in to delegate event handling of certain messages to your particular application you can encapsulate the task of handling queuing these messages into the observer and then built your individual event handlers separately. My guess though is that I may be misunderstanding your problem because you're a smart guy and what you're attempting above feels like a problem that's probably already been solved at most financial institutions; so I'm gonna reserve the right to say "I misunderstood the question" at this point.

Good luck.

Nonius
Founding Member
Nonius Unbound
Total Posts: 12699
Joined: Mar 2004
 
Posted: 2016-07-25 16:50
thanks Lebowski. Indeed it has been solved everywhere and I've never had to think about such a problem because a bunch of other guys were sourced to build out this stuff. I'm just toying around with something "on the side".

btw, I sort of gave up on the standard kdb C# wrap and am checking out qSharp, which has a sort of implementation that is closer to what I'm use to.

edit: wish one could paste code so indentations are respected.

like this:


using System;

namespace qSharp.Sample
{
internal class Subscriber
{
private static void Main(string[] args)
{
var q = new QCallbackConnection((args.Length >= 1) ? args[0] : "localhost",
(args.Length >= 2) ? int.Parse(args[1]) : 5000);
try
{
q.DataReceived += OnData;
q.ErrorOccured += OnError;
q.Open();
Console.WriteLine("conn: " + q + " protocol: " + q.ProtocolVersion);
Console.WriteLine("Press to close application");

q.Sync("sub:{[x] .sub.h: .z.w }");
q.Sync(".z.ts:{ (neg .sub.h) .z.p}");
q.Sync("value \"\\\\t 100\"");
q.StartListener();
q.Async("sub", 0);

Console.ReadLine();
q.Sync("value \"\\\\t 0\"");
q.StopListener();
}
catch (Exception e)
{
Console.Error.WriteLine("Error occured: " + e);
Console.ReadLine();
}
finally
{
q.Close();
}
}

private static void OnData(object sender, QMessageEvent message)
{
Console.WriteLine("Asynchronous message received: " + message.Message.Data);
Console.WriteLine("message type: " + message.Message.MessageType + " size: " + message.Message.MessageSize +
" isCompressed: " + message.Message.Compressed + " endianess: " +
message.Message.Endianess);
}

private static void OnError(object sender, QErrorEvent error)
{
Console.Error.WriteLine("Error received via callback: " + error.Cause.Message);
}
}
}

Chiral is Tyler Durden

EspressoLover


Total Posts: 245
Joined: Jan 2015
 
Posted: 2016-07-25 21:20
Regardless of the approach you take, but particularly so with busy-spinning, you should consider scheduler affinity to pin a process to a single core. The latency reduction can be pretty substantial.

https://news.ycombinator.com/item?id=4893866

indiosmo


Total Posts: 9
Joined: Jun 2011
 
Posted: 2016-07-25 22:43
Oh, I assumed you were talking about reading from the network.
I'm not familiar with kdb or it's API so I won't comment on that.

But generally if latency is your main goal there are a few things to consider:
1. Keep things in cache to avoid costly trips to main memory
2. Avoid copying data around and allocating/freeing stuff, try to preallocate everything you need and just use pointers or references
3. Avoid synchronization overhead, try to keep the entire critical path in a single thread

Obviously this is not suited for every scenario and you usually have to design for this from the start, but if you can get your data from I/O to the final consumer without any queues in the way, that'll get you the least possible latency.

If you absolutely must use queues then try searching for wait/lock-free structures in you language. You can then have your consumer thread spin on dequeue() or whatever the function is called. Other waiting strategies can be considered depending on your demands, e.g. you can spin for a few miliseconds then yield or something like that.

Facebook's folly library has a nice single producer/single consumer lock-free queue in C++.
They also have a multi producer/multi consumer non-blocking queue but I haven't checked it out yet.

And yes, affinities and priorities make a big difference.

Check out Martin Thompson's blog, or really just about everything he wrote regarding performance sensitive applications.

mechanical-sympathy.blogspot.com


Nonius
Founding Member
Nonius Unbound
Total Posts: 12699
Joined: Mar 2004
 
Posted: 2016-07-26 00:44
thanks guys. the qSharp looks sort of sugar syntactic to me. I'll roll with it tomorrow and see how it goes.

if it doesn't I'll look at your alternatives.

Chiral is Tyler Durden

Nonius
Founding Member
Nonius Unbound
Total Posts: 12699
Joined: Mar 2004
 
Posted: 2016-07-26 14:07
qSharp seems to work reasonably well

Chiral is Tyler Durden

TonyC
Nuclear Energy Trader

Total Posts: 1245
Joined: May 2004
 
Posted: 2016-07-28 05:04
take it from an APLer, if your using kdb/q, pick up a book called "q tips" by Psaris ... and "q for mortals" by Borror

flaneur/boulevardier/remittance man/energy trader

TonyC
Nuclear Energy Trader

Total Posts: 1245
Joined: May 2004
 
Posted: 2016-07-28 05:05
take it from an APLer, if your using kdb/q, pick up a book called "q tips" by Psaris ... and "q for mortals" by Borror

flaneur/boulevardier/remittance man/energy trader

jslade


Total Posts: 1097
Joined: Feb 2007
 
Posted: 2016-07-29 01:12
If Nonius was using q before talking to me, I would have to fly out to London and issue a noogie.

qSharp is an IPC framework though; no relation to the APL awesome-sauce.

If you need a non-blocking socket, http://liblfds.org is pretty good.

"Learning, n. The kind of ignorance distinguishing the studious."

Nonius
Founding Member
Nonius Unbound
Total Posts: 12699
Joined: Mar 2004
 
Posted: 2016-07-29 05:03
hey jslade! apologies I ain't using it! promise!

the guy sending me some messages might be. Ok, I'll reach out to him.

thanks for the nonblocking socket link.

Chiral is Tyler Durden

ast4


Total Posts: 390
Joined: Aug 2007
 
Posted: 2016-08-14 17:12
A bit slow to the party, but what exactly are you trying to solve? Are you running single strategy/config process because you're very sensitive to latency? Or are you running multi strategy/config out of a single process and only somewhat latency sensitive? etc..

Another poster pointed this out, which I agree with - the definition of 'better' is largely problem dependent. For example, in the second example I gave, you may run into issues if you're doing spin and processing all book events as a flood of events comes in.

Since someone else mentioned core pinning. You can also look into setting the scheduling policy (http://man7.org/linux/man-pages/man2/sched_setscheduler.2.html) and priority (http://man7.org/linux/man-pages/man2/setpriority.2.html).

"Mathematicians are machines for turning coffee into theorems!"

liblfds-admin


Total Posts: 1
Joined: Aug 2016
 
Posted: 2016-08-21 19:39
> If you need a non-blocking socket, http://liblfds.org is pretty
> good.

Hi. I am the author of liblfds.

There are no socket APIs in the library. I may be wrong, but I think you may mean a queue?

The library as of version 7.1.0 contains the "standard" M&S queue for many/many/unbounded, but the performance of that queue is poor (better than all locking queues using the same design, but still, poor; and be aware that if all threads are on the same physical core, the M&S queue will always be slower than locking queues).

There is a bounded/many/many queue, but it is not lock-free; there is a very small window where locking can occur. There is also no benchmark, so there are no hard figures for performance. I expect it to be about three times faster than the M&S queue, but I could be completely wrong.

There is bounded/single/single queue, which is memory barrier only, and so goes like the blazes - no benchmark yet, but I expect ten million plus operations per second. The problem is bounding.

7.2.0 - not yet released - contains an unbounded/single/single, which should fulfill that particular niche well.

netmonk


Total Posts: 1
Joined: Jun 2015
 
Posted: 2016-09-14 11:58
Not only pinning process to one core is required, also isolating this specific core (and may be others) from the scheduler (isolcpu) to avoid other process to run on this specific core.
You can also avoid the kernel tick which introduce huge jitter (tickless mode).
You can also pine network interruption on specific core if you are not doing kernel bypass. With good care of wich core you bind them to have efficient cache communication with kernel and process.

Then you can tweak sysctl, tcp/udp queue size, steering... vmstat.interval.

Non blocking socket, infinite pooling.

If you are interested and i see some java here, you can join the "mechanical sympathy" google groups for very good technical talks about low latency and "high freaks" especially for Java

(im not using java btw).

Regards
Previous Thread :: Next Thread 
Page 1 of 1