NinjaTrader VPS vs Dedicated Server: Which Is Faster for Futures Trading?
Three separate latencies sit between a futures platform and a matching engine, and only one of them is a hosting decision. This guide separates them, then gives the figures we measured from our own Chicago facility to the broker gateways a NinjaTrader or Tradovate setup actually connects to: 0.2 ms to Rithmic's market-data gateway, under 1 ms to its order gateway, about 3 ms to CQG's. The question that follows is not really "VPS or dedicated". Both sit in the same city and cover the same distance, so neither is closer to anything. What changes is who else is scheduling the CPU while your strategy is trying to finish a calculation, which is a question about load, not about milliseconds on a map.
Loading...
The short answer
A dedicated server is not closer to the exchange than a VPS in the same building. Distance is a property of the building, not of how the machine is carved up, so anyone selling you a virtual instance and a physical one from the same rack is selling you the same network path.
What a dedicated server changes is the part of the delay that happens inside the machine. On a VPS, a hypervisor decides when your virtual cores get real ones, and that decision depends on what every other tenant on the host is doing. On a dedicated server there is no such decision, because there is nobody else. For a platform that renders charts and evaluates strategies on a handful of threads, that shows up as consistency rather than raw speed.
So the honest verdict is conditional. If NinjaTrader is open on your desk while you click into trades, a VPS in the right city is enough, and the money is better spent on the connection than on the metal. If a strategy runs unattended and has to react on the tick, the machine with nobody else on it is the one that behaves the same way at 2pm as it did at 9am.
Where the milliseconds actually go
There are three hops between you and a fill, and they are owned by three different parties.
Your desk to the server. If you are trading from home, this is your ISP's path and it is the largest number in the chain, typically tens of milliseconds. If the platform runs on a hosted machine, this hop stops mattering for execution entirely: your remote-desktop session can be slow without the strategy being slow, because the strategy is not running on your desk.
The server to the broker's gateway. This is the hop that hosting actually decides, and it is the only one in the list you can shop for. It is also the one nobody publishes honestly: a provider claiming "1 ms to CME" is usually quoting a path to a broker gateway, not to a matching engine, and often without saying which gateway, on what date, or over how many samples.
The gateway to the matching engine. This belongs to your broker and their routing arrangements, and no hosting provider can sell it to you. Rithmic, CQG and the other gateway operators sit in CME's Aurora facility or at 350 East Cermak downtown; what happens after your order reaches them is their infrastructure, not ours.
The practical consequence is that the hosting decision affects exactly one of three hops. That hop is worth getting right, and it is worth being suspicious of anyone who describes it as if it were the whole chain.
What we measured from Chicago
These are round trips from our own Chicago facility, taken on 14 September 2026, 100 samples per target, no packet loss. The two TCP figures have the measuring host's 0.3 ms address-translation delay subtracted; the ICMP figure is uncorrected. The targets are the gateways a NinjaTrader or Tradovate setup actually connects to, not a city centre or a landmark address.
| Target | What it is | Method | Measured |
|---|---|---|---|
ritmz01001.01.rithmic.com | Rithmic market-data gateway, the feed a chart renders from | ICMP, 100 samples | 0.2 ms round trip |
ritpz01000.01.rithmic.com:64100 | Rithmic order gateway, where R|API orders go | TCP connect, 100 handshakes | under 1 ms |
www.cqgtrader.com:443 | CQG gateway, where NinjaTrader Continuum and Tradovate orders route | TCP connect, 100 handshakes | about 3 ms |
Three things those numbers are not. They are not a cross-connect: this is a path across our own AS55285 network and the public internet, not a cable into an exchange cage. They are not a CME figure: CME Group matches in Aurora, and we have measured the broker gateways rather than the exchange, because the gateway is what your platform opens a socket to. And they are not a promise about your broker's own queue, which sits past the last hop we can see.
One target is deliberately missing. Tradovate's API hostnames resolve to an anycast load balancer, so pinging them measures the distance to a nearby front end rather than to Tradovate. We have left that figure out rather than publish a flattering number that means nothing; the CQG gateway above is the one Tradovate orders actually route through.
What the hypervisor costs a trading platform
The case for a dedicated server is the same one that applies to game servers, for the same reason: both are workloads where a small number of threads must finish work on a schedule, and neither is helped by having more cores.
A VPS gives you virtual cores. Behind them, a hypervisor arbitrates between tenants on one physical host, and your thread runs when the scheduler says it can. Under light load nobody notices. When a neighbour on the same host starts a build, a backup, or a badly written query, your thread waits, and the wait lands wherever it lands, which may be in the middle of a strategy evaluating a tick. That variance is the cost, and it is invisible in a benchmark run on a quiet afternoon.
A dedicated server removes the arbiter. There is no hypervisor, no other tenant, and no scheduler deciding when your instructions run, so the clock speed on the specification is the clock speed the platform gets. For NinjaTrader in particular this favours per-core speed over core count, which is why the AMD Ryzen configurations tend to be the sensible pick over a many-core EPYC that would win a spreadsheet comparison.
| Trading from home | VPS in a Chicago facility | Dedicated server in a Chicago facility | |
|---|---|---|---|
| Path to the broker gateway | Your ISP's route, typically tens of ms | The facility's path, single-digit ms | The same path, the same single-digit ms |
| Who else uses your CPU | Everything else on your desktop | Other tenants, arbitrated by a hypervisor | Nobody |
| Behaviour under someone else's load | Your own browser is the neighbour | Varies, and you cannot see why | Unchanged |
| What you can measure yourself | Ping from your desk | Ping from the instance | Ping from the instance, and from the provider's looking glass before you buy |
| What stays invisible | The provider's internal path, the broker's queue | Neighbour load on the host | The broker's queue and the venue's own matching |
| Sensible use | Discretionary clicking | Unattended platform, light strategy load | Strategies on a tick budget, tick databases, multiple instances |
Chicago or New Jersey
Which city is right depends on what you trade, and the answer is not a matter of degree.
Futures. CME Group's matching engines are in its Aurora, Illinois data centre, roughly 30 miles west of downtown Chicago, and the retail gateways sit there or at 350 East Cermak in the city. Futures traders want the Chicago area, and the figures above are what that region looks like from our facility.
Equities and options. Nasdaq, NYSE and Cboe run their campuses in Carteret, Mahwah and Secaucus, so the relevant infrastructure is in northern New Jersey, not Chicago. From our New Jersey facility we measured under 3 ms to Secaucus and under 2 ms to Piscataway on the same date, 100 samples each. Those targets are public research probes in the campus towns rather than the exchanges' own gateways, which are members-only and do not answer strangers; they establish the metro path, not a venue relationship.
Europe. Euronext moved its core matching to Bergamo in 2022, so Amsterdam no longer carries an equities story at all, and Eurex and Xetra match in Frankfurt. This is worth checking per venue rather than assuming the financial-centre city is the data-centre city, because it frequently is not.
When a VPS is the right answer
Plenty of setups do not need a physical machine, and the conditions are easy to state.
- You trade discretionally, by hand, during the session. Your reaction time is the binding constraint, not the server's. A VPS in the right city is fine.
- The platform is idle most of the day. You are paying for a whole machine to watch a chart. A virtual instance sized to the job is cheaper and behaves identically at that load.
- You are running one instance with no automation. The jitter argument only bites when something must finish on a deadline. Nothing here has a deadline.
- You want to test a broker or a data feed for a week. Spin up whatever is cheapest, measure the path, and decide afterwards.
The case flips when a strategy runs unattended, when several instances share the machine, when a tick database is writing while charts are rendering, or when you have already seen the platform stall at exactly the wrong moment and want to eliminate the explanation you cannot inspect.
Test it yourself before you buy
Every figure in this article is repeatable, and the point of publishing the method is that you can check it rather than take it.
Open our public looking glass, choose the Chicago or New Jersey node, and run a ping or a traceroute against your own broker's gateway hostname. That gives you the same measurement we took, against the endpoint your platform will actually use, before any money changes hands. Results can be copied or downloaded, so comparing two providers or two cities is a matter of running the same command twice.
When you compare against someone else's marketing figure, ask the three questions that make a latency claim meaningful: to which host, by which method, and on what date. A number without those is a number about nothing in particular.
How Serverside fits
Our Chicago machines are single-tenant servers in a downtown facility on our own AS55285 network, with the measured paths above to the Rithmic and CQG gateways. Windows Server deploys as a one-click image for NinjaTrader itself, the AMD Ryzen configurations cover the clock-bound case, and NVMe local storage handles a tick database on the same box. Inline DDoS mitigation runs on every server by default rather than as a detour through a scrubbing service. Billing runs hourly through annual on the same hardware, with a 5% discount at semi-annual and 10% at annual, so testing by the hour and staying by the month is one machine rather than two.
The full picture of what a trading workload gets is on our Chicago low-latency trading servers page, the machines themselves are listed on the Chicago dedicated servers page, and the argument for physical hardware in general is on our bare metal page. Serverside is not affiliated with or endorsed by NinjaTrader Group, Rithmic, CQG or CME Group; their names appear here to describe what runs on the machine and what we measured against.
FAQ
Does a trading VPS need to be in Chicago?
For US futures, the Chicago area is where the relevant infrastructure sits: CME Group matches in its Aurora data centre west of the city, and the retail broker gateways resolve to Aurora or to the carrier hotel at 350 East Cermak downtown. Hosting anywhere else adds the distance between that region and wherever you chose instead. For US equities and options the answer is New Jersey, not Chicago, because Nasdaq, NYSE and Cboe run their campuses in Carteret, Mahwah and Secaucus.
What latency does NinjaTrader actually need?
Neither NinjaTrader nor the exchanges publish a threshold, and anyone quoting one is quoting themselves. The useful distinction is between discretionary and automated trading. Clicking a chart is a human-timescale activity, and tens of milliseconds are invisible against your own reaction time. An automated strategy that reacts to a tick is a different case, and what matters there is consistency rather than the average: a path that is usually 1 ms and occasionally 40 ms is worse than one that is always 5 ms.
Is a home fibre connection enough for futures trading?
For discretionary trading, often yes. A good residential line to a Chicago gateway is typically tens of milliseconds, which is below the threshold at which a human notices anything. What a home connection cannot give you is a machine that stays up and connected when you are not at the desk, or a path whose behaviour you can measure and hold someone to. Strategies that need to run unattended through a session are the case for hosting, more than raw speed is.
Should I pay hourly or monthly for a trading server?
Hourly to test, monthly once you have decided. The point of the hourly cycle is that you can provision a machine, run your own platform against your own broker gateways through a full session, and see the figures for your setup rather than ours. If it works, the same machine moves to a monthly or annual term without being rebuilt; if it does not, you have spent a session's worth of hosting to find out.
Windows or Linux for a NinjaTrader server?
Windows. NinjaTrader 8 is a .NET desktop application for Windows, so the platform itself needs Windows Server, which deploys as a one-click image. Linux is the right choice for the parts of a trading stack that are not the platform: a tick database, a data recorder, or automation that talks to a broker API directly. Running both, one machine each, is common.
Written by
CFO, Serverside.com & Host Havoc
Chris is the CFO of Serverside.com and Host Havoc, a Chartered Professional Accountant with Big Four audit experience at PwC and KPMG and a decade in the finance of hosting businesses.
Keep reading
View all articlesEnjoyed this article?
Get new guides and engineering write-ups in your inbox. No spam, unsubscribe anytime.



