Why is it that ALL brokers do not understand true latency?

Discussion in 'Order Execution' started by sigsegvboogman, Dec 17, 2005.

  1. You know what really drives me crazy: Brokers think they understand the term “Low Latency”. I have been trading algorithmic strategies now for over 5 years. We were doing this before it became “hot” on the street. Through that experience, we have learned so many things that have helped us survive all of these years and make money consistently.

    What bothers me so much is that every damn broker we end up trading with has the same speech and pitch. It usually goes: We have the best this and that, best collocations, feed lines, api’s customer service blah blah blah blah. They obviously want your business, so they are going to do whatever it takes to get it. The funny thing is: Most of them believe what they say because it is all that they know. Some brokers are large and because of this, think they are the best. They have the money to buy the technology and hire the programmers to build the “lighting fast” API’s. The trouble is that they have no way of identifying what is TRULY considered “fast”. They assume they have it and that’s good enough. In their world: “It’s the best”. That goes for feeds as well: “We have direct fiber pipes” and we are at Harborside..blah blah blah. (Do I sound frustrated?)

    The truth is that none of these guys look deeper into real latencies. Sorry, but a ping time doesn’t cut it. Most high speed customers do not complain if they feel the executions and service are adequate. Because of that, the brokers “don’t fix what isn’t broken”. Well, what about the few that do complain? What does it take to prove them wrong? And if you do prove them wrong, what does it take to make a difference and have them take action? My experience has almost always been that even once proven, they rarely take action.

    Five and a half years ago, we were with a “broker” and co-located at their facilities. Back then, we were just learning about latencies. We found some outside of our own systems and pointed it out. The broker took no action. Later, they were bought out by another firm. We later found latencies within that firms api/network/hardware. They were unwilling to even look at any issues. We ended up leaving and going to a bigger firm: Had the same issues there. After a year and a half with that “firm” we left out of frustration to another broker. For the first time, this new broker started listening. We were happy. Through that experience, they became a much better shop with regards to execution, low latency and all of that. Well, that firm is now a new firm. This “new” firm which has so much “experience” basically has us in the same position as we have been for years and years. They talk about how good they are, they throw numbers at us and based on what our options are, we go with it. Well, the end result is always as it is: They are slower than what their full potential could be. The problem is that the people who run all of these firms think their version of “fast” is fast enough. I am now at the point where I have pointed out latencies we uncovered on their end, but they seem gun shy to even consider any as an issue. Bottom line: The faster a broker is head to tail, the more money their clients will make the more volume the broker will do and new clients will migrate to whoever is fastest. It’s simple.

    So out of frustration of not being “heard” at my broker, I started the search once again to find a new “broker” to suit my needs. And here we are in 2005: The same speech, the same stories, the same claims. Here’s an example: I have been talking to a large well known broker (which I will not name, nor will I name any in this story) on the street. They basically made all of the same claims. They bet that they could beat anything I had on my end as far as speed and all of that. I asked them to run tools that we have built which measure true latency. These tools basically have kept us in business for all of these years. They ran them on their main servers and gave me the results. I wanted to go with this approach rather than spend months of development time fusing to their api and finding out first hand they were wrong. Well, BINGO I proved them wrong again. My systems were about 900% faster than anything they had from execution servers to feed distribution servers with regards to latency. What this means in my world: They are the automatic bottleneck. All it is here is the same story over and over. And the beauty of all of this is that NONE of them know how to fix that issue. They never thought of digging that deep! Same old story, “We are the best and fastest”.

    You know what I wish? I wish I was big enough to help build a real automated trading brokerage firm. With all of the first hand knowledge we have from the years of experience and not overlooking the smallest of variables, it would be the fastest anyone has ever seen. It would change the landscape. What’s funny is that if any of these brokers actually listened and implemented some ideas pointed out, they would be there now. I never claimed to know everything, but I do understand true latency. Sorry guys, I had to vent for the first time.
     
  2. mokwit

    mokwit

    At a lower level than the one you operate in a major cause of latency is the bottleneck from undercapacity in the brokers servers that check client margin before executing. Not ping, not lines to exchange, just plain old undercapacity/inadequate spec. Add this on top of exchange matching engine also lagging in high volume and you have a very noticeable delay.
     
  3. But you can design so that this function in the api is at a latency where it doesn't get in the way. Not even under heavy loads and many clients. But they don't. They just "think" they have and it's "good enough".
     
  4. mokwit

    mokwit

    I thinky you are operating at a higher level than me on this. When I encountered it, it was just that the MD would not authorise the expenditure for additional capacity.
     
  5. mokwit

    mokwit

    Out of curiousity is this the "true latency" you were describing or were you referring to something else?
     
  6. mindfull

    mindfull

    Perhaps you can enumerate all these latencies you are referring to?

    Also if your knowledge of latencies 'can change the broking landscape' you have something which venture capitalists would be interested in.
     
  7. either that or start your own brokerage firm
    to your ideal specs ... and then get business
    from customers who want or need this in their
    trading

    :)
     
  8. All I am saying is that I have seen so many firms build up their technology, create a good trading platform, get the best lines, best colo's, full back office software that does everything smooth and an API that is fast, but could be much much faster. Beyond the API issues that go unnoticed, the feed side of their technology is something that is usually not approached beyond simply purchasing "best" lines and "best" routers/switches. They get the goods and think that's all they need. Never fail, everytime I have to deal with someone new, they all have the same issues. And EVERY time you have a conference call or a meeting and we present all of the places where latencies exist and why, they are always caught off guard. You get that "really?" response. The problem is that you are only one voice. Most firms are afraid of hearing one voice over the crowd. They are afraid of doing something that they think could "disrupt" business when everything seems already to be going smooth. In my opinion, that excuse is used because none of these guys get it and there really isn't anyone out there that can direct a programmer to find these points of latency because they never knew to look in the first place. They get their execution reports back when they test their API's and simply believe their time for data passing through the API is fast enough. They can't understand finer resolutions beyond that point because "nobody needs that".

    Then there is another barrier that is tough to get through: Most programmers and owners who designed the API software and/ or designed the network in which you run on have an arrogance about them. They are proud of their work and believe that nobody can make it better than they. Granted that alot of these things are fast and efficient, never fail there are always 4-10 very important areas that they always overlook and could make the systems so so so much better.

    Changing the landscape? Absolutely. In my mind, if one broker stepped up to the plate and listened, they would be faster than everyone else hands down. If you are a hedge fund that makes more money with your algorithms because the faster you get the data FROM the market, decide what to do with it and execute it back into the market, your truly going to make more money and trade more volume. The end result to this is that all of your competitors will start getting their lunch eaten, have lower profits to customers and critical mass would move to wherever the speed and ultimately money was.
     
  9. Venture capitalists? I wish they would listen. I know that my group could take care of the latency end better than anyone else. The rest, that's someone elses expertise. But there we go again. Who listens?
     
  10. Why is it that ALL brokers do not understand true lattency?

    They are not ambitious.
    They feel no need to understand as long as they are in profit.
    They don't have incorporated in their business the capitalism ideal.

    They are always in profit because dingbat traders outnumber serious traders.
    Their short sight is 'earthquaked' only when competitors take their market share.

    Will it then be too late? No, they sell their business for a larger profit.
    :D
     
    #10     Dec 17, 2005