Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bobcat rate limit #6

Open
droidkfx opened this issue Jul 8, 2022 · 1 comment
Open

Bobcat rate limit #6

droidkfx opened this issue Jul 8, 2022 · 1 comment

Comments

@droidkfx
Copy link

droidkfx commented Jul 8, 2022

What happened

When using this exporter it seems to rather regularly fail to fetch temperature data because it receives a 429 response. I can reproduce this issue at polling intervals all the way up to 1m so I am pretty sure it is not the scraping frequency that is the culprit.

time="2022-07-08T00:08:26Z" level=error msg="Can't scrape /temp.json: HTTP status 429" source="main.go:205"
time="2022-07-08T00:09:26Z" level=error msg="Can't scrape /temp.json: HTTP status 429" source="main.go:205"
time="2022-07-08T00:10:26Z" level=error msg="Can't scrape /temp.json: HTTP status 429" source="main.go:205"
time="2022-07-08T00:11:26Z" level=error msg="Can't scrape /temp.json: HTTP status 429" source="main.go:205"

Debugging

I did some debugging and I think the issue is the tight loop that this exporter uses. I think, and this is sorta ironic, that the code executes the call to /temp.json too soon after calling /status.json.

In some cases, 429 errors come with a Retry-After header that could be used to space out the requests but I don't see that in the response from the miner.

temp 429 headers

I went looking for documentation from bobcat but I can't seem to find any details on the miner HTTP server or how it is configured...

By testing, I found the limit, at least on my miner, could be as low as 1 request per 1.5s!

temp 429

Possible solution

I think there are a couple of things that could be done:

  • The fetch routine could be improved to have a retry with a back-off
  • There could be a configurable constant sleep time for requests (seems questionable to me)
  • The fetching could be done in the background instead of on-demand. I think this is "best" but does not really fit with what you had going here. It also adds a lot of complexity.

I mention the above because I am happy to do any of them but since this is not my project, and I don't wanna fork it, I wanted to see what you the author thought.

Let me know and if I have some time I may send a PR your way.

Take care!

@droidkfx
Copy link
Author

droidkfx commented Jul 16, 2022

Also just learned that as of the time of writing the status.json endpoint is being removed. As of:

Bobcat Firmware version updated to 1.0.3.1
Helium Firmware version updated to 2022.07.14.0_GA

Bobcat miners will be lite so they will not have a sync status. Syncing will be done by validators I guess... So the above might be a non-issue. The only metric you can really track without impacting the bobcat would be the temperature.

Details if interested: https://shop.bobcatminer.com/blogs/all/bobcat-ota-update-blockchain-sync-turned-off-7-15-2022

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant