I see. Do you remember the difference between PyBot and NuBot?
I suppose FC ALPs will be using something close to PyBot but in that case how can the parametric order book that will be implemented in the next NuBot version be implemented and used?
NuBot is currently only working for MLPs (e.g. NuLagoon; soonTM maybe my NuBot on hitBTC).
PyBot is currently only working for ALPs.
NuBot has been soundly developed ever since development was started.
PyBot is hacked together code (correct me if Iām wrong) that acts as a proof of concept for an ingenious concept, invented by @creon: the automated liquidity pools (formerly known as TLLP - trustless liquidity pools).
NuBot requires a lot of CPU power.
[edit] But as I found out a few minutes ago: only if being run in server mode; without server mode CPU load looks like thison my RaspberryPi 2 (4 CPU cores):
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22483 pi 20 0 321m 60m 10m S 101.8 6.2 9:14.09 java
2337 pi 20 0 680m 559m 32m S 32.7 57.5 5357:27 nud
If you donāt need the server mode (maybe because you run it on a headless RaspberryPiā¦), NuBot is more CPU friendly than with server mode and can run very well on RaspberryPi 2,maybe even on a RaspberryPi 1 (although thatās close to the limit of it)!
[/edit]
PyBot doesnāt require much CPU power.
Exactly that - with an adjusted server.py thatās called fc_server.py.
@woolly_sammoth is working on a solution that will integrate NuBot into the ALP client:
That should give ALP clients the same features NuBot has.
If you intend to run NuBot on a RaspberrPi, I recommend to get a RaspberryPi 2. The CPU load NuBot causes is at average on 75% on a RaspberryPi 2.That means 3 of 4 cores are constantly busy.
Hereās output from top
:
top - 06:53:04 up 8 days, 9:26, 2 users, load average: 5.16, 5.21, 5.14
Tasks: 91 total, 1 running, 90 sleeping, 0 stopped, 0 zombie
%Cpu(s): 67.0 us, 3.1 sy, 6.6 ni, 21.7 id, 1.4 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem: 996848 total, 982224 used, 14624 free, 52212 buffers
KiB Swap: 102396 total, 1540 used, 100856 free, 191224 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2929 pi 20 0 338m 132m 11m S 277.4 13.6 2245:14 java
2337 pi 20 0 680m 564m 37m S 28.0 58.0 4120:01 nud
You could move nud to a different machine to reduce some CPU load (nud is required for broadcasting liquidity information into the network).
PyBot on the other hand causes single digit CPU loads:
top - 06:49:33 up 26 days, 14:26, 2 users, load average: 1,64, 1,41, 1,42
Tasks: 7 total, 0 running, 7 sleeping, 0 stopped, 0 zombie
%Cpu(s): 4,2 us, 2,8 sy, 1,8 ni, 91,0 id, 0,0 wa, 0,0 hi, 0,3 si, 0,0 st
KiB Mem: 998176 total, 974844 used, 23332 free, 17308 buffers
KiB Swap: 102396 total, 7028 used, 95368 free, 145900 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
26259 pi 20 0 64036 10m 5912 S 4,7 1,1 125:46.88 python
22490 pi 20 0 63832 10m 5968 S 4,0 1,1 18:00.29 python
socket error (111)
any change?
The server kills itself every night because I donāt have nud on. Iāll restart it tonight. This will not be an issue once Iām operating on nupond instead of a test server.
Tks for the tip about Pi.
So right now more than half of the liquidity is provided by a bot behavior different from NuBot. Doesnāt make NuBot as half
Valuable? If Pybot is lighter than Nubot, doesnā t it make Pybot more efficient than Nubot and shouldnāt it make it the main bot?
I m trying to see to which extent Nubot is crucial to Nu.
I guess the answer is in the parametric order bookā¦
Pybot is a server-client pair. Nubot is everything in one. They are different programs with different goals in mind, and both are useful if not vital to Nu.
Iām very happy to finally see this idea articulated well and so I am voting for this proposal. I suggested the beginnings of a similar idea back in March but this is more relevant as I was considering the operator fee and requested funds as the same amount.
This is a superior method of purchasing liquidity that will balance liquidity targets and encourage lower interest rates.
Thanks for bringing this interesting discussion up. I think given long enough time and a static boundary condition all models will converge to the same interest rate. The feedback loop of the fixed cost scheme is much shorter, making price discovery much faster, giving us a more agile system in a volatile market.
If this succeeds and reduces costs in the long-term, credit is due to yourself, Nagalim, Masterofdisaster, and all others who brought the idea to life here: Fixed total payout for liquidity providers to enhance liquidity security and pool operation.
running the test client again
Hi @cryptog
Here are the details for the Motion Vote on 187e547074c3fe0508a56d684dd705ec5d9929ee:
##187e547074c3fe0508a56d684dd705ec5d9929ee
Blocks: 604 (6.040000%
)
Share Days: 243446099 (7.048140%
)
Vote for this only if you think fixed cost should be explored experimentally using shareholder funds. It will not affect the total requested funds of NuPond Term 5, but is only proposing an alternative reward protocol, and only on the NBT/BTC pair.
Voted
Hi @huafei
Here are the details for the Motion Vote on 187e547074c3fe0508a56d684dd705ec5d9929ee:
##187e547074c3fe0508a56d684dd705ec5d9929ee
Blocks: 820 (8.200000%
)
Share Days: 320881621 (9.325522%
)
Hi @cryptog
Here are the details for the Motion Vote on 187e547074c3fe0508a56d684dd705ec5d9929ee:
##187e547074c3fe0508a56d684dd705ec5d9929ee
Blocks: 1630 (16.300000%
)
Share Days: 669965972 (19.597495%
)