Topic: M's Miner (Ant/SP) Monitor v5.2: alerts,auto/mass/scheduled reboot/mobile miner - page 4. (Read 209558 times)

It probably means that he has one version of the Web pages and another version of cgminer on his S3?
My S3 update steps change both.
You can also just redo the update steps but first power cycle it to be sure the overlay is correct.

Also make sure to save the settings again from both the settings pages after you've upgraded to my version or if you removed my version and downgraded to the bitmain version - just in case.

Are you using the latest firmware as well as Kano's cgminer update?

It seems to be working for others, so I'm not sure what makes yours different.

M

M -- I'm still getting an error trying to add an S3 Kano updated into ms miner. Log show..  the following Arithmetic operation resulted in an overflow. Any idea ? .. Thanks

hashing is displaying good now.

thanks.

Great, thanks!

M

I'm sure there are other differences.  For the sake of fixing the hash display, it was one character.  That's all I was asked to fix.

If the rest is good enough for everyone else, it's good enough for me.

M

Yeah, that's what I figured, although I never used a value above 1 anyway. I used to use 0 with the crappy bitmain firmware & p2pool as it seemed to perform better using that instead of 1 (if I remember correctly, bitmain had it set in the 1000's!! ), but since using your firmware I just keep it at the default 1 setting & it works a treat with p2pool  

Edit: I noticed bitmain have released another firmware update for the S5 - I assume they're still using their borked cgminer fork with the same crazy settings. I'll not go near it, that's for sure. Eagerly awaiting your S5 release kano 

queue is gone.
It has long been irrelevant to mining on cgminer  - especially on an Ant due to it's limited CPU - and people have over and again kept suggesting values to use but don't realise that they are only doing harm by considering putting it above 1.

Hey mdude,

I can confirm that the hash rate is now displaying with kano's S3 firmware - nice! 

The queue setting is still not displayed, but in my case I already know what it is - but others might want it?

Great to have the hash rate showing again, thanks mdude - will throw a few satoshi your way 

You are welcome ... never done any harm doing it your own way, so keep at the JSON to excel thing, I am sure you'll end up with a custom report that can beat any code off the web! I personally have no SP20, so not in the best postion to give advice on how to reduce the miner speed. Via the SSH or through a script, it should be straight foward, i.e simply change frequency settings (in conf file) then restart cgminer (which re-reads the conf file).



If by commad line you mean SSH, then all cgminer API commands can be run via SSH, and since you'll be looking to change settings for cgminer, I'd say the best repository would the very same cgminer API- README file.

I suppose there are a number of ways to skin a cat. The way I implemented the parsing of json (BTW I've never used M's monitor simply because I wrote my own) meant that I took care of the MHs nuasance when I first saw it, because I thought "what happens when it's THs ... so I had it covered to PHs ! The issue that cropped up (I think I mentioned this in another thread), was the additional nesting of the json result ... but all good now.

No, there are other differences.

Firstly a side track, if you use the DEVS command, it returns each device, which with an ant is always just one device.
Of course in an Ant it's ... MHS ... oh wait why is it different to the Ant summary?
So if you do a DEVS request to an Ant cgminer ... it's MHS ... but the summary request is GHS ...

Anyway, when the AntS1 was released, in the pool stats it returned the timestamp (as cgminer always has since it was added) for the "Last Share Time".
If you want to know how long ago that is, the API also always returns a field called "When" which is the cgminer time of the API request.
So how long ago was the last share? "When" - "Last Share Time" ... no big deal.
They LATER changed that to NOT return the timestamp, but rather a string HH:MM:SS
Why? Again to save having to format the the result in their web code.
What does that mean? Well you have to either accept their formatting, or if you wish to format it differently, you must first "convert" their string before formatting it differently.
... and of course you have to know which AntS1 you are talking to - the original firmware or a later version... and of course master cgminer itself always has been and always will be a timestamp since that makes sense.

Next, internal to cgminer there is the diff the pool is currently expecting for shares.
This field internally also has a formatted string of the diff for display on the cgminer text screen.
Bitmain added this text version of the field (not the numeric version) to the API.
So if you need the numeric value for any calculation, or wish to display it differently, you first must convert it to a number.
i.e. yeah nice to add it, but no that's not how it should be added.

