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)
Ii seems it's an ISP issue, but from what I see, from different IP sources (so different routes are taken), the last ISP before CQG servers is always Qwest. Maybe they only have one ISP, which is not, at least now, a good one ?
Yes i think so. Is it important to have more than one ISP? Maybe they have another one as backup. I am not that expert.
In my eyes the problem is the "jump" from Germany (in my case) to USA. Ping is fine within Germany and within USA. There is only one ping spike from Germany to USA.
It is understandable. Thank you and the team for the efforts to solve this issue too.
Sorry to ask again, if NT will not report lost connection, will the user somehow know about delayed/filtered/packaged connection state?
Will the mentioned ignorance of slow connection state affect only CQG-based connections, or others too?
Would be there an option within NT to return the strict use of the connection state?
- User will not know if slow, I would not equate slow to meaning delayed or filtered, please keep this in mind that slow in our experience is far and few between and when it happens it returns to normal in seconds, its a temporary state
- The quality of your internet connection to the trading servers is not CQG specific and can effect all electronic trading providers
- No option to return to strict use of connection state
I am going to move from CQG back to rithmic. I can live without server side OCO. Even if NT fixes the disconnect sensitivity there does seem to be some system wide issue with the route that has nothing to do with NT. There are times one hop is over 100ms and I am sitting on a server in Chicago. I may not be able to report back because I think I am going to try and get in Aurora CME Data center as well as move to rithmic (I can report on how that goes but won't help those still on CQG). Will cost more than what I am doing now but less hops means less issues and even lower latency. Should pay for itself.
I will say my experience with CQG feed has basically stunk. No other way to say it. Whose fault who knows? It's not ready for primetime imo and has cost me valuable ticks.
"The day I became a winning trader was the day it became boring. Daily losses no longer bother me and daily wins no longer excited me. Took years of pain and busting a few accounts before finally got my mind right. I survived the darkness within and now just chillax and let my black box do the work."
Platform: "I trade, therefore, I AM!"; Theme Song: "Atomic Dog!"
Trading: EMD, 6J, ZB
Posts: 796 since Oct 2009
trace route command shows how many hops, pings and dinks inbetween the client pc and the host receiving server,
those collectively when added together are latency
slow in this context means bandwidth issues, clogged pipes, bursts of data exceeding the mean average capacity of the outbound pipes from the data server to the entire populace of subscribers
slow also has much to do with one's ISP SLA and in-bound speeds.
slow also has much to do with one's CPU, motherboard and chipset, operating system HDD / SSD and other active processes running on the platform at the time "it (slowness)" is observed
futures.io (formerly BMT) has a thread regarding speeding up one's platform, whether using Ninja, or any other trading application. In essence the suggestion is to initially increase to maximum one's DRAM slots; implement some sort of VRAM / Ramdisk; allocate priority to your trading architecture through your QOS Router features and de-prioritize everything else.
Eddie and his crew at EZTradingComputers.com are some awesome guys that have really run the gambit on this issue and can take this conversation further, provided one's glasses stop fogging over from the details...
