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

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

  1. ".... or you could just accept the fact that this is part of playing the game and figure out an advantageous way (for you) to deal with it. That's what entreprenurialism is all about. Maybe even start your own broker and then let the market decide if it agrees with you."


    No offense, but that's a lousy excuse. Markets have been forced to become more efficient, so should brokers. I have lived exactly like you describe and it is tiresome hearing the same speeches over and over. The brokers now are at the point where they don't believe they need to be better and they clearly can. And the beauty is that anything beyond this point is an end game for them when it comes to latency. They just refuse to understand the world that is out there for the taking.

    Start my own broker? With what? I wish I could. It has always been a dream to be a part of that process and do my part the "right" way.
     
    #31     Dec 18, 2005
  2. I really couldn't care less and anybody using internet connection would be completely wasting their time worrying about it. Neither do I particularly care if RH 7 is running on a streaming price data server and introducing a 1 msec extra delay if indeed that is the case. It is irrelevent if it is two orders of magnitude less than internet propagation delays.

    And by the way Linux is a portable operating system that was never 'optimized' for P3s or Athlon 64s or anything much else. Performance gains in the 2.6 kernels are not particularly related to optimizing for newer CPUs. Using a newer Linux distro than RH7 might improve performance but NOT because it is optimised for newer CPUs.
     
    #32     Dec 18, 2005
  3. I think that this discussion does not apply to any users who trade through the internet. I'm talking about people who need the data and need it fast. I wouldn't be in business if I traded through the internet.

    The RH7 is not introducing a 1 ms delay to the feed servers....it's much more of a delay than that. Much more.
     
    #33     Dec 18, 2005
  4. To clarify one thing: I believe my current broker has a very fast API. I believe it is 95% acceptable to this current market. My past experiences throughout the years have seen slow API's. My current broker just does not seem to understand hardware and the proper operating system to use. Also, how to optimize that hardware/OS so that the performance is incredible while remaining stable. What is so frustrating is that IF they fixed that piece alone from head to tail, I wouldn't be having this discussion. The problem is that it seems to fall on deaf ears after countless meetings and emails.
     
    #34     Dec 18, 2005
  5. #35     Dec 18, 2005
  6. #36     Dec 18, 2005
  7. Well sir,

    That time in the equities market is an eternity. I think the old days with Redi and Arca "Old Fix" engine was 1000% better than those times.

    Execution times in milliseconds is not a waste of time. Maybe for you and your trading, which is fine. Brokers look at a client like yourself and go with that flow unfortunately.

    This is what I mean by people not understanding the deeper level. I'm sure he doesn't because he doesn't have to. Which again, is fine 100% for him.
     
    #37     Dec 18, 2005
  8. The specific tecnnical issues, raised by the author of this thread, are limited to automated, non-internet trading. These specific technical issues are rooted, however, in political-organizational limitations at brokerages, which do have a larger impact beyond the author's specific technical concerns. This larger impact impairs all equities trading, whether automated or not, whether internet or not.

    Here is a specific example. Some securities, like SPY, have so much electronic liquidity (on ECNs and NASDAQ), that specialist execution is always sub-optimal for the trader taking liquidity (as opposed to offering liquidity). Specialist executions can mean delays of 30 seconds, and prices far worse than what could have been achieved by avoiding the specialist. Naive smart-routers will route to the specialist anyway, if the specialist is showing the best price, even though this will produce poor results, because the specialist price is no longer the best price by the time execution occurs. Some brokers have a smart-routing algorithm, which allows the exclusion of NYSE and AMEX as order destinations, so that specialist executions can be avoided, and this is a step in the right direction.

    The optimal solution, however, is offered by no retail broker. The optimal solution is to include NYSE or AMEX in the smart-router's list of possible destinations, but ONLY when the particular exchange guarantees immediate automatic execution at the NBBO, instead of manual specialist execution. So sometimes NYSE or AMEX are in the smart-router, and sometimes they are not. The smart-router can easily determine when to include an exchange, and when not to exclude an exchange, because a set of simple rules allows a program to determine, automatically, whether or not each exchange is providing immediate auto-ex at any point in time.

    But no broker provides this capability. My efforts to change this situation have gotten nowhere.

    And by the way, I resent Nitro dismissing this thread as silliness. I think it is the mark of arrogance to dismiss, as silly, that which one doesn't understand. I think we all profit when we try to understand other viewpoints, even if they might be wrong, rather than belittle other viewpoints.
     
    #38     Dec 18, 2005
  9. I am looking for a broker with negative latency. Feel free to offer names and numbers.


    And as for routing something like SPY to the specs. Yes, they fill slow. But the blanket assumption of a 'bad' fill is not proven. You might get filled at a better price than the ECN's if you are early to the spec while the mkt is moving in your direction.
     
    #39     Dec 18, 2005
  10. Please tell us what strategy suffers measurably from this 1 ms delay.
     
    #40     Dec 18, 2005