Discussion of development releases of Prohashing / Requests for features
Forum rules
The Development forum is for discussion of development releases of Prohashing and for feedback on the site, requests for features, etc.
While we can't promise we will be able to implement every feature request, we will give them each due consideration and do our best with the resources and staffing we have available.
For the full list of PROHASHING forums rules, please visit
https://prohashing.com/help/prohashing- ... rms-forums.
-
Steve Sokolowski
- Posts: 4585
- Joined: Wed Aug 27, 2014 3:27 pm
- Location: State College, PA
Post
by Steve Sokolowski » Fri Aug 14, 2015 9:16 am
I wanted to get final comments before I implement the worker data improvements tuscondirect and two others have requested this weekend.
After some research, I propose the following:
- Instead of being deleted as it is now, historical worker data will be stored every minute, resulting in a total of about 100 million rows in the table with current usage.
- The worker history will be purged every Monday before the full database backups, retaining 4 weeks of data.
- On the "details" view of the worker status screen, a button will be available to generate a chart of various worker parameters over time. Generating the chart will take a long time and require 10MB bandwidth, so it will only be available by clicking the button.
- The charts will allow users to zoom in to a 1-minute granularity to see values of hashrate, work restart time, difficulty, and all the other values. They can also be zoomed out to see the full 28-35 days of data.
- To save disk space for users who don't care about this data, workers that do not have an n=[name] password argument provided will not have their data archived and no charts will be available for them.
Feel free to comment before tonight. If there are no comments, I'll assume this implementation is what everyone agrees upon and will implement it tomorrow and Sunday.
-
tucsondirect
- Posts: 73
- Joined: Mon Jul 20, 2015 8:05 pm
Post
by tucsondirect » Fri Aug 14, 2015 1:19 pm
This is exactly what i need, and 4 weeks is more than enough storage for me, it might be a good idea to include a date range selector so we are Slamming the server requesting data that we don't need. Doing so should help prevent problems down the road when a user is unaware of what the button is doing, and that actual amount of granular data they are requesting.. (and should be easy to implement
) I would take it one step further and provision an additional password argument of "log=true" to substantially reduce load on the server and speed up historical worker storage
-
JarBinks
- Posts: 24
- Joined: Mon Jul 06, 2015 1:25 pm
Post
by JarBinks » Sat Aug 15, 2015 8:46 pm
API availability of the data?
With some date range criteria?
-
Steve Sokolowski
- Posts: 4585
- Joined: Wed Aug 27, 2014 3:27 pm
- Location: State College, PA
Post
by Steve Sokolowski » Sun Aug 16, 2015 3:55 pm
This task is now complete and has been sent to Chris for final testing, but he won't do that until he returns from Montreal. You can expect this in two weeks.
Unfortunately, the API availability is not included; we'll need to look at that separately.
