• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:

  • You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
  • You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
  • If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.

Previously on "Technology stack for a high freq low lat trading system"

Collapse

  • bilgehan
    replied
    Originally posted by pacontracting View Post
    So - a typical stack in this case may be Java, layered on Linux. The GUI may be an apache hosted website on the same box). Get some decent hardware like HP Proliant or similar. The expense of low latency network cards and switches may not be required and look what's upstream and downstream from your proposed environment e.g. do you have internal risk system that need to be consulted before you can make a trade.

    So to summarise - it's not the speed of your part of the whole trade lifecycle that's important; it's the latency on the whole tick to trade journey.
    This is good insight thanks and backs my latest decision.

    BTW sorry for late reply, I just signed a new 1 year contract outside UK (will use C on RTOS and C#), then will come back to UK. As this trading system is a side project I decided to use technologies I use at work. In this case it'll be C#, I decided not to use QT/C++ , don't want to endevour a QT learning process.

    Leave a comment:


  • pacontracting
    replied
    Low Latency Design

    Typically - for low latency - you would want to minimise the time taken from the tick being generated from the exchange to the trade being accepted by the exchange.

    For example - if your new system takes 10 microseconds to process a trade but seconds are wasted getting the tick to your server and then getting the intention to trade onto the exchange, you'll just end up with a large number of non-filled orders.

    The tier-1 investment banks typically have this sewn up using water cooled servers, with custom FPGA network cards, 10GB low latency networks, running custom built software (always Linux and C++) and the best mathematical minds continually refining their automatic trading algorithms. Physical latency is further reduced by hosting these servers in the same building as the exchange matching engines. In other words - for pure low latency - forget it.

    There is obviously a market if you don't want to compete with the 'big boys' and want to look into offering a simple to use product that balances ease of use and perhaps offers something new and you just want to get the trades in as fast as possible within the limitations of your infrastructure.

    In this case, a lot of the tier-1 banks also want to trade on esoteric exchanges or with certain products, but latency isn't the most important issue (low latency rather than ultra low latency). This is where Java wins as it is easy to develop for and absolute speed is not required (perhaps because someone is pushing a button to decide a trade rather than the machine making the decision as in Ultra-Low Latency environments).

    So - a typical stack in this case may be Java, layered on Linux. The GUI may be an apache hosted website on the same box). Get some decent hardware like HP Proliant or similar. The expense of low latency network cards and switches may not be required and look what's upstream and downstream from your proposed environment e.g. do you have internal risk system that need to be consulted before you can make a trade.

    So to summarise - it's not the speed of your part of the whole trade lifecycle that's important; it's the latency on the whole tick to trade journey.

    Leave a comment:


  • SupremeSpod
    replied
    Originally posted by Bunk View Post
    Like double posts?
    It was an accident and if this wasn't the technical area I'd tell you to **** Off, seriously.

    Leave a comment:


  • Bunk
    replied
    Originally posted by SupremeSpod
    If you can afford his rate he does onsite training.

    Well worth considering if you have specific issues.
    Like double posts?

    Leave a comment:


  • SupremeSpod
    replied
    Originally posted by eek View Post
    If you can afford his rate he does onsite training.

    Well worth considering if you have specific issues.

    Leave a comment:


  • Contreras
    replied
    Originally posted by bilgehan View Post
    First problem was to choose between Windows and Linux. I decided to make it crossplatform but open to a single platform solution as well.
    I checked QT for crossplatform GUI development but I think mixing it with boost would be problematic like using QT for UI and using boost threads. Also I have no experience with QT so I don't know whether it'll worth to dive in it.
    Have you looked at wxWidgets (wiki / doc / forums ) ?

    A "thin wrapper" with a common API onto the OS's native widgets, be that MS-Windows, GTK, etc.. Supports multi-threading as well. Doesn't carry the extra baggage of a widget library as QT does, so apps run faster and/or require less resources. Also less restrictive license than QT for commercial use (AFAIK). Disclaimer: I haven't used QT so my assessment is biased.

    Leave a comment:


  • eek
    replied
    This may be of interest to people

    Mechanical Sympathy: Fun with my-Channels Nirvana and Azul Zing

    Leave a comment:


  • squarepeg
    replied
    Erlang?

    Some shops use Erlang.

    Leave a comment:


  • VectraMan
    replied
    Originally posted by SupremeSpod View Post
    Our Java code is Garbage Free, and very low latency.
    Thinking about it some more... doesn't garbage collection still have to stop the world and trace all the references to all the objects to work out what's accessable? So it doesn't matter if you have no garbage, it's still doing the work as if there were. Or is there a way of turning it off completely.

    Leave a comment:


  • doodab
    replied
    Originally posted by d000hg View Post
    [De]Allocing memory all over the shop is bad in C/C++ too, hence C++ apps sometimes do similar things... when you're running this kind of thing you can't even trust the OS to do it right.
    The OS generally doesn't do much more than allow you to ensure a range of addresses is actually backed by something e.g. brk, VirtualAlloc etc, although Windows does offer heaps.

    What most programmers think of as memory management is done by the runtime and will be implemented in different ways by different dev tools and libraries. On solaris for example malloc() can resolve to one of several different implementations at runtime, and the implementation is likely different in different versions of visual studio as well.

    Leave a comment:


  • bilgehan
    replied
    Originally posted by d000hg View Post
    [De]Allocing memory all over the shop is bad in C/C++ too
    Yes it causes memory fragmentation, gave me too much headache in a previous job.

    Leave a comment:


  • SupremeSpod
    replied
    Originally posted by d000hg View Post
    [De]Allocing memory all over the shop is bad in C/C++ too, hence C++ apps sometimes do similar things... when you're running this kind of thing you can't even trust the OS to do it right.
    Never, ever trust the operating system.

    Leave a comment:


  • SupremeSpod
    replied
    Originally posted by VectraMan View Post
    In other words, you're doing your own memory management because the built in system is deficient. May as well have just done it in C++ in the first place ;-).
    Not when your customer wants it in Java.

    Btw, I have developers who do that kind of thing for me now.

    Leave a comment:


  • d000hg
    replied
    [De]Allocing memory all over the shop is bad in C/C++ too, hence C++ apps sometimes do similar things... when you're running this kind of thing you can't even trust the OS to do it right.

    Leave a comment:


  • VectraMan
    replied
    Originally posted by SupremeSpod View Post
    It is a serious reply.

    We have a library of factories that manage pre-allocated objects. When these objects are no longer required they are handed back to the factory where they are "cleaned" for reuse.

    It's a little more complicated than that but you get the general idea.
    In other words, you're doing your own memory management because the built in system is deficient. May as well have just done it in C++ in the first place ;-).

    Leave a comment:

Working...
X