Tixwiz 

Are there any profitable traders out there who use AMP and regularly withdraw funds? Could you please comment on your experiences with them, if withdrawals are paid and paid promptly, or if you have encountered any problems?

I've been using AMP something about 8 years now without a single glitch. So there should be no problems.

Kiks 

Just so you know, I am just doing scalping and not HFT. Metatrader is not the right platform for HFT. After hearing from Andriy (andrico), I started looking into R|API in order to speed things up. Metatrader may not be good for scalping. If only there is another broker with a better implementation of metatrader, I do not have to give up my metatrader programs. Thanks, Kiks

I am not familar with the Metatrader but I quess those timestamps are from your computer not from the AMP platform right ?

In windows you cannot get guaranteed execution times. It depends so much what the operating system is doing at the given moment. This is why I do my algos in special version of colocated Linux (direct access to NIC in dedicated core and h/w with no NMIs). IMO Rithmic is a good choice for Lx.

To get the fastest execution the clearing process is the problem (broker is checking your margins etc.) so this is why Rithmic has it's R | Diamond API™ where you can clear your trade in advance and when it's time for execution you only need to send a short execution signal to make things happen.

But to get the fastest executions use allways the native order types. These kind of orders cannot be beaten by other external computing systems no matter how fast and colocated they are (ie. expensive) because you allready are in the matching engine queue.

Yes you may know all of this stuff but I put it here so others will know.

Scalpguy 

I am not familar with the Metatrader but I quess those timestamps are from your computer not from the AMP platform right ? In windows you cannot get guaranteed execution times. It depends so much what the operating system is doing at the given moment. This is why I do my algos in special version of Linux, colocated. IMO Rithmic is a good choice for Lx. To get the fastest execution the clearing process is the problem (broker is checking your margins etc.) so this is why Rithmic has it's R | Diamond API™ where you can clear your trade in advance and when it's time for execution you only need send a execution signal make things happen.

Thank you for looking at this.

Those timestamps were from metatrader server.
After I sent my order, my Windows OS just sits there while AMP & CQG do their thing.
My program's job is done at line 1 of that image.
The rest is up to them. And the "rest is up to them" part took more than 240 ms.
Every step in that route is being reported by AMP as shown in the attachment.
Those are system generated messages. My program had nothing to do with those messages.
AMP already cleared the order and it took them 4 ms.
AMP holding the order for another 240 ms before they send it to CQG is really my concern.

With the platform you are using, how long does it take for your order to get filled?
Do you know where your order is at any moment as it travels to CME then back?
How long after AMP clears your order before it sends it to CQG?

I am just trying to understand this because even if I use Rithmic API, AMP will be the bottleneck.

I do asynchronous order sending. My software does not wait for confirmation. Because I know with market limit order, my order will be one of the first in line in the limit order book.

If my order is still in the LOB and the price moves 2 ticks away, my program cancels the order.
I'll have 200+ trades during RTH and one or 20 missed trades are okay.

Kiks 

Thank you for looking at this. Those timestamps were from metatrader server. After I sent my order, my Windows OS just sits there while AMP & CQG do their thing. My program's job is done at line 1 of that image.

So it's the Metatrader/Windows server who is generating those timestamps. RIght ?

Those timestamps are not real timestamps occured on AMP/CQG platform they are timestamps when your server received the messages from the platform. So you cannot be sure who is making the delay but I would bet it's your Metatrader Windows Server.

Or am I missing somehting important in this scenario ?!

Scalpguy 

So it's the Metatrader/Windows server who is generating those timestamps. RIght ? Those timestamps are not real timestamps occured on AMP/CQG platform they are timestamps when your server received the messages from the platform. So you cannot be sure who is making the delay but I would bet it's your Metatrader Windows Server. Or am I missing somehting important in this scenario ?!

If I am running on demo account, the whole process would be done in 3 ms. Not in over 245 ms as is happening when running with a live account. Really huge difference in processing time.

It cannot be the client side, Windows and my program, doing the delay. The program runs less than 1 ms from tick arrival to issuance of an order.
The trip from client to server over the internet is < 1 ms.
It is the time spent outside the Windows box that is really taking a long time.
In that 245 ms delay, my program could have sent 1 contract 245 times asynchronously.

I think I have a clue now why some scalpers are into direct market access.

Kiks 

If I am running on demo account, the whole process would be done in 3 ms. Not in over 245 ms as is happening when running with a live account. Really huge difference in processing time. It cannot be the client side, Windows and my program, doing the delay. The program runs less than 1 ms from tick arrival to issuance of an order. The trip from client to server over the internet is < 1 ms. It is the time spent outside the Windows box that is really taking a long time. In that 245 ms delay, my program could have sent 1 contract 245 times asynchronously. I think I have a clue now why some scalpers are into direct market access.

You cannot trust timestamps generated by the client server.

btw. Demo and Live systems are often very different environment.

