Apology accepted. WarEagle was spot on. You've taken your latency issues as far as you need to if you are manual trading. As long as your connection is reliable I would not worry about connectivity anymore.
I didnt really think that far into the fact that im not truly scalp trading. Im simply taking short term trading to the extreme whether thats 2 or 3 ticks, all the while using limit orders for both entries and exits. How fast the order gets to the exchange isn't as important as if I was placing market orders. Im headed of to Panama for 7 days, but I'm excited to get started with the live account as soon as I get back!
I am NOT trying to ruffle feathers here, but in order to minimize your latency, use a Linux/UNIX front end and make sure that you are trading through a Linux/UNIX back end that is near to the exchange you want to trade through. You may also be able to use a "type" of trade to make your latency even lower, e.g. something like a "stop-limit" where the event that causes the trade execution to trigger does not have to go back to your machine, wait for your response, go back to the back end and out to the exchange. In the stop limit case above it would be: trigger goes off, trade sent to exchange...wait for execution report The thing about YOU not being in the execution loop is fairly important. IIRC, human response is like 0.750 seconds....750 miliseconds...a lot when trading against machines (algorithms). -gastropod
unfortunately papertrading or sim does not match real life. If I get filled on a buy at the bid in sim or paper does not mean I would get filled in real life trading.
This is an old thread, but Stillstanding's response above is critical to understand if you are going to use a simulator platform to evaluate trading methods. Even the best platforms will usually give unrealistic fills. For example, let's say time and sales is used to trigger a simulated fill of a limit order. It could be that all that would have to happen to get the fill is that a trade would have to print at your limit price. But the print could be because of a market order that in real trading takes precedence over a limit order. A more realistic way to fill the simulated trade would be to fill it when the quoted ask equals the limit price for a buy, or the quoted bid equals the limit for a sell. But the best, most realistic and conservative way to trigger a fill in simulated trading would be to only trigger a fill if the price trades through the limit price, because in real trading that is the only event that guarantees a fill (or should anyway). Unfortunately, i don't know of any simulator platforms that don't give unrealistic fills or allow the user to easily specify what event will trigger a fill for a particular order type. The Thinkorswim paper trade platform, for example, seems to fill a limit buy order when the bid reaches the limit price, and a limit sell order when the offer reaches the limit price -- just the opposite of the way it should work. It is very easy to make lots of money on paper scalping on such a platform, especially if you ignore commissions. I don't know why trade simulators so often have this defect of giving unrealistic fills, but my guess is that brokers want to hook neophytes by making it seem easy to make money. As Arthur Levitt said in his book: "Take on the Street", "Your Broker is not Your Friend."
The question is not retarded at all - on fast-moving stocks, the brain-finger lag is often your biggest enemy, particularly given that there are programs that do not suffer from this that will be competing with you for fills. If you assume your data already might have a 1/4 second lag, adding another 1/4 second (which it could easily be for many trades when you are waiting to pull trigger, finger ready) is a *big* deal.