The smallest firm that could truly do away with these latencies would win critical mass in the area of high speed. This is because once clients started loosing money, or not "making" as much as they used to", they would hunt for the best again. The larger firms have the ability to do this, but they just have to first admit they have issues that could be fixed with minimal effort. That's unfortunately the hardest part. Nobody listens.
Why is it that ALL brokers do not understand true latency?
- Thread starter sigsegvboogman
- Start date
Sig.,
I think the the points that you make are valid and the probs you experience are legit. I think the thing is the situation you are identifying is a classic example of industry and 'big money'. Truth is brokers and providers loath change. They like to think that they can get away with having something that is perceived marginally better than the next guy and then basically put it over on everyone that "we are the best". Besides that there is always all kinds of external forces and factors acting upon the issue that you are identifying and while your complaints seem justified they often fall on deaf ears.
Case in point, wouldn't you think that an auto manufacturer would be driven to produce a vehicle that had triple the fuel economy of every other competitors'? And wouldn't it seem obvious that this manufacturer would gain huge market share as a result of offering this 'uniqueness' in their vehicles? Reality is that it just hasn't happened, and it probably is possible in fact maybe even very achievable. But there are so many exogenous factors impacting the issue that it doesn't happen. I think too that the bigger the guys you deal with the less likely that you will be to impact real change even thought they are the one's with the resources to make the changes.
Anyways I feel your pain brother, and just remember, the longer the search to find your solution the more likely it is that it will be a real and sustainable edge. I mean honestly do we really want everyone to have access to the same advantages? Remember this is competition for $$$ not something for the greater good of the society like a cure for cancer.
Cheers,
AM
I think the the points that you make are valid and the probs you experience are legit. I think the thing is the situation you are identifying is a classic example of industry and 'big money'. Truth is brokers and providers loath change. They like to think that they can get away with having something that is perceived marginally better than the next guy and then basically put it over on everyone that "we are the best". Besides that there is always all kinds of external forces and factors acting upon the issue that you are identifying and while your complaints seem justified they often fall on deaf ears.
Case in point, wouldn't you think that an auto manufacturer would be driven to produce a vehicle that had triple the fuel economy of every other competitors'? And wouldn't it seem obvious that this manufacturer would gain huge market share as a result of offering this 'uniqueness' in their vehicles? Reality is that it just hasn't happened, and it probably is possible in fact maybe even very achievable. But there are so many exogenous factors impacting the issue that it doesn't happen. I think too that the bigger the guys you deal with the less likely that you will be to impact real change even thought they are the one's with the resources to make the changes.
Anyways I feel your pain brother, and just remember, the longer the search to find your solution the more likely it is that it will be a real and sustainable edge. I mean honestly do we really want everyone to have access to the same advantages? Remember this is competition for $$$ not something for the greater good of the society like a cure for cancer.
Cheers,
AM
Good post and I agree. I just believe that if someone stepped up to the plate and broke the mold of this industry, others will only have to follow in order to survive. I wants latency issues to be in MY lap and up to ME to figure out because nothing else is in my way except myself.
Here is an example: This week, we found a latency with a very well known broker that we trade with (again, I respect them enough to not give names). They have probably one of the best customer service ends I have ever seen. Their API is fast, but could be faster and very easily done so. We uncovered that the feed server we were getting one of our ECN feeds from was running Red Hat 7.3 i686 2.4.20 kernel. Now folks, when was Red Hat 7.3 released? Ah, 4 years ago? AND i686 basically means that they are running this OS in a very generic fashion so that it could easily run on a Pentium 3 to Xeon. The OS is not optimized for the hardware it is using. To boot: For an OS to be 4 years old ONLY means that the hardware it runs on is 4 years old!
We had an old version of 7.3 kicking around the office from the old days when we used to run deathly slow "Red Hat". For giggles, we installed it on an old machine (that was considered fast) and mimicked what we knew of their setup. The latencies produced were just as we remember. It reminded us as to why we ran from Red Hat to begin with.
So lets look at the outcome of running Red Hat 7.3 i686 in a live setting for an ECN feed distribution: The data comes from the ECN, the time you get that data and any quote revisions is lagged severely by this box. Thus, your decision making with your algorithms is done THAT amount of latency slower. But you never know this because you only focus on EXECUTION data from the API. This issue is all pre. Now simply going faster hardware and better OS will not solve this issue at all: You have to know what to do with it.
Here is an example: This week, we found a latency with a very well known broker that we trade with (again, I respect them enough to not give names). They have probably one of the best customer service ends I have ever seen. Their API is fast, but could be faster and very easily done so. We uncovered that the feed server we were getting one of our ECN feeds from was running Red Hat 7.3 i686 2.4.20 kernel. Now folks, when was Red Hat 7.3 released? Ah, 4 years ago? AND i686 basically means that they are running this OS in a very generic fashion so that it could easily run on a Pentium 3 to Xeon. The OS is not optimized for the hardware it is using. To boot: For an OS to be 4 years old ONLY means that the hardware it runs on is 4 years old!
We had an old version of 7.3 kicking around the office from the old days when we used to run deathly slow "Red Hat". For giggles, we installed it on an old machine (that was considered fast) and mimicked what we knew of their setup. The latencies produced were just as we remember. It reminded us as to why we ran from Red Hat to begin with.
So lets look at the outcome of running Red Hat 7.3 i686 in a live setting for an ECN feed distribution: The data comes from the ECN, the time you get that data and any quote revisions is lagged severely by this box. Thus, your decision making with your algorithms is done THAT amount of latency slower. But you never know this because you only focus on EXECUTION data from the API. This issue is all pre. Now simply going faster hardware and better OS will not solve this issue at all: You have to know what to do with it.
Let me add to that last post: Hundreds of clients that are automated hook to that server right now. All are blind to the truth. Pretty eye opening huh?
From a dingbat trader 
If I were to start my own brokerage, I would give ol' sigsegv a chance!
Michael B.
If I were to start my own brokerage, I would give ol' sigsegv a chance!
Michael B.
To address the earlier post related to a firm not authorizing addition capacity: Usually capacity is not the issue. The issues usually resides around what people do with what they have to work with. The answer is usually what they consider "best" performance. It's 99.9% crap. Brokers: Step up to the plate.
I have observed similar issues in the area of order execution and order routing algorithms. The very best retail brokers, in this area, don't do nearly as well as they could, if they would just make some reasonable improvements to their execution logic. Broker programmers are too arrogant to listen to traders on this subject. Well-meaning executives rely on the programmers who report to them. Customers don't take the time to investigate the issues, so they don't demand anything better than mediocrity in this area. If you really take the time to do your homework, and you try to bring things to the attention of your broker, then they chant the mantra, "But you are the only one complaining." I think that there is always a battle, both between brokerages, and within brokerages, and that this battle is waged between the small-numbered minority who understand and who strive for QUALITY, on the one hand, and the small-minded majority who are so content with MEDIOCRITY, that they don't even realize, and don't even want to realize, that they could choose something better.
Is it better to buy a pair a shoes every month at payless...or a pair of good shoes once a year?
Payless shoes can work just fine if you know how to walk in them correctly.
JimRockford,
I agree with you 100%. To boot: Most programmers do not dare (nor do they know how) to achieve these performance results. In some cases, they are afraid of sticking their necks out there just in case it fails and its their head on a platter. They are with firms that are solid, so they are almost guaranteed a paycheck if they produce. Imagine what they would do if they were at constant risk of loosing their jobs because they were not fast enough? We used to be in that boat. Now imagine the results based on that outlook: You all do something you truly love to do and are passionate about. If you are not fast enough, you die. What would you do? How would you perform? Would you only think about your job ONLY when you were on the clock? Or would it have a deeper meaning? Would you uncover everything and anything you could on a deeper level? That's where we came from: No arrogance, just simply survival. But again, do the big guns or ANY gun listen? No way. BROKERS: STEP UP TO THE PLATE!
I agree with you 100%. To boot: Most programmers do not dare (nor do they know how) to achieve these performance results. In some cases, they are afraid of sticking their necks out there just in case it fails and its their head on a platter. They are with firms that are solid, so they are almost guaranteed a paycheck if they produce. Imagine what they would do if they were at constant risk of loosing their jobs because they were not fast enough? We used to be in that boat. Now imagine the results based on that outlook: You all do something you truly love to do and are passionate about. If you are not fast enough, you die. What would you do? How would you perform? Would you only think about your job ONLY when you were on the clock? Or would it have a deeper meaning? Would you uncover everything and anything you could on a deeper level? That's where we came from: No arrogance, just simply survival. But again, do the big guns or ANY gun listen? No way. BROKERS: STEP UP TO THE PLATE!