Rithmic platform is able to give you the timestamps generated on the platform so you can trust them quite well. With AMP and Linux you can get easily 5 ms tick-to-trade (in 1ms connection) and If you can use dedicated h/w where you have tweaked the kernel and using for example Diamond you will go sub ms without direct connections.

I do not have any massive research in this topic but the setup has been working very well for me.

Good luck with your journey.

Scalpguy 

You cannot trust timestamps generated by the client server.

I am the client. AMP is the server.
How can I not trust the message from the server? Do you mean 245 ms is not really 245 ms?

Scalpguy 

Rithmic platform is able to give you the timestamps generated on the platform so you can trust them quite well.

Can you share a screen snapshot of Rithmic's timestamps?
Does it show all the stages of where your order is during its trip from desktop to AMP/CQG then back?

Anyway, I just got my Rithmic API credentials. Thanks to @mattz for helping out.

Thanks for your help.

Kiks

Kiks 

I am the client. AMP is the server. How can I not trust the message from the server? Do you mean 245 ms is not really 245 ms?

Yes. It's a question of NMIs and other events overriding your process who is generating those timestamps. You're handling timestamps which are very different what happens on the platform. Specially if you're using a Windows. VPS is a problematic environment too. Unfornately this is way too large topic to discuss here...

Kiks 

Can you share a screen snapshot of Rithmic's timestamps? Does it show all the stages of where your order is during its trip from desktop to AMP/CQG then back? Anyway, I just got my Rithmic API credentials. Thanks to @mattz for helping out. Thanks for your help. Kiks

Yes please subscribe to Rithmic API and learn is it suitable for your purposes. There is a very good API documentation available.

I do not know your real situation well enough to give you any precise help but I am sure I gave you some good clues and advices. Follow them if you like.

Kiks 

Thanks, Kiks

1st - 2 lines are local MT5 terminal response messages. (not just the 1st line). After the 2nd line >> Line 3 (line 3 - is the time “241 ms” from the MT5 terminal to the AMP/CQG/MT5) the order is sent/received at AMP/CQG/MT5 environment.

MT5 terminal processes orders in sequential order.
The “speed time” from the MT5 terminal >> 1st order is what took the bulk of the transfer time - 162.77 ms
This is where the initial bulk of the total “speed time” lies, all the other 4 orders processed after this 1st order took only approx. 80 ms

1st order - transfer time from his MT5 Terminal to AMP was 162.77 ms
2nd order - transfer time from his MT5 Terminal to AMP was 203.89 ms
3rd order - transfer time from his MT5 Terminal to AMP was 220.74 ms
4th order - transfer time from his MT5 Terminal to AMP was 228.08 ms
5th order - transfer time from his MT5 Terminal to AMP was 243.23 ms

You sent 5 orders and total time MT5 terminal spent to send/process all 5 orders to AMP/CQG/MT5 environment - was 243.23 ms

What is the Chicago colocation you are using? The MT5 native VPS?

Thank you,
Matt Z
Optimus Futures Support

There is a substantial risk of loss in futures trading. past performance is not indicative of future results.

Hi Matt,

Thank you for getting the response from AMP. I am just trying to understand why MT5, known as a very fast platform (actually designed for HFT) , suddenly is very slow.

Let us assume it wasn’t an algo generating the order. You are sitting there and ready to order with your mouse.
Line 2 represents your “mouse click” to BUY LIMIT.
What else do you do as the buyer? You wait until you get the deal confirmed.
That’s lines 3 to 6.

For all you know, after you clicked your mouse, your electricity went down.
Are you still messing around with your mouse without the electricity? No, you can’t. Everything is in the hands of AMP/CQG/CME now.
Would they still handle your order? Of course!
That’s where lines 3 to 6 come in.

With algo trading, here is what I think happened.
Line 2 - Algo software sents an order asynchronously.
For all we know, I could have unloaded the software and shutdown windows, all programmatically, right after sending the order. I don’t care, I am sending the order and then shutting the desktop. We can do that programmatically.

Line 3 - AMP received it. Examined it if the order type is valid (buy limit). If the symbol is valid (EPU8). If the amount is valid (2853.50). If there is money in the account to cover the margin required. If there is a problem, it would reject the order and that’s the end of it. It is not necessary for my desktop computer to be hooked up and listen further to their messages.
For all you know, I have another connection on my iphone watching the trade with CQG Trader. And manage the trade on my iphone.

Line 4 - finally AMP is happy and the order is good to go. Sents it to CQG.

Line 5 - CQG sends the order to CME so they can put it on their limit order book.

Line 6 - CME fulfills and confirms




Another example. Let us say I place a stub BUY LIMIT order for ES at $1000. Hoping for a flash crash.
I can do that anywhere. On Sierra Chart, on NT on Rithmic. Anywhere. Do I spend 240 ms doing that? A mouse click from a dedicated server with a <1ms ping to AMP would take 240 ms?