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

cpuminer-opt API #256

Closed
JayDDee opened this issue Mar 16, 2020 · 4 comments
Closed

cpuminer-opt API #256

JayDDee opened this issue Mar 16, 2020 · 4 comments

Comments

@JayDDee
Copy link
Owner

JayDDee commented Mar 16, 2020

I have avoided messing with the API because I'm not a web programmer. The enhanced statistics
now reported to the console would be very useful if accesible through the API.

There are several miners with APIs and I;m sure some are better than others. There may also
be some quasi standards for miner APIs.

This issue is opened for suggestions on improvement. Examples of the best existing
implementations, preferably with open source code would be great.

Ideas on how the statistics should be provided are also welcome. The ability to stream the data
rather that the existing one shot command would be nice, but I would probably need some
technical help with that.

One addition I intend to make is version control to facilitate changes without forcing users to
upgrade their scripts promptly.

The floor is open.

@JayDDee
Copy link
Owner Author

JayDDee commented Mar 17, 2020

One if the big concerns about adding more features is the impact on mining performance.
Adding a streaming feature to the API would likely have an impact.

Instead it might be preferable to use a pipe to redirect miner output to an external program
that could parse the data for analysis or transmission to a remote manager.

The key would be a stable output format with certain requirements to aid parsing while
maintaining human readability. This would avoid any additional overhead in the miner.

@YetAnotherRussian
Copy link

Up to 90% of users do disable the API in xmrig/xmrstack (some forks even generate config files with disabled api by default). The rest (powerful miners) uses HiveOS or similar (so there is no interest in miner api as well). My guess is that "avoided messing with the API" was the right way of doing things there.

Not bad API is here: https://github.com/Bendr0id/xmrigCC/tree/master/src/base/api (though some issues have been fixed in the parent repo).

[offtopic] Sorry for being aware of #246, I was out for a week, but now I cannot sync, the test coin seems to be down, even resync from scratch does not help, or maybe I got banned @ nodes (I still see the pool being alive though). I'll search for another low-hr victim somewhen between this and then. There're some I currently hang on, but you've dropped cryptonight support (so I see no reason in testing with a veeery old releases).

@JayDDee
Copy link
Owner Author

JayDDee commented Mar 20, 2020

Using the API as as seperate data stream is inefficient. A better approach might be to use
a pipe to redirect stdout to another program that can parse the data and process it as
it pleases.

If the current data is machine readable as well as human readable in its curent form
then no changes would be required to the miner and all overhead would be borne by other
programs.

@JayDDee
Copy link
Owner Author

JayDDee commented Mar 25, 2020

I'm closing this. There doesn't seem to be much interest and I don't have a clear vision or direction.
Any attempt at a streaming feature would add additional overhead that would affect performance.

@JayDDee JayDDee closed this as completed Mar 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants