Skip to content
This repository has been archived by the owner on Feb 15, 2022. It is now read-only.

Error suppression workaround #870

Closed
wants to merge 2 commits into from
Closed

Error suppression workaround #870

wants to merge 2 commits into from

Conversation

ghost
Copy link

@ghost ghost commented Dec 14, 2017

Suppresses the illusion that your client is not working right.

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
@ghost
Copy link
Author

ghost commented Dec 14, 2017

Side note: gdax update_products.js needs to be run.

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
@ghost
Copy link
Author

ghost commented Dec 14, 2017

Want another note here:

FTR my current settings (that dont seem too too volatile working with this is below:

// sell if price drops below this % of bought price (0 to disable)
c.sell_stop_pct = 0
// buy if price surges above this % of sold price (0 to disable)
c.buy_stop_pct = 0
// enable trailing sell stop when reaching this % profit (0 to disable)
c.profit_stop_enable_pct = 0
// maintain a trailing stop this % below the high-water mark of profit
c.profit_stop_pct = 1

// Order execution rules:

// avoid trading at a slippage above this pct
c.max_slippage_pct = 5
// buy with this % of currency balance (WARNING : sim won't work properly if you set this value to 100)
c.buy_pct = 100
// sell with this % of asset balance (WARNING : sim won't work properly if you set this value to 100)
c.sell_pct = 100
// ms to adjust non-filled order after
c.order_adjust_time = 10000
// avoid selling at a loss below this pct set to 0 to ensure selling at a higher price...
c.max_sell_loss_pct = 25
// ms to poll order status
c.order_poll_time = 3000
// ms to wait for settlement (after an order cancel)
c.wait_for_settlement = 3000
// % to mark down buy price for orders
c.markdown_buy_pct = 0.33
// % to mark up sell prie for orders
c.markup_sell_pct = 0.28
// become a market taker (high fees) or a market maker (low fees)
c.order_type = 'maker'
// when supported by the exchange, use post only type orders.
c.post_only = true

// Misc options:

// default # days for backfill and sim commands
c.days = 14
// ms to poll new trades at
c.poll_trades = 1000
// amount of currency to start simulations with
c.currency_capital = 5000
// amount of asset to start simulations with
c.asset_capital = 0
// for sim, reverse time at the end of the graph, normalizing buy/hold to 0
c.symmetrical = false
// number of periods to calculate RSI at
c.rsi_periods = 14
// period to record balances for stats
c.balance_snapshot_period = '15m'
// avg. amount of slippage to apply to sim trades
c.avg_slippage_pct = 0.045
// time to leave an order open, default to 1 day (this feature is not supported on all exchanges, currently: GDAX)
c.cancel_after = 'day'

@ghost
Copy link
Author

ghost commented Dec 14, 2017

There's definitely maybe something going on in c.wait.for.settlement, though, if I am correct, this is the correct functioning. Maybe there needs to be more variables in wait_for_settlement spaced out for each call. Such as:

c.buy.retry.settlement
and
c.sell.retry.settlement
and
c.getquote.retry.settement
and
c.gettrades.retry.settlement

This, or that there NEEDS to be some sort of promise function that way all the calls are not piling up on the c.wait.for.settlement or the retry function in strategy.js
IE

promise(timeout { function (buy) } c.buy.interval)
(in lazy-nodejs)

I am not 100% sure of the code workings, but, I guess this would be within gdax's API limit with those settings above. But all the while, this heavily depends on the public and private API endpoints, even then so, GDAX public api has like 3 calls per second, and private has like 6 in burst.

PUBLIC ENDPOINTS

We throttle public endpoints by IP: 3 requests per second, up to 6 requests per second in bursts.

PRIVATE ENDPOINTS

We throttle private endpoints by user ID: 5 requests per second, up to 10 requests per second in bursts.

This would make no sense unless there wasn't a promise statement or there was a flood happening in the code piling up in a function. Maybe, like I said, the promise must happen before the timeout.

@DeviaVir DeviaVir closed this Dec 28, 2017
@DeviaVir DeviaVir reopened this Dec 28, 2017
@DeviaVir DeviaVir changed the base branch from master to unstable December 28, 2017 16:58
@JensvdHeydt
Copy link
Contributor

I really don't think that removing the console.error calls is a very good workaround here. Please don't!

@ghost
Copy link
Author

ghost commented Dec 30, 2017

I agree to an extent. Thanks. (not sure if that other PR went through, but, if there is any more PR's from me they will be a few days until I am back on my feet since I basically broke my neck the other day rofl)

This pull request was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants