0 buy side liquidity currently: {“credits”: 37628, “users”: 11, “validations”: 451543, “liquidity”: [0.0, 7938.904999999996], “sampling”: 12}
why is the pybot of bittrex not picking up any bid orders? Has been 0 for a while now…
ask orders are fine though…
HI @PinkyAndTheBrain. Thanks for the heads up. I’m investigating now. I know there is a bug which causes the bot to not place all balance on order when certain conditions are met. I think the changing BTC price may be causing those conditions to be met more often.
Restarting the bot normally fixes the issue but is far from ideal. I’m hoping that the coming NuBot release will cure a lot of the issues we are seeing with the current implementation
Edit: There was a low hanging ask order that was preventing bid orders from being placed. I’ve cleared that now and (hopefully) the client should act normally now.
Yah, I implemented an automatic restart on the tllp client because of stuff like this. The bugs in our tllp system are a little embarrassing, but I’m also hopeful that fixing issues farther down the line will cure some of these bugs.
2 Likes
I agree. The issue is that the bugs are all in the portion of code that is most complicated and lacks explanation. The NuBot update does address a lot of the issues but will, I’m sure, add a few issues of it’s own. I’m concentrating on that release as a priority now.
2 Likes
How do you restart the tllp client automatically without just killing the process (which doesn’t delete the orders as it’s no clean shutdown)?
All my bots (I have one at liquidbits, nupondCNY and nupool 
) are running remarkably stable at the moment, but I’d like to know anyway.
1 Like
At the moment that’s it I’m afraid. If you are running on just a single exchange and running the TLLP client in the traditional way it should shutdown cleanly and cancel the orders. The issue arises if you run the client in the background with `nohup`` and the like, or using the run_client script for multiple exchanges. Then the shutdown is forced and the orders aren;t cancelled.
I’ll add this need to the todo list for the next release.
So at the moment something like this is the best you can do?
#!/bin/bash
echo "starting nupool in the background"
function background_loop
while :; do
pkill -f client.py
~/apps/nupool/unix/client >/dev/null 2>&1
sleep 600
done
background_loop &
I would very much welcome you putting other ways of shutting down a tllp client to your todo list
…this would provide an even better liquidity, because tllp bots wouldn’t go nuts and kepp the funds off the order book…
2 Likes
my usual tactic is to get the main loop of an application to check the existence of a file in the file system (usually just called ‘run’). The application creates that file on startup and then stops if it is missing for any reason. You can then just remove that file to stop the application even if it’s running in the background.
I’ll definitely bump this up the todo list as it should be fairly easy to accomplish.
I have played with two ways of running a tllp bot
- running it within a screen session and connect to it from time to time to check the status - being able to shut it doewn properly if need be
- running it in the background with periodic restarts - no real interaction and no way to check the status without looking at the exchange
My conclusion is:
even if the tllp bot sometimes goes nuts and needs to be restarted this is the lesser evil. I faced legions of stranded 1 NBT orders that remained after killing the tllp bot (instead of shutting it doen properly). As they weren’t removed after the tllp bot started again they piled up until I noticed that.
Deleting them was something I don’t want to do again soon I rather have a tllp bot that doesn’t provide liquidity for some hours or a few days.
A config parameter to recycle the tllp bot after a given time would be great!
But before I sidetrack the topic, I give you the feedback that the last run of my nupool tllp bot was from
2015/06/28-11:19:44 to
2015/07/05-23:56:12
and only ended because of a power outage at my RaspberryPi.
I added this to tading.py:
try:
totime = time.time() - self.startime
if totime > (self.restime*3600):
python = sys.executable
os.execl(python, python, * sys.argv)
except:
print “issues restarting bot”
I’ve been using this for a while, I made it a config parameter, and it works alright for a workaround. https://github.com/Nagalim/nu-pool
Does it place the orders and just not validate them? I have been suspicious of nupool’s 0.0085 tolerance since I had trouble getting my bot to work on poloniex. I’m wondering if the nupool price feed is off for some reason, so it validates orders that are higher than the price but fails at validating lower than the price.
@masterOfDisater - that’s some run! a config parameter to recycle the client is a good idea and one that I’ll look into.
@PinkyAndTheBrain - there are still ask orders on Bittrex that are lower than the tllp calculated bid price. That is causing the client to not pace orders as they are being run with ordermatch = False.
I don;t have enough funds to clear the ~22BTC worth of orders that are causing the block. Similar things did happen in the early days of NuPool and we found that they do tend to clear as the BTC price moves. If anyone wants to help out, you can run your client with ordermatch = True in your config. This will force the bid order to be placed and filled immediately with the low priced NuBits. It means you get NuBits for a lower price than that calculated by NuPool which may be what you want but may not be. I have set this as the default behaviour in the next release.
There have not been any changes to the price feed code on NuPool and the settings are exactly as they have been for the last 2 operations.
how much sell side is being validated on bittrex? Are we sure that block isn’t being caused by a rogue tllp bot? If it’s someone actually selling that much nbt, fine, but I can’t help but think that’s a lot of nbt.
So it’s not a rogue client then, just an ordermatch thing. 8,000 sell side, all around .00377, then another 4,000 around .00372.
Check status - you just need to save the output to a log file (instead of > /dev/null ) and look at the tail to see recent status (and history) when you want.
Without the
>/dev/null 2>&1part it’s not possible to run the tllp bot in the background.
Checking for logs in unix/logs is always possible to check the status, but less convenient than running each tllp bot in its own screen session.
At the risk of derailing this thread (please don’t read further unless you are interested in running tllp bots on a RaspberryPi ):
my current tllp bot operation model deals with 3 screen sessions and automatic output of the last lines of the current log files on demand.
One script starts the screen sessions that are named and where the path is set to start the tllp bot with simply executing “./client” (I haven’t found out how to execute commands within a screen session to automate starting the tllp bots):
cd ~/apps/liquidbits/unix/
screen -dmS liquidbits
cd ~/apps/nupool/unix/
screen -dmS nupool
cd ~/apps/nupondCNY/unix/
screen -dmS nupond
screen -dmS poolinfo
And this script - executed from within the “poolinfo” screen - gives a convenient overview of the status of the tllp bots:
#!/bin/bash
liquidbitsdir=~/apps/liquidbits/unix/logs/
liquidbitslog=`ls -t $liquidbitsdir | head -n 1`
nupooldir=~/apps/nupool/unix/logs/
nupoollog=`ls -t $nupoolclientdir | head -n 1`
nupondCNYdir=~/apps/nupondCNY/unix/logs/
nupondCNYlog=`ls -t $nupondCNYdir | head -n 1`
echo "#########################################################################################"
date
echo "### liquidbits ###"
echo $liquidbitsdir$liquidbitslog
tail -n 2 $liquidbitsdir$liquidbitslog && echo
echo "### nupool ###"
echo $nupooldir$nupoollog
tail -n 2 $nupooldir$nupoollog && echo
echo "### nupondCNY ###"
echo $nupondCNYdir$nupondCNYlog
tail -n 2 $nupondCNYdir$nupondCNYlogPrinting the current log file into the output of poolinfo makes it easy to dig deeper in the log files without first searching for the most recent one.
These two scripts with only a few lines make it very easy to run and check the tllp bots.
…just in case somebody is interested in it…
any thoughts on tmux vs screen?