search

JKorf / Binance.Net

A C# .netstandard client library for the Binance REST and Websocket Spot and Futures API focusing on clear usage and models
https://jkorf.github.io/Binance.Net/
MIT License
1.04k stars 428 forks source link

Auto handling Time offset breaks my program #505

Closed Amannda123 closed 3 years ago

Amannda123 commented 3 years ago

Hi,

so my tool is working pretty fine since im using tasks for everything, because it has to be quick. During high volatility it starts spamming the errors mentioned below. After some investigation i found the cause (i think) every time i see the following lines, and some action is going on it produces these errors:

2020.11.25 06:55:03:140 | Info | Time offset between 0 and 500ms (118,5636ms), no adjustment needed 2020.11.25 06:55:08:738 | Info | Time offset between 0 and 500ms (117,44ms), no adjustment needed 25.11.2020 06:55:08 - - GetTotalWalletBalance - Error retrieving balance Object reference not set to an instance of an object.

Or most of the time when the offset has to be set:

2020.11.25 16:03:20:602 | Info | Time offset set to 657,5812ms 25.11.2020 16:03:20 - - Snipe -Object reference not set to an instance of an object.

I know you dont know my code but either i call for the current open positions or i call for my balance via api. is there any way to handle or prevent this? or make it thread/task safe.... or do you need further informations?

thanks in advance

JKorf commented 3 years ago

Hi, you can turn off the auto time syncing by setting AutoTimestamp to false, see if that helps

Amannda123 commented 3 years ago

out of the sky i would say that will help at least prevent from breaking... but at what cost? offset getting huge some times.. up to 5-7000 ms

JKorf commented 3 years ago

Multiple people having had issues with timestamping have started using the SP TimeSync utility with success. With that program your computer time gets synced every x period, preventing you computer time from differentiating too much from the server time. People have been using it with an interval of 10 minutes to get rid of any clock skewing.

For my info, do you have any details where that null reference is coming from?

Amannda123 commented 3 years ago

i heard about that sync tool.. but i wonder if it helps since this problem only occurs on high volatility. ususallly my time is fine... but i will test it for sience 😀

if you mean the api functions im calling (code simplified) : using this on accountupdate (user data stream) var balance = this.getAccountInfo().Data.TotalWalletBalance; and var position = this.FuturesUsdt.GetPositionInformation(Symbol, RECEIVEWINDOW, token);

dont know if its actuall the function call or use of the variable afterwards.. ... if you want the full stack trace let me know, have to change the logging to print that as well

Amannda123 commented 3 years ago

Just leaving this here: Did some investigation on the logs from my colleague using my software on a bit less powerfull cpu.. To me this doesnt seem normal... in that short amount of time (2 seconds) so much offset corrections... isnt it supposed to only do this every 10 minutes? or does this get checked every api call? its a hosted root server on a big provider around here.. so i doubt its network issues.. is it a problem that we just throw everything in a task and let it run?

2020/11/26 08:30:10:994 | Warning | [18056] Request timed out 2020/11/26 08:30:10:996 | Warning | [18049] Request timed out 2020/11/26 08:30:10:997 | Warning | [18050] Request timed out 2020/11/26 08:30:10:998 | Warning | [18051] Request timed out 2020/11/26 08:30:10:999 | Warning | [18054] Request timed out 2020/11/26 08:30:10:999 | Warning | [18048] Request timed out 2020/11/26 08:30:10:999 | Warning | [18057] Request timed out 2020/11/26 08:30:11:001 | Warning | [18045] Request timed out 2020/11/26 08:30:11:001 | Warning | [18046] Request timed out 2020/11/26 08:30:11:001 | Warning | [18052] Request timed out 2020/11/26 08:30:11:221 | Info | Time offset set to 11432.8718ms 2020/11/26 08:30:11:224 | Info | Time offset set to 11441.9402ms 2020/11/26 08:30:11:227 | Info | Time offset set to 11440.0954ms 2020/11/26 08:30:11:229 | Info | Time offset set to 11441.9965ms 2020/11/26 08:30:11:246 | Info | Time offset set to 9691.6696ms 2020/11/26 08:30:11:246 | Info | Time offset set to 11454.586ms 2020/11/26 08:30:11:246 | Info | Time offset set to 10694.0827ms 2020/11/26 08:30:11:246 | Info | Time offset set to 6190.0493ms 2020/11/26 08:30:11:248 | Info | Time offset set to 3189.4784ms 2020/11/26 08:30:11:248 | Info | Time offset set to 4190.8196ms 2020/11/26 08:30:11:248 | Info | Time offset set to 7693.0999ms 2020/11/26 08:30:11:249 | Info | Time offset set to 7193.6615ms 2020/11/26 08:30:11:249 | Info | Time offset set to 5163.8994ms 2020/11/26 08:30:11:249 | Info | Time offset set to 8695.0897ms 2020/11/26 08:30:11:250 | Info | Time offset set to 2185.3576ms

JKorf commented 3 years ago

This doesn't seem right, I agree. It's probably because the AutoTimestamping isn't really thread-safe. At the start of a request it checks if auto time syncing should be done. After syncing the variable gets updated. When multiple requests at the same time make a request at the moment a sync should be done they all think that time syncing has to be done.

Amannda123 commented 3 years ago

Do you see any chance to improve this or should i just go with the autotimestamp= false? currently swtiched it back to ture, because i made many improvements so i dont pull api that frequently anymore ...

JKorf commented 3 years ago

AutoTimestamp is more of a quick way to get started when you don't want to have to deal with server times and I don't know what, but releasing/using actual trading software the best way is to make sure the server is syncing time as it is more accurate.

So I might look into it in the future, but I don't have any plans to improve it at this point.