Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
it will - because remote desktop like connectivities always have an overhead and add latency.
It still means though that your automatic system parts (stop loss, trailing stops etc.) execute 5ms from the exchange. Depending how automated you are this can be a signiicant diference in better executions. And it also means hiher uptime because your machine is in a data center not your home end - power failures, line down situations should be a lot more rare there.
But at the end, moving closer to the exchange makes only sense for autoamted trading - note that I dont explicitely mean ATS (automated trade systems) - every decent platform has automated parts like trailing stops and those will be in the market faster.
I think it's not that simple.
Their is the latency but also the bandwidth, and the power of the end user PC.
Let's say the end user is 45ms from the exchange, but need 500 kb of market data to compute and generate a signal, or draw a bar. It might easily take 500ms for this PC to get all the needed data, compute them, and then display it on the user screen.
With a remote machine, without enough cpu power, a 100mb/s, and 1ms from the exchange (this is what I have myself), the job can be done in, let's say, less than 100ms. With the RDP overhead, with is relatively light, it can be faster, in this example.
What I can see with my VPS users, there are far away from the exchange (in Asia or Europe), or have a "not so good" Internet connections (it's always very fun to lose Internet when your in position, and when your stop is defined and managed by your own PC ), or people who use 100% automated systems.
The only performance issue I can see, due to the latency, is for traders who only use market orders for entries and for exits (no ATM at all), or people who needs a lot of charts with very small timeframes, on multiples screens. I use my own VPS with 3 screens, and it works fine, but I assume that with more with 4 screens full of changing charts, the bandwidth used by the RDP might be too high (but never tested, that's a theory). That's logical: RDP is just send the changes which occurs on the remote screen: if this one has a lot of pixels to refresh, it might be slow.
Then, a good compromise is to have the big charts running from the user PC, and few DOMs for the instruments traded on the VPS itself.
Why are you still wondering about zenfire - it is add on to rithmic. All questions answered For some reason people just get comfortable and with a brand and stop looking for the truth. Read my other post, I provided direct CME exchange certified connections and Mirus/Zenfire is not on it. Rithmic is listed. You guys need to cut the fat and go to rithmic directly. This is not a paid endorsement of mattz of optimus I can not believe you guys are still falling for this Mirus marketing BS.
Your point has been made several times over. Stop posting the same review over and over, as it seems you are trolling or are doing this for self-promotion if you continued -- neither of which are allowed here.
Mike, FYI, if not this "trolling" post I would have found this information re Zen I don't know when. Most people, including me, don't have capacity to read everything posted on the forum, so I believe there's nothing wrong in repeating information already existing in other threads as long as it's relevant to the topic. So I'm grateful to MooneyNYG for that post.
The safer is to change TcpAckFrequency and TCPnodelay values in the registery, no need to launch an .exe.
The gain would be visible if you already have an high latency, like 300ms from Australia to Chicago. Below 100ms, I don't think the difference will be visible.
TCPnodelay won't help a lot, it's only useful for very small packets (see Nagle's algorithm - Wikipedia, the free encyclopedia).
TcpAckFrequency allow acknowledging immediatly all incoming TCP segments, in all cases (instead of waiting a bit for another packet).
I don't think both parameters could help, it may only "look" faster.
All these can be changed in the registry.