Next, at some release of the firmware they added the "GHS 5s", "GHS av" and "Device Hardware%" to the stats output.
Why? Coz they didn't want to have to request the summary or devs that has the hash values and hardware% in it ...
Does it matter? No, but it's pointless making such changes since no other mining device has those numbers there, and they are already in devs and summary where they should be.
DEVS is designed to be (and is) standard across all devices/miners.
STATS contains other random information that differs from one device/miner to the next.

... and just to throw things out a bit more ...
Their internal web code expects all fields to be in a specific order in the API output.
As you would know the API is name=value or json name and value ... i.e. key and value pairs ... as it should be.
When you want a value, you reference it by key, NOT by field order.
That's one of the things I fixed back in my original S2 release and again in the S3 release, my version of their web code for processing the API is smaller and wont fail if the order of fields change, or new fields are added.
They've ignored that even up to the latest S5 firmware.

BTW, with Spondoolie equipment, you don't have to use the API output, which requires editing the config file etc.  It should work just fine plugging in the IP and port 80.  Make sure you have the web credentials set properly, then it should work.  (I configured this when I moved my SP30 offsite and API output was no longer available.)

M

That's precisely what happened here.  My app was looking for "GHS", which of course doesn't exist with your cgminer. 

M

No, I'm referring to them changing the names and values of fields and putting fields in other places.

A simple example is the hash rate.
In master cgminer it has always been and will always be MHS plus the setting after it e.g. "MHS av" "MHS 5s" "MHS 1m" etc
Bitmain didn't "fix" anything, they renamed the fields to GHS and divided them by 1000.
Why? Coz they didn't want to divide them by 1000 in the web display code in the S1 ... i.e. pointless.
Result is that anyone who wants to get the hash rate stats from an ant has to look for the fields called "GHS ..." instead of "MHS ..."

What you display on the screen of an app is whatever you like, you get the field and can display THs if you want - you simply divide it down.
But there's no reason to rename a field from the standard API and then require every monitoring tool to have to check for 2 field names and thus divide the 2 fields by a different power of 10.

That is what happened when they made that change. Pointless, and a waste of other people's effort.
Anyone who had a program to monitor the API was of course looking for fields named "MHS ..." then Bitmain put different fields in the Ants, so all of those monitoring programs now had to look for both "MHS ..." and "GHS ..."
Yes there have been other monitoring programs around for a long time.

Here is a beta of v5.3 that I believe will get the hash rate to display again for S3s after you've applied Kano's firmware.  Note that I do not have any mining hardware at all at my disposal for testing, so I've tested this, but obviously not as well as I could if I had a physical S3 on hand. 

Please let me know how it goes.


Download link: MMinerMonitor53b1.zip

M

Actually, that has nothing to do with it.  The difference is literally one letter.

M

OT: I enjoy he threads where you overclocked your S3 and S3+. Huge help for me when I started mining and I have used that knowledge for both over and underclocking. Underclocking is the Bitcoin miner's overclocking these days. I wish there was more information about the pencil mod, or a mod you could do with a rheostat which simply dialed the vcore and frequency up and down. I need to load Kanos firmware because I am still running the October 24, 2014 FW I found in the Ocing thread you made.

and Thank you very much for pointing out the missing R. After I read your post then Kanos I jumped to the cgminer text he linked and there it is, hello to me haha. I should probably do more googling on the topic.

I have been playing with JSON to Excel for kicks and starting importing data, but then I realize the hard work is done in so many open source projects like this one.
I do however like the ability to apply a % reduction to the miner speed reported by the SP20 in M's miner to see if I can find the magic number.


As I mentioned above, the API-README is awesome, thank you. Where is the best thread or site to find things like can I pass through the command line parameters for cgminer through the password field. I'm not averse to reading long threads and googling, but man I haven't tripped across a for sure on that except password and a mem command. I'll go through the cgminer thread again and read the readme.

Thanks for the great program Mdude77.
I will get some coin over that way. I have always started it and stopped it within a few minutes in the past, but I have grown to appreciate the information in an easy to glance and catch manner. I understand not wanting to take on liability for people screwing up their machines if they do something wrong during an SSH session. Bad publicity if people have bad experiences or blame the software, but I don't think there is anything wrong with linking and having a big disclaimer. People are gonna do what they do.
Have a good one.

I agree there was nothing much to be done about the "mother" cgminer API output, simply because there was no demand for it and the assumption that bitmain actually properly implemented the API.
Saying that, the fix is quite simple, basically, the json output from kano's API is nested inside another array (if you deserialize using the native javascriptdeserializer in .NET), and there are extra values added (hopefully that will be consistent in the S5 release too).

This is at the top of my to do list.

M