[Passed] LiquidBits term 5 grant - Automatic Liquidity Pool (ALP)

NuShares Passed Grants
#81

That is not great. Did you try to ask for e.g. 0.01%? My experience that it does swap/auction funds better if not zero, but haven’t done a lot of testing with it. At least I always get paid something.
Vaguely recall that Creon said something that it would be better to set a minimum, not sure if it was related to this though.

From what I see is that the system doesn’t actively put liquidity on tier 2 when higher than the target. All liquidity is on tier 1, except you are sharing the payout with the competing LPs reducing the payout.

#82

as far as i understand how the dutch action works, if for example the target is 5k and total custodian amount is 10k in the alp, then all 10k are set in the pool during the day in a turn based manner.
then for above example, instead you earn the full 0.24% rate, you will earn a smaller rate.
see pool in bittrex right now (current rate < max rate)

Exchanges bittrex
Monthly interest rates 5.3999999999999995%
Max ask rate 0.24 % per day
Max bid rate 0.24 % per day
Current ask rate 0.18 % per day
Current bid rate 0.18 % per day
Ask order target 11256.96 NBT filled of maximum 5000 NBT ( 225.14% )
Bid order target 12090.87 NBT filled of maximum 5000 NBT ( 241.82% )

#83

Server is down? Caught the bug this time?

#84

Wish it was true, just adding new tracing/logging code after the payout, but getting errors with the new code. Might have to reverse out…

#85

Code fixed (typo), running with new traces. Hope the next crash will result in something more meaningful. Hope it happens soon as this creates a lot more logging clearly.

#86

I just noticed that the bot performance have been fixed on the CCEDK side. They are now close to 100%. If any time, now is good time to try again and confirm whether you still have the problem. Maybe you can share part of the logs in PM as I can’t replicate your problem.

#87

I have changed 0 interest to non-zero. The problem seems to have gone. Thanks. Maybe the server side improvement also played a part.

1 Like
#88

Will restart server.py after automatic payout in 20 minutes or so. The added logging doesn’t work satisfactorily and I will try another approach involving off-VPS logging of terminal output.

Edit: automatic payout occurred, restarted and up and running again.

#89

All right, after 3 days without interruption and automatic payouts without issues I like to think that the issues we have seen in the last fortnight were indeed related to the CCEDK API behaving badly. This has been addressed 4 days ago and stable since. Hope LiquidBits can regain some trust as I have seen some users leave for probably this reason.

1 Like
#90

is the API corrected somehow?

#91

Yes, some ‘magic’ happened. Will keep a close eye on things though.

1 Like
#92

server down?
edit: no, its up. some bad connection issues i guess

#93

About 8 hours ago the balance stopped counting yet everything else seems to be working.

#94

Confirmed. This is a new ‘bug’, haven’t seen this behaviour before. Just restarted the server. Will have a look in the logs whether I can find something unusual. It seems to be counting again for now.

1 Like
#95

Looked at the logs and actually it is an old one back again:

2015/11/01-22:39:15 ERROR: exception caught in main loop: dictionary changed size during iteration.

This time with different behaviour. However the logs are empty after this error, the main loop clearly exited in some odd way. Not sure what to do about this. Trapping this error seems to be very difficult as it is random and only happening once in a number of days. The server have been stable for more than a week since the last reset due to a similar error.

I hope that the new NuBot and server software is going fix all this. I’m for one are really looking forward to that!

#96

Here are some tips debugging python. pdb is good for catching exceptions. But if you find it too complicated, a logger may just be what is needed.

I wonder if the server uses the logging module to produce detailed logs? @woolly_sammoth

Besides the logging module, another way mentioned is running the server like

python -m trace -t server.py > execution.log

it will display lines as they are executed.

#97

The server does provide detailed logs using the logging module. Unfortunately the way the main loop is set up it catches all exceptions at all points of the execution of the program. That makes tracking down the cause quite tricky. More so when it’s not easily reproducible.
I’m afraid that my main efforts of recent weeks have been in producing the new version of the server software which will hopefully alleviate these issues (or at least make it easier to track them down when they do occur).

2 Likes
#98

Thanks. I just tried the line number tracing method with client.py

python -m trace -t -g client.py ...xxx... > execution.log 2>&1

This will produce a big trace log (at 3 MB every 10 sec when I tried with client.py) mixed with error messages. If the vps has 100 GB disk space that is enough for a week’s logging. If this is used with the server, next time when the exception happens, search the exception’s name backward from the log’s end

not sure performance impact on the ALP server tho

#99

There is only a 30GB VPS and a lot has been used by current logging and besides the risk of running out of disk space after a few days we indeed have no idea whether it affects the performance.

I have two options from here; meddle through and wait for the new version or basically cease operations and put the server at risk likely causing people to walk away. Not knowing the root cause this may ‘fix’ the problem we are seeing so not a great option.

I think it is best to wait till woollysammoth has a new version. Hopefully soon. Open to better ideas.

2 Likes
#100

That is fine. It was just some thoughts to share.

1 Like