I remember the time when market orders where filled instantly. Now it is usually 10 seconds or even more, and I get 2-3 ticks worse fills then when I pushed the Place Order button.
I understand that there are more users, so here is my solution:
The fill would be with the timestamp of the Order button pushed, rather then when the trade actually executed after spending time in the queue. So the confirmation could be still slow, but at least the fill would be where the market was when the Place Order was given…
Except that it’s stamped/filled about the same time the order is sent to autotrading clients.
Doing as you suggest would greatly exaggerate hypothetical versus real-world results.
Quite frankly if your strategy is dependent on sub-12 second execution times, it’s not suitable for trading on C2.
I agree completely. I would rather suggest to do the opposite, i.e. add another 10 seconds to it.
But perhaps it depends on how one views the purpose of C2? If the vendors only interest is to build a track record - and not to have subscribers - then I can understand that he wants specific C2-related delays removed from it. If the vendors interest is to provide (auto)trading service for subscribers, then even posing the question is a bad sign of his understanding of the problems that subscribers often have.
"Then, after the trial, subscriptions cost $100 per month."
Seems like he is going for the subscribers.
I’m wondering if it would be possible for systems where execution speed is really an issue, to receive the signal directly from the vendor (bypassing the C2 server). To put it very simple: What if the vendor has access to the folder on my PC from which TradeBullet picks up the orders. All that is necessary is a little application (licensed through C2) running on both machines, that guarantees a secure connection. I.e. the vendor does not have access to any other parts of my PC and nobody other than the vendor has access to my PC. It’s somewhat similar to peer-to-peer software. Note, I’m not an expert in these things, and this is just a random thought, so it might not be feasible at all, or perhaps very unsafe.
- I think the delay is caused by the additional stats, not by the number of users. In the past there were more users and it was instant fill.
2. It also delays limit orders, it takes 10+ seconds for a limitorder to go live.
3. If C2 wants to be realistic, marketorders should fill fast. Again, I can do with 2-3 secs delay, but come on, 12 or more seconds? Would you stay with your broker if they provided you with that speed?
4. I assume it doesn’t just delay the execution but also the signal out to the subscribers. A little loss here, a little loss of time there…It adds up.
5. If someone wants to just test a strategy, he can not realisticly do so…
- The number of users of your system may have decreased, but I believe the total number of C2 users increased.
4. Indeed, and since I and many others want to know which fills a subscriber gets, the delay should be part of the fills that C2 reports.
5. On the contrary, assuming that there is no delay would not be realistic.
I bet you would run into legal problems. For peer-to-peer signals to work, the vendor should know my position size and trading scale, and adjust his signal accordingly. That would turn his signals into personalized trading advice. It would also be hard to distinguish this situation from a managed account. But I’m not a lawyer.
Again, I can do with 2-3 secs delay, but come on, 12 or more seconds?
Keep in mind that for auto traders, TradeBullet polls the C2 server at certain intervals for new signals. These intervals are almost certainly larger than 2-3 secs. Probably more like 7-10 secs. I think the ITM window refreshes at even lower rates.
>I would rather suggest to do the opposite, i.e. add another 10 seconds to it.
Hey, that is a fantastic idea!! Genius! I could also suggest, that we could use 15 mins delayed quotes, that could save a few bucks for Matthew!!
Here is a simple poll: If your broker does 12 secs market order fills, rise your hand!
On the serious side:
>Keep in mind that for auto traders, TradeBullet polls the C2 server at certain intervals for new signals.Probably more like 7-10 secs.
Actually, this would be nice to know just how much time lapses between giving the signal and executing a real order on the subscriber side. I assume about 30 secs. Now if we could cut down a 12 secs part of it, sure everybody would be happier.
Again, this is a rather new problem, a few months back I got the same fill what I saw on my ticker. One solution could be to run the stats part of the software only in every 15-30 mins.
I’m dead serious. You seem to have a problem to understand the subscribers point of view, or you don’t remember what you suggested yourself. This is what you suggested:
"The fill would be with the timestamp of the Order button pushed, rather then when the trade actually executed after spending time in the queue."
Consider an example:
- you push the order button at 10:00:00
- C2 transmits the signal at 10:00:12
- the subscribers are filled on average at 10:00:30, but certainly not before 10:00:12.
Currently, as you say, the fills of your C2 track record will be based on 10:00:12, and you suggested that the fills should be based on 10:00:00. Frankly, that is ridiculous. If you have so little interest in your subscribers results you shouldn’t be selling a system here in the first place.
"One solution could be to run the stats part of the software only in every 15-30 mins."
I doubt that the delays are caused by the stats part of the software. I believe that they are updated only overnight. But if I am mistaken then I agree that it would be enough to run the stats only overnight.
I didn’t advocate the subscribers getting a delayed fill but the vendor getting an instant. In a perfect world both would be close in time. I am not sure how the software works, how the 12 secs delay gets in the line of the subscribers. Is it possible that a trade actually gets signaled faster to subscribers than filled? I don’t know. Well, I am going to do a few tests on my own next week.
What I know is that a few months ago everything was faster, and I want that back! 
"I didn’t advocate the subscribers getting a delayed fill but the vendor getting an instant."
I know; neither did I advocate delayed fills for the subscriber. My point is: if the fills of the subscribers are delayed, then the fill of the vendor should have the same delay.
"Is it possible that a trade actually gets signaled faster to subscribers than filled?"
If that happens, you will have a point.
Matthew probably did something, because suddenly I am getting almost instant fills. Not this morning, but after 11:30 or so…
Where was this when the market went 8-10 ticks by the time the order got filled yesterday?
So far I have only made incremental improvements. As I said in an earlier post, we will be transitioning soon to a newer, much faster hardware and database architecture which should improve site speed dramatically. It’s still weeks away, though. I’ll keep you posted on our progress.
In the meantime, I will continue making tweaks to wring any modest speed improvements I can out of our existing infrastructure, while we await the new hardware.
Matthew
Today is slow again, 20-30 secs market order fills. The whole website is slow too. Can’t we turn off the stats in fastmoving markets? Or let them run only once an hour…
Actually statistics-generation does indeed hibernate when the site is overloaded.
Really, the only solution to fix the slowness of C2 is to add more hardware and money to the site. I am doing this now. I hope to unveil a much faster site in the near future. Please bear with us as we undergo these growing pains.
I promise to keep you all informed about the progress of this very important project. As of right now, I have no definitive date when the project will be complete, but it is top priority.
Thanks Matt, I won’t mention it again…
