PRT Running on Cloud Servers?
- This topic has 10 replies, 3 voices, and was last updated 6 days ago by
.
-
It is not about you who observes a server as being “in the cloud” – it is about PRT herself. At least this is what GraHal means.
But that doesn’t matter much, because what GraHal wants to refer to is VPS vs VDS vs possibly even CoLo.
Now go Google … 🙂IMO all is moot or worse, because nobody can provide better and faster servers than you yourself (hence PRT in this realm). The difference lays in the maintenance and support.
The only server type which would help out PRT mere internally, is the CoLo (Co-Location) type where you again can shovel in your very own server in the environment of 99.999% up time and that located close to were it is needed (example : in the middle of / in between Chicago and Connecticut instead of in Paris). But these are not the reasons GraHal wants to hear about.So GraHal – no. All you’d want is your own server(s) (read : PRT wants her own server(s)) with dynamic processor core and memory allocation for specific tasks in the VM (Virtual Machine) environment. And well, I guess they done that long gone.
Something else is : AFAIK IG has her own PRT server(s). And where they reside – don’t ask me. But they are slower than PRT’s servers. In any event they wouldn’t belong in between Chicago and Connecticut (= CME vs IBKR) but I suppose somewhere in the UK, on premise of IG’s.
🙂
1 user thanked author for this post.
Hi GraHal,
Just envision that you own such a PRT server yourself. Or more realistically, that you use any of the other platforms you know and you have to run that on your own PC – server(s) if you want. You will hardly get it faster than what PRT provides (this is not guessing – this is knowing from experience). And then to think that it is quite easy to see that the PRT servers provide 8 processor cores to you. It is only that I can not tell when these are shared between you and me (and more) and thus to what degree more of these processors (or full servers) – each with their own processor cores – are provided so we won’t bother each other. Of course we talk about numerous people – not only you and me.
Trading hours are hardly related because a server doesn’t have to do much more than one time processing the ticks, which is just data pushing through some pipes. – plus hand out an order here and there. This is totally different from running a backtest which would consume 100% of the CPU (-cores) for the duration of each backtest. Thus, if your single backtest takes 10 minutes, then all the time you would be bothering someone else, assumed that he/she (and several more) share the same cpu with you. Thus two backtests take twice as long (this is about linear). No data (hence I/O) is involved except for some coughing up of a small result set towards you, so it is really 100% cpu.
The real pain comes from the timeframe – and you will actually know it. If you use seconds then a 200K bars backtest may take say 5 minutes for these few days of time period, while the same backtest with a 10 minute timeframe takes less than one seconds, assumed that the time period is equal (again a few days). Less bars = less processing = less cpu cycles required.
Don’t tell : back at the time when I was backtesting with 1 second bars on EUR/USD, people complained about the slowness of “the PRT server”. So everybody noticed that I was running backtests on 1M second bars which took 10-15 minutes each time, with the notice that EU/USD bears very many ticks (much more than indexes). So *that* is painful. You could thus bet that when something is suddenly very slow, that someone is backtesting with 1 second bars on EUR/USD (or other Fx).This distance from you(r PC) to the PRET servers does not matter a bit. All runs on the server(s) itself, and all you may notice is the latency of commands and results (which is umm … 15ms or so, round trip to Paris ?). For Australia it could be somewhat more (like 300-400ms these days).
The distance from the server(s) to broker and/or exchange *is* relevant when you’re working with orders which try to snatch the best price from others. This means working at the tick level, which is not possible with PRT anyway. Still it would matter slightly when submitting an order right after you notice “your price” which is long gone after you transmit the order which needs to go to Paris, from there to the UK (IG location ?), back to Paris for confirmation and possibly a final way back to the UK again. Really 1000s of price changes will have passed in the mean time during trading hours. Anyway, no need to think about this with PRT. Other platforms – operating at the tick level with Bid and Ask – Yes. But still quite undoable unless … your server (yes, YOUR server – the Co-Locate thing – but can be VPS too) is om premise with the broker or Exchange (which would be the same for IG).This is a whole world in itself … but luckily a black box to how we work with PRT.
Lastly, don’t underestimate the Seconds vs Minutes and backtesting;
Minutes bars don’t contain tick data for backtesting. Seconds bars do (this is common to data providers and although PRT is its own data provider I recall it is the same). Not that you can utilize them with backtesting (with some sneaky indicator perhaps), but processing all those ticks under the hood is killing.1 user thanked author for this post.
You can try to get quotations or just select from server providers for disk type (like SSD), disk size, or processor (most provide simple E5) and processor speed and cores, plus memory – and you will see that you won’t get far. The best out there would never suite me at all (like all is maybe 25% of possibilities), while it then costs 1500-2000 per month.
It is all about management, support and maintenance. Same like a website. You can roll your own and *do* all your own, or have it hosted and don’t look back but have all sluggish and with too few capacity (depending on your needs of course).If a program (could be ERP) runs in the cloud then
– you don’t care about backups and maintenance and new hardware
– and are confronted regularly with things you did not ask for.
That’s the cloud, and that is where you recognize it from. GMail is an example. Office365 another. And if Microsoft is doen, airplanes don’t fly (like a year ago).1 user thanked author for this post.
Here we are in 2025, but the speed of optimisation feels like we are still in 1990’s re computing power?
You have it upside down – but how to know it …
Working with PRT is a sheer relief, were it about backtesting speed. This is not only about processing power or speed, this is also (even merely) about functional aspects of the environment of concern. One example (out of dozens) : in PRT you run your backtest and during the process you can observe/analyse results. One small example out of that : ask for the Detailed Report while the backtest still runs (for another 15-30 or whatever minutes) and do that again and again and again. Others ? please wait until these 15-30/etc. minutes have been passed and only then ask for the Detailed Report (again out of more examples of what you all can do meanwhile the backtesting). I estimate the gained throughput speed at at least 100 times better for PRT. And oh, what about the yawing elsewhere (simply nothing to do !).But again about “how to know it” : I am afraid you just lack the reference to ever make the statement that the speed is back to the 1990’s because … well, you never tried it where the grass seems greener. 🙂 This, while an xxx elements lay on your own side of the matter – but GraHal, I cannot know *that*, so just few examples (“Backtest” I regard the same as “Optimise” here) :
- Do not use Graph(OnPrice) while backtesting;
- Do not use bars based on seconds (if possible of course);
- Do not use loops.
- Avoid averages of any “length” (14 is already “length” that needs to process of 28 bars already and that for each bar);
- Avoid arrays as the plague;
- Do not use CAL;
- For that matter, do not use standard Indicators of which you probably won’t know what they do internally (yea, process per tick) – this is the same as the Averages subject;
- If possible, use an even amount of backtest iterations as the number of cores used by the PRT server (like : (just an example !) if the PRT server bears 10 cores, avoid the 21 tests we use all so often – instead use 20 – this saves about 1/3 of the throughput time (!));
- Avoid IG in the first place – it bears ~ 10 times more price movements because of her own internal corrections and hedging, and it is linear to the time your backtest takes (it always processes the “ticks” no matter you cannot utilize them (yet);
- Avoid nested loops and rather try to run two subsequent separate loops – example : don’t run an optimisation on TP and SL at the same time (bad for other reasons anyway) but rather run those subsequently) – this is a general thing, not only PRT’s);
- Shorter codes run faster than longer codes;
- Tell IG to use more servers, because it is clear that a. more people like us are backtesting on them and b. I know historically that they are not interested in that while PRT herself is (compare IBKR as a broker).
All these things – even the last one – you could translate to your own multiprocessor super server – would apply the same when you’d have it at home.
Salient detail : technically PRT allows this, and I don’t know if from today, but back in I think 2019 I have been testing the API version of PRT and this means that we ran all locally;
a. You might not know where to start because you’d suddenly need to know all about hardware and capacities and speeds of everything (you might, but Joe might not);
b. You’d be doomed to the grills of the broker and its down times and all sores applying to that (I can promise : you do not want that – it is the exponential of our complaints to PRT/IG – also IBKR of what they all should do better, with currently PRT behind the wheel streamlining this all).I hope it is clear that I have been there (literally : still am) and that I don’t have vested interest in ProRealTime SARL etc.).
But : discuss; I think it is fun. I think I know of at least two other PRT users who try to eat from that greener grass, so if they read this – please join. And … it is perfectly allowed to even mention names of other platforms because it is PRT in the positive. I will refrain from that for now, but the subject is huuuuge. So much to learn …Working with PRT is a sheer relief
Wow! I’m sure PRT will be glad to know … above are not the sentiments you generally express in Topics on here. 😉
1 user thanked author for this post.
There are two main streams and the 2nd below I deliberately scratched from my previous post because … well, not related to the subject :
- The technical merits within PRT go well beyond other so-called self-respecting autotrading platforms. This is IMO but with the experience.
- The functional support of PRT is non-existent. This includes *dealing with issues, *feedback of changes (Release Notes), *functional (I don’t say technical -) testing prior to release, *snale-speed and beyond (towards the wrong direction).
So GraHal, I am just the most neutral and don’t like to inject negatives into an actual positive post/thread. I just did under b. ever so slightly, out of self-defense.
Haha.Ad 1.:
- The sheer speed of adding indicators or debug graphing, is beyond anything.
- The intuitivity of doing so, is again beyond everything, BUT I now talk from a being-able-to-code perspective. This turned upside down : even with this knowledge, other platforms bring you nowhere without huge time investment first.
- The sheer fact that you can zoom in infinitely while at the same time being able to zoom out infinitely (okay, up to when bars are close to merging), is one 100+ positive because without that I am helpless. So Yes, *I* am then helpless. But I am the one that dives into each possible detail. Is that not possible ? then I am blind. It could be rare that people demand such a feature and a. without knowing PRT one would not know the merit of that and b. without knowing other platforms than PRT you wouldn’t know the enormous value of it.
- Same counts for what I already talked about : what PRT all undertakes to let your system keeping on running, never mind we “all” think otherwise. Again : try to do it yourself and learn what it is all about. It-is-un-do-a-ble. Of course, I would manage, but still it keeps hunting you forever.
- We have no clue what it means to have tick data available for free, which otherwise would cost you a relative enormous amount of money. Think 100+ per Exchange/sub market per month *if* you did not make the mistake to announce yourself as Pro (many people on IG have done that), which makes that something like 1400+ per sub market per month.
This all is because PRT provides her own data feed. And merely : a feed of IG would be wordless to begin with (because “fake”) and a feed from IBKR is so enormously poor that it is useless (I am serious). The data from PRT ? it is just great (no aggregation). N.b.: Yes, it lacks the filters for fake spikes, as discussed the other day, but I am not bothered by that (coincidentally, other people well may be). - It is (don’t laugh) a sheer technical super merit that the backtesting of PRT is so enormously *fast*. How ? again, because you and me and all do this on the same server – a server which you could have at home for you own self and still don’t achieve the speed. This (IMO) is all about some strange kind of intelligence of skipping parts of code, because they are irrelevant in certain situations anyway. So … give me C++ or C# what the other platforms work with / provide, and *I* would not know what to intelligently skip. Anyway … this can be seen from various sorts of anomalies, like If commands and Graphing, which often fail.
… But it would improve backtesting speed.
And the strange thing : a small provision in the parser to auto-comment-out the Graph commands lack ? that would be for an Ad 2. 😉 - As a separate subject we could mention the charting in PRT. Nothing else out there comes even close. And mind you, this is within the same backtesting environment. So PRT can do both, while nothing else even comes close without the charting capabilities.
For fun you could compare with the grande IBKR. It is totally-nothing-nowhere regarding this.
Ad 2. could comprise of : but PRT’s mobile app is the worst while IBKR’s mobile app is the best. Anyway, all these subjects play a role, like : - What to do with a Trading Platform if you can’t get out decent Statistics – which would be your accounting.
Ad 2. could be : but in PRT Detailed Reports so often fail on diverse aspects (but at least the attempt is there). - I suppose people have no idea what it means to open a second chart with tick data for comparison with another chart with the same instrument and e.g. 1minute data. Try that elsewhere and see how far you get in an hours of time (here in PRT ? 5 seconds ??).
I just stop with this never ending list. But the moral is : you will only know when you tried to survive elsewhere – something I actually do for the reasons of better performance, ever back starting with the API from IBKR (at the same time I started with PRT). What a laugh … (pure misery).
This subject could diverge in different subjects more on the functional aspects like : “but I like to use the performance of another instrument in order to trade ‘this’ instrument”. Really ? Then with the experience-bag from PRT go to those platforms which can do that, and let us know when you are up to that aspect, first mimicking the PRT base experience in there. I will personally give you a year for it. And buy your personal super server of course because that is the first thing you will need. Wait, two of them, one for backtesting and one for production. And good C# or C++ knowledge. And the data feeds. And the knowledge about this hoopla.
All ‘n all my point remains : on the technical merit (like from Ad 1.) there is not much to complain. Oh, you want Bid and Ask ?
No.
Once you have learned how to use that, you will also have learned that to really exploit that, you are up to more servers elsewhere (the Chicago – Connecticut thing), that it requires knowledge and creativity which is for the very few only, and that …
In the end you could do all with PRT as well.
The exception could be the Volume Profile stuff – which is mere for manual trading (but could be used with Autotrading as well). Maybe some day ?1 user thanked author for this post.
Find exclusive trading pro-tools on 
