Hardware, Workers and Cloud

1. Why GSB uses so much RAM

• GSB caches everything it can calculate in memory. That makes it 10 to 100 times faster, but RAM-hungry, and it means one process can't use the whole CPU.
• So GSB splits the work: a manager (the window you use) hands jobs to workers, separate processes that each take a share of the CPU and RAM.
• GSB doesn't use the graphics card. Peter looked at it: only the performance metrics could move to a GPU, for about a 10% gain (2020). Add computers instead.
• An indicator's calculation speed doesn't matter inside GSB, because it's cached.

2. CPU

• Intel with a high clock speed. Parts of GSB are single-threaded, so clock speed matters as well as core count.
• AMD: as of January 2025, Peter's rule is to scale an AMD chip's cpubenchmark.net score down by 50–75% when comparing it with Intel for GSB. AMD also needs more workers, and so more RAM.
• Desktops: Peter rated the i9-13900 and 14900 class by far the best for GSB and TradeStation (2022–25). The 14900 takes 192 GB of RAM.
• Best value: a second-hand dual Xeon E5-2699v4 server.
• Undervolt the CPU and cache slightly (about −0.05 to −0.1 V) and use a good water cooler.
• Keep CPU temperature to roughly 80 °C or below (Peter, 2021). Resource Manager can throttle workers on temperature, but his view is that better cooling is the real fix. If the PC resets itself during builds, check the Windows event logs and the CPU temperature first.
• TradeStation uses at most 32 cores, so the best GSB machine isn't always the best trading machine.
• Build 65.12 added a "tiled mode" speed-up for 13th-generation Intel chips.

3. RAM and page file

• Two normalisation modes in one build double each worker's RAM. More modes multiply it again.
• Bigger cache sizes in Tools → App Settings are faster but use more RAM, in the manager as well as the workers.
• Several machines of different sizes sharing one GSB folder: App Settings (including cache sizes) apply to every machine that uses the folder. Peter's workaround (2020) is to save a separate App Settings file for each machine and load it on that machine's manager, while sharing the optimisation settings.
• A manager killed during walk-forwards on a big machine is often a page file that's too small: one user fixed it by raising the page file from 38 GB to 100 GB.

4. Windows settings

• Power plan: set the minimum processor state to 100% (High performance). Power saving can hold the CPU at a fraction of its speed.
• Dual-CPU servers: Windows Server 2022 spreads the load better than Server 2019 (Peter, 2024).
• Multi-CPU desktops need Windows 10 Pro for Workstations (a member's tip).
• Don't use "debloated" Windows builds. GSB relies on Windows performance counters, and stripped-down installs can stop it starting.
• .NET Framework 4.8 must be installed.
• Schedule Windows updates for times you're not building or trading.

5. How many workers

• From build 67.72 (mid-2024), far fewer workers fill a machine: Peter maxed out a 72-core server with 8 workers. If you set a high worker limit before then, lower it.
• Let Resource Manager decide how many to run, and aim slightly below full CPU.
• Run fewer workers when you're doing a lot of walk-forwards.

6. Virtual machines and VPS

• GSB's licensing won't run in a virtual machine, and rented VPS cores are often oversold and poor value for GSB anyway.
• GSB needs Windows. On Linux it would only run inside a Windows VM, which hits the same problem, so rent dedicated physical servers instead.
• Standalone is fine while you learn, but much slower than a manager with several workers. For real builds Peter recommends a manager with your own workers, plus the free cloud if you want it. A manager with only one worker gains little.

7. The GSB cloud

• Workers report back through Trademaid's database, even when they're on your own PC. A slow or unreliable internet upload can lose systems.
• How much free capacity the public cloud has varies. A new build that can't talk to older ones takes you out of the public cloud until others update.
• To build only with your own (or a group's) machines, use a private share key. The steps are on GSB Resource Manager.
• A cloud walk-forward that ends as CanceledLost was removed from the database because the worker running it was closed, killed or lost its connection. Run it again.
• The manager uploads price data already multiplied: 1-minute data set to 30 is sent as 30-minute bars. So you can keep one long 1-minute master file and set the interval in the manager.
• Running workers on a second PC of your own? Auto Share In Network decides whether this manager pulls them in without a share key; see GSB Resource Manager. Don't turn it on for public cloud workers.
• SQL timeout messages on workers can be ignored.
• If the cloud has an outage, restart your managers and workers once it's back.

8. Speed tips

• Use as few data streams as the system needs.
• Use as few indicators as you can. With every indicator switched on (166 in 2023), one member's builds ran five to ten times slower than with his usual 117.
• Larger bars are faster: 60-minute bars build faster than 20-minute bars.
• Turn off live GUI updates during long runs; they cost about 20% of the speed.
• Use an M.2 SSD. Peter: nothing beats a Samsung M.2 for bang for buck.
• Keep GSB current: from build 75.63 (2026) GSB builds 2,500 ES systems in about 90 seconds.
• Build 75.94 (July 2026) can run several parallel search "islands" on a multi-core machine with the /optimizers command-line option.

9. Licences per machine

• Every machine that runs GSB workers needs its own licence. Trademaid discounts second licences.
• From build 67.15 (April 2024) you can label each machine on the registration screen.
• Replacing or reformatting a PC: ask Trademaid to revoke the old registration and issue a new one. The labels tell you which one to revoke.

Further reading on the Trademaid forum

• What CPU/hardware to run GSB on
• GSB Resource Manager

Next Steps

With a machine ready, get to know the GSB window: