Continuing the discussion from Dealing with gateways in particular and liquidity provision in general.
I thought it might be good to share some background information.
This might not really be a guide for the whole setup, but will help with the first step.
This is from a private conversation I recently had, when a community member was interested in details about running gateways:
I run those on a RaspberryPi2 (1 GB RAM) along with nud to make maintaining the system easy (I only need to backup one SD card to have a full backup).
I could put all on a virtual server, but I’m too paranoid to put private keys of custodial addresses on a virtual server as such a private key in the wrong hands might make some trouble.
And without the custodial address broadcasting the liquidity information isn’t possible, but as pool operator you know that.
So what have I done to create the gateways?
I’ve created dedicated Poloniex accounts, one for each gateway, to have separate API credentials (both with 2FA, API credentials are only allowed to do order management, but no withdrawal).
I’ve created a blank wallet (walletB.dat) and imported the private keys of the custodial addresses.
I’ve downloaded NuBot and created two directories - one for buy side, one for sell side NuBot.
I’ve created configs (there’s sample configs in the config directory) for each NuBot.
That’s pretty much it.
I had some trouble running the gateways with configuration setting "dualside": false, although that’s what I want to do. I had to limit the side, where I don’t want to have orders on, to 0.0 to make the gateways run fine.
And I don’t know why the parametric order book is effectively disabled and only one order is being placed (with my settings I’d expect to have two orders), but as I consider this a minor issue, I didn’t dig deeper to resolve this issue.
It turned out that there is already an issue raised for that.
I run the NuBots in screen sessions.
That allows me to detach from them and attach to them later.
The logs created by the NuBots are quite exhaustive. If you run the NuBots for some days, you will have hundreds of MB logs.
That’s a problem for my RaPi2 (which more than once caused crashes of nud due to low disk space) and for that reason I switched the gateways for most of the time to standby a few days ago.
One remark about crashed nud: if nud crashes, the broadcast liquidity can’t be reset when NuBot gets shutdown.
The liquidity for that session needs to be reset manually:
nud liquidityinfo B 0 0 BBZ4h88BwYCyE9q268LoArps6eodq9PDGH $nubot_sessionWith nud requiring over 700 MB, it’s close to the limit of the RaPi2 to run nud and NuBot instances on the same machine:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2377 pi 20 0 878m 697m 37m S 60.9 71.6 2199:27 nudI hope this gets better with version 2.1.
An instance of NuBot needs a little bit over 100 MB RAM and a lot of CPU power during startup and on wall shifts, but very little CPU power most of the time:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9750 pi 20 0 325m 120m 8364 S 0.0 12.3 9:02.87 javaIf you have any questions, feel free to ask.
The config below might help you get started.
An explanation of the options can be found here
Following are the config files. They have been reworked massively over time.
This is the most recent configuration at the time of writing, which seems to do the job quite well:
