Running WoW simulations is very CPU intensive. We let you run short simulations on our servers at no cost, but as soon as you try to run something longer, we tell you to get the simulator client.
The simulator client is a small program that runs on your own computer. When it is running, any simulation that you submit on our website is sent to your computer instead of one of our servers. The nice thing is that you can use the website to set up simulations, view the results, browse your history, and so on, even though it is your own computer running the simulations.
A major advantage of this approach is that you can run as many and as large simulations as you want for free – the only limit is how much CPU power your own computers have.
Follow the instructions on the Simulator Client Page to download, install, and configure the client.
The short version is this:
- Download a zip file for your platform
- Unzip it somewhere on your computer, it will create a folder called AskMrRobotClient
- Create a settings.json file with your preferred configuration and put it in the AskMrRobotClient folder
- If you have the universal version, install the proper version of the .NET Core Runtime
Installing the .NET Core Runtime
This is only necessary with the “universal” version. If you have the windows-only version, it is completely self-contained and you can skip this step.
The client requires the latest version of the 3.1 .NET Core Runtime. You do not need the ASP.NET Core Runtime, Desktop Runtime, or any of the SDKs.
There are two popular ways to install the runtime: with a package manager, or a direct download.
Direct download: .net core 3.1 runtime
Package manager: .net core install with linux package manager
Running the Client
For the windows version, all you need to do is double-click the simclient.exe file.
For the universal version (works on Linux, Mac, and Windows), open a command prompt in your AskMrRobotClient folder and run:
The simulator client is a very simple program. It only responds to one key: press Escape (ESC) to stop it. That’s it! Everything else is handled via the website, and all configuration is handled in your settings.json file.
Updating the Client
The client auto-updates itself. When it gets a simulation or starts up, it will check for the latest version.
NOTE: If you are running an old version of the client that is lower than version 1239, you will need to manually shut down all of your clients, delete them, and download the latest version. Those old versions cannot auto-update themselves to the newer versions.
Free users can only run one client at a time. Premium users can connect as many clients as they wish (if you want to distribute your simulations across a lot of computers).
You no longer need to (or should) run more than one client on the same machine – see the configuration settings below for more details on why it is no longer necessary, short version is that we do it for you automatically with a single client.
If you had a free account running one client, then update to premium, please note that you may need to do the following to connect more clients:
- Disconnect your currently running client
- Wait for about 15 minutes
After doing that once, you should be good to connect more clients from then on.
The bottom of the simulator client page shows some statistics about your running clients. Note that they do not automatically update – you need to refresh the web page. Also, there can be up to a 10 minute delay on statistics about the global network.
Clear your Queue
The most common use for this is if you accidentally started a really long simulation and don’t want to wait for it to finish. Please note that you actually have to follow the instructions for this to work: you must exit all of your clients first. Then press the button to clear your queue.
The simulator client web page describes how to create a settings.json file and gives a brief description of each setting. Here we will go into more detail on each setting, as well as advanced use cases.
Username and Token
Pretty simple: these are needed so that your client can find your simulations. Do not share your token or your settings.json file (which contains your token) with anybody else.
If you check Enable Global Network, you are choosing to let us run simulations on your client when you are not using it. This is extremely helpful to us and we really appreciate it! You can set two settings related to the global network: threads and schedule. Threads we will explain below, it works the same as the setting for your personal simulations.
Global Network Schedule
The schedule defines a daily schedule for running the global network. For example, you might decide that you only want to let the global network do work from 1 AM to 7 AM every day. You could do that by entering the schedule:
You can also enter more than one range, such as
0100-0700,1100-1700. This would let the global network run from 1 AM to 7 AM, and 11 AM to 5 PM every day.
We have kept the scheduling system pretty simple, e.g. there is not a format for specifying a separate schedule on weekends, fancy calendar editors, etc. If there is a lot of demand for fancier scheduling we might change it in the future, but for now this does the job for most people.
Performance Mode and Threads
These two settings work together to control the performance of the simulator. The simulator client page gives a basic description, but here we will give some more guidance on what settings are most appropriate for you.
There are two main questions that you want to ask yourself:
- Do I usually run single simulations (Single Sim) or batch simulations (Test Combinations)?
- Do I want to run simulations in the background while using my computer, or dedicate all of my computer’s CPU to finishing simulations as quickly as possible?
This divides users roughly into four categories. Below are some recommendations:
1. Run single simulations as quickly as possible
Set Performance Mode to Single. For Threads, it depends on the kind of single simulations that you do. If you are doing very low margin of error simulations (0.1% or lower), or running very long custom scripts, set Threads to 1.0. This will use all of the cores on your computer.
If you are running normal simulations with 0.25% or higher margin of error, you can leave Threads at the default of -1. This will use up to but no more than 8 threads. Quicker simulations don’t benefit a whole lot from more than 8 threads.
2. Run single simulations in the background
Set Performance Mode to Single. Set Threads to 0.5. This will use half of your processors, which should allow you to do normal work while simulating without your computer slowing down much.
3. Run batch simulations as quickly as possible
Set Performance Mode to Batch. Set Threads to 1.0. This will use all of your processors.
4. Run batch simulations in the background
Set Performance Mode to Batch. Set Threads to 0.5. This will use half of your processors.
You can use the simulator client web page to generate a new settings.json file whenever you want to change settings. But if you are comfortable editing json files directly in a text editor, feel free to modify the settings.jon file directly.
Note that the only way to get your user token is to download the settings.json file at least once.
For people looking to squeeze more performance out of their simulator client, here is a little more detailed explanation and some more settings that you can change.
Firstly, this only really matters for Batch mode if you are running larger Test Combinations simulations, or trying to maximize the throughput of the global network.
In Single mode, the client starts a single worker. This worker will sit idle until a simulation is submitted. Then it will download the setup, do the simulation on the number of threads specified, aggregate the results and upload it to our servers. You will never get 100% CPU utilization with a single worker – it takes some amount of time to download the setup and upload the results, and during that time your CPU is not very busy.
In contrast, Batch mode will start multiple workers on the same machine. The advantage of this is that while one worker is downloading/uploading, another worker can be using the CPU to run simulations.
We have found through testing that running more than 8 threads per worker doesn’t tend to improve performance much when running large batches – it is better to run more workers with 8 or less threads. Thus if you enter a number of threads greater than 8 in Batch mode, the client will start more workers with less threads.
You can go up to 2x your computer’s processor count (where “processor count” means the virtual processor count, e.g. most 4-core CPUs have 8 virtual processors, so you could go up to 16). Every computer performs a little differently – feel free to play around with it until you hit on something that works well for you.
Some real world examples of machines that we own and try to max out:
- 8-core Ryzen: 24 threads (three 8-thread workers)
- 12-core Xeon: 32 threads (four 8-thread workers)
- 6-core i7: 16 threads (two 8-thread workers)
If you are not comfortable editing configuration files directly in a text editor, or this section is confusing to you, don’t mess with it!
Our simulator client is written in C# using .net core, which is a managed programming language. Managed languages run a background process called a “garbage collector” that cleans up memory as your program runs. .net core provides two “flavors” of garbage collection that can have a significant impact on performance.
By default, we ship the client in “workstation” mode. The other mode is “server”. If you are looking to maximize performance, you can try out server mode. To enable this, you need to modify the
simclient.runtimeconfig.json file. Open it in a text editor and find the following setting:
true to enable server mode. It may or may not make your simulator client run faster – feel free to experiment. The more cores you have, the more likely it will improve speed.
NOTE: Server mode uses a LOT more memory. Like, a LOT more. It is designed for scenarios where all of the machine’s resources are available for the program, and it doesn’t have to share with anyone else.
To put this in perspective, on a machine with a 8-core Ryzen 7 1800X, client configured for 24 threads in batch mode, workstation mode consumes about 200 MB of memory when busy, server mode consumes about 2.5 GB of memory when busy. But, I was able to run batch simulations almost 1.7x faster!
We will update this section with answers to any frequent questions that we see about the simulator client. If you have a question or issue with the simulator client that is not answered by this manual, please make a new post to ask your question.