 Show Posts
|
|
Pages: [1]
|
|
Its amazing that after you post something, the answer whacks you on the side of the head. Ok, I know what diff1 work=103 and accepted=103 means. But the 3rd, No Device=false still eludes me. It couldnt be as simple as answering the question; is the usb device present?
|
|
|
|
|
Hi,
I'm trying to write a dashboard app that will help me monitor several cgminer 3.7.2 rigs. I am trying to understand what certain fields mean from the "devs" api query. To put things in context, here is an output line from the devs api call. This is for a single gridseed mini usb device.
ASC=9,Name=GSD,ID=9,Enabled=Y,Status=Alive,Temperature=0.00,MHS av=0.36,MHS 5s=0.36,Accepted=103,Rejected=0,Hardware Errors=10,Utility=0.36,Last Share Pool=0,Last Share Time=1402857221,Total MH=6209.4445,Diff1 Work=103,Difficulty Accepted=76567.00000000,Difficulty Rejected=0.00000000,Last Share Difficulty=800.00000000,No Device=false,Last Valid Work=1402857221,Device Hardware%=8.8496,Device Rejected%=0.0000,Device Elapsed=17272
1. What does Diff1 Work=103 mean?
2. The Accepted=103 has the same value as Diff1 Work. What does this mean?
3. Does anyone know what No Device=false means? (it has to do when USE_USBUTILS is true)
I understand the rest of the fields. Can anyone help with these three?
|
|
|
|
Regarding T=361680. You're so right. 10hrs * 3600 = 360000 (oops should be 36000) + 28 mins * 60 = 1680. Total 37680 seconds. Geez the original 361680 gave me the magic number I was looking for that I did not even double check the math. How coincidental is that? Furthermore, I did not even multiply A * 65536. What a brain fart on my part. With the given correct number of seconds and using your formula A * 65536 / T, the new number is 3908096*65536/37680=6797265.909 or 6.8mhs. You've got it. Is that suppose to be an average of something? Or is that how CM computes mhs at any given time?
My 2 blades run cool at the touch even around the voltage regulators. I've got it clocked conservatively at 800mhz. No usb errors ever in the system logs since I got them a little over a week ago. And the first (and last) week on weminerltc, they ran at a steady 10-10.5mhs on their charts.
The 9th and 10th hour just came in at 5.41 and 5.24. And the Last Hour Hashrate right now is 5.2mhs. cgminer is still rocking at 10.8mhs. I'm not sure what's going on. Could you explain your formula a bit more? Thanks much for the input.
Edit: I think I know what's going on. Since the formula for the hash rate is based on accepted shares, all 4 of my blade boards had the proper hash rate, BUT 2 of them did not have the proper wu rates which led to improper accepted rates. ahha. I decided to reset the system and give it another whirl. So far so good. All 4 boards are logging expected numbers. Hopefully, the numbers will reconcile with CM's hash rate. Thanks again for the road map and interesting conversation.
cgminer's "A" is "difficulty 1 shares". In scrypt context a "diffculty 1" share has a probability of 1/65536 (2^16), i.e. on average one out of 65536 hashes will be a diff 1 share. Since we know the number of shares (A) and the probability of each share (1/65536) we can estimate how many hashes the miner calculated (A * 65536). Divided that by the number of seconds and you get hashes per second. The pool must be using something similar to calculate your hashrate, perhaps A+R instead of just A. WU is directly related to that, I just don't remember the exact formula right now. If some of your boards had a much lower WU, then that's obviously an issue. You can calculate the estimated hashrate for each board separately using the same formula, and if it's been running long enough you can just eyeball the "A" for each board and see which ones are lagging. 10-20% could be normal variance, more than that is certainly suspicious. I hope you'll get it sorted out. Thanks for explaining the formula. I read so many different meanings of "difficulty" that it's been difficult for me to figure out what difficulty is. I guess that's why its called difficulty. hahaha. Once I reset cgminer which in turns reset the boards, everything got sorted out. All 4 board's wu were in the 4.x range which is what it suppose to do based on the math, and the accepted shares were distributed nice and evenly. And CM concurred by cranking up the hash rate chart with an avg of 10.2 in the past 7 hours. I now have a better picture on what to look for. Thanks again. You've been a great help. |
|
|
|
Thanks suchmoon for the response. A=3908096/T=361680=10.8. Yup. Right on the money; 10.8mhs exactly what cgminer is reporting. What does anyone suggest to do next? Give it more time?
Not sure now, I was kind of expecting it to be closer to CM numbers :-) Can you check if you mined at CM all the time, no backup pools involved? What does your 24-hour hashrate chart show? Good points. I've been on the CM pool for the full 10hr.28min duration (no pool switches) and there was no downtime I could see (summary polled every 5 seconds). The 24hr CM hash chart just came to life and it says I peaked out at 9.07 (which is close enough) during the 1st hour. The 2nd-5th hours dropped and peeked out at 7.6, and the final 3 hours are in the 5.1-5.8 range. The 9th-10th hours are not on the chart yet. In my cgminer log, I've been a constant 10.8 throughout the 10.5 hour range. I think it needs more time? Let's go back to that formula. How did you get the T=361680? It doesn't add up to 10.5 hours for me. It should be ~37800 and with that I get A * 65536 / T = 3908096 * 65536 / 37800 = 6775687 = ~6.8 MH/s How is temperature around blades? Power supplies ok? Any USB errors in system logs? Regarding T=361680. You're so right. 10hrs * 3600 = 360000 (oops should be 36000) + 28 mins * 60 = 1680. Total 37680 seconds. Geez the original 361680 gave me the magic number I was looking for that I did not even double check the math. How coincidental is that? Furthermore, I did not even multiply A * 65536. What a brain fart on my part. With the given correct number of seconds and using your formula A * 65536 / T, the new number is 3908096*65536/37680=6797265.909 or 6.8mhs. You've got it. Is that suppose to be an average of something? Or is that how CM computes mhs at any given time? My 2 blades run cool at the touch even around the voltage regulators. I've got it clocked conservatively at 800mhz. No usb errors ever in the system logs since I got them a little over a week ago. And the first (and last) week on weminerltc, they ran at a steady 10-10.5mhs on their charts. The 9th and 10th hour just came in at 5.41 and 5.24. And the Last Hour Hashrate right now is 5.2mhs. cgminer is still rocking at 10.8mhs. I'm not sure what's going on. Could you explain your formula a bit more? Thanks much for the input. Edit: I think I know what's going on. Since the formula for the hash rate is based on accepted shares, all 4 of my blade boards had the proper hash rate, BUT 2 of them did not have the proper wu rates which led to improper accepted rates. ahha. I decided to reset the system and give it another whirl. So far so good. All 4 boards are logging expected numbers. Hopefully, the numbers will reconcile with CM's hash rate. Thanks again for the road map and interesting conversation. |
|
|
|
Thanks suchmoon for the response. A=3908096/T=361680=10.8. Yup. Right on the money; 10.8mhs exactly what cgminer is reporting. What does anyone suggest to do next? Give it more time?
Not sure now, I was kind of expecting it to be closer to CM numbers :-) Can you check if you mined at CM all the time, no backup pools involved? What does your 24-hour hashrate chart show? Good points. I've been on the CM pool for the full 10hr.28min duration (no pool switches) and there was no downtime I could see (summary polled every 5 seconds). The 24hr CM hash chart just came to life and it says I peaked out at 9.07 (which is close enough) during the 1st hour. The 2nd-5th hours dropped and peeked out at 7.6, and the final 3 hours are in the 5.1-5.8 range. The 9th-10th hours are not on the chart yet. In my cgminer log, I've been a constant 10.8 throughout the 10.5 hour range. I think it needs more time? |
|
|
|
Thanks suchmoon for the response. A=3908096/T=361680=10.8. Yup. Right on the money; 10.8mhs exactly what cgminer is reporting. What does anyone suggest to do next? Give it more time? I've been mining with clever for 12 hours now. My only concern is with my hash rate. I have 2 blades with cgminer running at 10.8mhs average for the last 12 hours (i run in verbose log mode with every 5 second hardware summaries, scrape the logs, and do the stats) with very few hardware errors and reject rates that are lower than the pool average. According to my user stats, it says I've done only 5.3mhs in the past hour and 6.9mhs in the past 24 hours (I'm assuming it knows I've been on for only 12 hours). From past mining experience and my own research, I'm pretty sure my blades are doing what cgminer says its doing. So the big question is why are my reported hash rates so low (less than half)? I searched the forum for "low hash rate" and it seems like everyone is instead concerned about high reject rates so if I'm repeating someone else's concern, I apologize and ask that you point me to the right reply. Thanks in advance.
Take your cgminer "A:" shares and do this: A * 65536 / T where T is the number of seconds cgminer was running ("Device Elapsed" from the API, or just use the number of hours times 3600) Is that any closer to 10 MH/s? |
|
|
|
|
I've been mining with clever for 12 hours now. My only concern is with my hash rate. I have 2 blades with cgminer running at 10.8mhs average for the last 12 hours (i run in verbose log mode with every 5 second hardware summaries, scrape the logs, and do the stats) with very few hardware errors and reject rates that are lower than the pool average. According to my user stats, it says I've done only 5.3mhs in the past hour and 6.9mhs in the past 24 hours (I'm assuming it knows I've been on for only 12 hours). From past mining experience and my own research, I'm pretty sure my blades are doing what cgminer says its doing. So the big question is why are my reported hash rates so low (less than half)? I searched the forum for "low hash rate" and it seems like everyone is instead concerned about high reject rates so if I'm repeating someone else's concern, I apologize and ask that you point me to the right reply. Thanks in advance.
|
|
|
|
|
