Welcome to NexusFi: the best trading community on the planet, with over 200,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 -- discounts are available after registering.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
Thanks — this looks like a strong fit for what we're doing (MBO-level research + honest fill simulation, no live/FCM path). A few technical questions before we go further:
1. Any linux-arm64/aarch64 build, or x86_64 only? Our research VM is ARM64 — would the Docker path work there (native or emulated)?
2. Do you ship or endorse a CPython binding, or is the C ABI doc sufficient to build one (any user examples you can point to)?
3. Which Databento DBN schemas are supported in replay (MBO vs MBP-10)? Any file-version constraints?
4. Does the simulator ship with sample PCAP/DBN data so we can validate the fill model before we buy our own MBO files?
5. License specifics: research use on a cloud VM/Docker fine? What does the UUID lock bind to? Renewal price after the 3 months?
Happy to take the pricing/discount side to DM — sending you a message.
1. We have validated with docker on a Mac (Arm cpu) - everything works as expected, however hugepages must be disabled (do not enable them).
2. We have users with their custom CPython bindings in both testing and production. We only provide C++ and Rust ABI. You are welcome and encouraged to use CPython, however it is not officially supported or provided by Nanoconda (At this stage we don't want to commit at covering any potential bug fixes or production issues for Python).
3. MBO is standard. MBO provides full data and is usually is more cost effective to purchase than MBP-10 for the same time period.
4. Yes, you will get a download link with sample DBN data.
5. Yes, you can use on any VM that is RHEL compatible and is X86 (you can get one for $5-$10 / m on Digitalocan). Arm was tested, however software was build with X86 architecture in mind. I sent you a discount in DM, it will last till end of the year, so you can purchase the simulator license twice the discount.
@probit — two things: one on cost, one that will save you a backtest. Databento's free window is wider than you think. mbp-1 is free for any date inside the last 12 months; it only starts billing further back (~$4.30/month-symbol in my case). get_cost gives you the figure before you pull anything.
Two caveats. It's top of book, not the MBO you clarified in #4 — aggregation only runs one way — though it does cover your original depth/imbalance ask. And the window rolls: a date that is free today bills next month, so don't delete what you pull. I can't share files, redistribution isn't mine to grant, but you may not need anyone to.
On your Nanoconda question about sample data to validate the fill model — that's the right question, and I'd make it a gate with a number on it. Before trusting any harness I require it to reproduce a known result trade for trade. Not close: identical. Mine were 333/333 against my own recorder, and 136/136 on a separate replay run.
The reason is that the failure is silent. A harness I trusted was running 157 of 204 trades with no tick data behind them at all — the rotated hourly files had stopped containing the hour their filename claimed, so I was filtering by name instead of by ts_recv. It threw no error. It just produced a quietly wrong backtest.
If a vendor can't hand you that number, you're the one who has to produce it.
probit, did you settle on interval snapshots or event level data for your research?
I’m interested in how you separated testing the order-flow signal from testing execution. Could the snapshots answer your signal question, with more detailed data needed only when evaluating fills? It would be useful to hear which part of the research actually required the extra detail and whether that changed your original data requirements.