Topic: OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB - page 107. (Read 1193368 times)
October 22, 2013, 12:41:23 PM
That's not what you asked, though, is it?
You asked if it was no longer available in 13.10, insinuating that it was available in 13.10 and no longer is.
October 22, 2013, 11:29:03 AM
When overclocking individual chips, it would be useful if I could calculate the average valid hashrate from work utility. Unfortunately, the procs API response only lists utility, not work utility. Adding either time elapsed (which could be used in the calculations with Diff1 Work) or work utility to the procs response would be helpful.
And before you say "just use average hashrate * 1-HW%", I'll note that at least broken bitfury chips sometimes report inflated hashrates. For example, a chip @ 2.2 GH/s doing 33% errors never manages to do even 50% of the diff1 work that normally functioning chips do @ 2.2 GH/s. These kind of problems are why it would be useful to have the ability to derive a hashrate from actual work done, for individual chips. This is easy to do for the whole instance from the summary response, by just calculating (Work Utility)/60*2^32.
Work Utility is Diff1 Work / ElapsedAnd before you say "just use average hashrate * 1-HW%", I'll note that at least broken bitfury chips sometimes report inflated hashrates. For example, a chip @ 2.2 GH/s doing 33% errors never manages to do even 50% of the diff1 work that normally functioning chips do @ 2.2 GH/s. These kind of problems are why it would be useful to have the ability to derive a hashrate from actual work done, for individual chips. This is easy to do for the whole instance from the summary response, by just calculating (Work Utility)/60*2^32.
Yes, but there is no elapsed stat either on the procs response, so it's hard to implement this in miner.php. Maybe I should use DEVS instead of PGA, then I could combine DEVS & SUMMARY and get elapsed from $alldata.
EDIT: This worked fine. I still see no reason not to list the work utility for devs, though. Except that adding it would take some work
October 22, 2013, 11:20:46 AM
When overclocking individual chips, it would be useful if I could calculate the average valid hashrate from work utility. Unfortunately, the procs API response only lists utility, not work utility. Adding either time elapsed (which could be used in the calculations with Diff1 Work) or work utility to the procs response would be helpful.
And before you say "just use average hashrate * 1-HW%", I'll note that at least broken bitfury chips sometimes report inflated hashrates. For example, a chip @ 2.2 GH/s doing 33% errorsnever barely manages to do even 50% of the diff1 work that normally functioning chips do @ 2.2 GH/s. These kind of problems are why it would be useful to have the ability to derive a hashrate from actual work done, for individual chips. This is easy to do for the whole instance from the summary response, by just calculating (Work Utility)/60*2^32.
Work Utility is Diff1 Work / ElapsedAnd before you say "just use average hashrate * 1-HW%", I'll note that at least broken bitfury chips sometimes report inflated hashrates. For example, a chip @ 2.2 GH/s doing 33% errors
Yes, but there is no elapsed stat either on the procs response, so it's hard to implement this in miner.php. Maybe I should use DEVS instead of PGA, then I could combine DEVS & SUMMARY and get elapsed from $alldata.
EDIT: This worked fine. I still see no reason not to list the work utility for devs, though. Except that adding it would take some work
EDIT2: Here's a screenshot of my (heavily modded) miner.php:
As you can see, the chip doing 33% errors only barely has a 50% noncerate ((Diff1 Work) / Elapse * 2^32) compared to it's avg hashrate. I wonder what happens to that missing 17%, it's consistently missing and not just random variance.
October 22, 2013, 11:12:04 AM
Was it ever?
yes in 13.04 via synaptic... October 22, 2013, 11:06:44 AM
When overclocking individual chips, it would be useful if I could calculate the average valid hashrate from work utility. Unfortunately, the procs API response only lists utility, not work utility. Adding either time elapsed (which could be used in the calculations with Diff1 Work) or work utility to the procs response would be helpful.
And before you say "just use average hashrate * 1-HW%", I'll note that at least broken bitfury chips sometimes report inflated hashrates. For example, a chip @ 2.2 GH/s doing 33% errors never manages to do even 50% of the diff1 work that normally functioning chips do @ 2.2 GH/s. These kind of problems are why it would be useful to have the ability to derive a hashrate from actual work done, for individual chips. This is easy to do for the whole instance from the summary response, by just calculating (Work Utility)/60*2^32.
Work Utility is Diff1 Work / Elapsed And before you say "just use average hashrate * 1-HW%", I'll note that at least broken bitfury chips sometimes report inflated hashrates. For example, a chip @ 2.2 GH/s doing 33% errors never manages to do even 50% of the diff1 work that normally functioning chips do @ 2.2 GH/s. These kind of problems are why it would be useful to have the ability to derive a hashrate from actual work done, for individual chips. This is easy to do for the whole instance from the summary response, by just calculating (Work Utility)/60*2^32.
October 22, 2013, 10:20:01 AM
When overclocking individual chips, it would be useful if I could calculate the average valid hashrate from work utility. Unfortunately, the procs API response only lists utility, not work utility. Adding either time elapsed (which could be used in the calculations with Diff1 Work) or work utility to the procs response would be helpful.
And before you say "just use average hashrate * 1-HW%", I'll note that at least broken bitfury chips sometimes report inflated hashrates. For example, a chip @ 2.2 GH/s doing 33% errors never manages to do even 50% of the diff1 work that normally functioning chips do @ 2.2 GH/s. These kind of problems are why it would be useful to have the ability to derive a hashrate from actual work done, for individual chips. This is easy to do for the whole instance from the summary response, by just calculating (Work Utility)/60*2^32.
And before you say "just use average hashrate * 1-HW%", I'll note that at least broken bitfury chips sometimes report inflated hashrates. For example, a chip @ 2.2 GH/s doing 33% errors never manages to do even 50% of the diff1 work that normally functioning chips do @ 2.2 GH/s. These kind of problems are why it would be useful to have the ability to derive a hashrate from actual work done, for individual chips. This is easy to do for the whole instance from the summary response, by just calculating (Work Utility)/60*2^32.
October 22, 2013, 09:38:32 AM
Code:
apt-cache search bfgminer
Was it ever?
October 22, 2013, 09:32:40 AM
Code:
apt-cache search bfgminer
October 22, 2013, 07:53:15 AM
Hi Luke,
I think that the KnCMiner is in your plans.
Do you have an estimation when you release the KncMiner version?
Thank you very much for your contribution to Cryptocoin Mining!!!
The next major version will support KnC units.I think that the KnCMiner is in your plans.
Do you have an estimation when you release the KncMiner version?
Thank you very much for your contribution to Cryptocoin Mining!!!
You can see the (working) code-in-progress in the git "knc" branch.
Thank you very much for your answer!!!
October 22, 2013, 05:47:32 AM
guess: the built in temp sensor on chip 1 in your bfl is non functional and it may be overheating or comm errors. have you flashed your unit?
no I have not flashed it 
October 21, 2013, 03:48:58 PM
anyone have a link to a table of bit fury osc6 bit stats like bits gnash/sec wattage. been trawliing trying to find it for some ideas.
edit: found one in nano fury dev thread. still open to more though
edit: found one in nano fury dev thread. still open to more though
October 21, 2013, 03:33:29 PM
anyone know whats wrong?
guess: the built in temp sensor on chip 1 in your bfl is non functional and it may be overheating or comm errors. have you flashed your unit?
October 21, 2013, 02:36:19 PM
anyone know whats wrong?
October 21, 2013, 01:42:24 PM
Hi Luke,
I think that the KnCMiner is in your plans.
Do you have an estimation when you release the KncMiner version?
Thank you very much for your contribution to Cryptocoin Mining!!!
The next major version will support KnC units.I think that the KnCMiner is in your plans.
Do you have an estimation when you release the KncMiner version?
Thank you very much for your contribution to Cryptocoin Mining!!!
You can see the (working) code-in-progress in the git "knc" branch.
October 21, 2013, 01:32:02 PM
Hi Luke,
I think that the KnCMiner is in your plans.
Do you have an estimation when you release the KncMiner version?
Thank you very much for your contribution to Cryptocoin Mining!!!
I think that the KnCMiner is in your plans.
Do you have an estimation when you release the KncMiner version?
Thank you very much for your contribution to Cryptocoin Mining!!!
October 21, 2013, 12:32:07 PM
Ah dude, every time I go out my miner stops working. It's a bfl 60gh. Usually it says something like this
Bugs don't get fixed unless they're reported 
Can you run BFGMiner in valgrind? It'll use a lot more CPU time, but it will also give a lot more info.
Code:
valgrind --leak-check=full --track-origins=yes bfgminer YOUR OPTIONS --debuglog 2>valgrind.log
Thank you, I will do when I return. Hope my 1gig of ram pc from year 2000 can handle it.
October 21, 2013, 11:40:05 AM
Ah dude, every time I go out my miner stops working. It's a bfl 60gh. Usually it says something like this
Bugs don't get fixed unless they're reported Can you run BFGMiner in valgrind? It'll use a lot more CPU time, but it will also give a lot more info.
Code:
valgrind --leak-check=full --track-origins=yes bfgminer YOUR OPTIONS --debuglog 2>valgrind.log
October 21, 2013, 11:03:46 AM
Ah dude, every time I go out my miner stops working. It's a bfl 60gh. Usually it says something like this
2d000-b6e2e000 rw-p 00000000 00:00 0
b6e2e000-b6e34000 r-xp 00000000 08:01 4854546 /usr/lib/i386-linux-gnu/libheimntlm.so.0.1.0
b6e34000-b6e35000 r--p 00005000 08:01 4854546 /usr/lib/i386-linux-gnu/libheimntlm.so.0.1.0
b6e35000-b6e36000 rw-p 00006000 08:01 4854546 /usr/lib/i386-linux-gnu/libheimntlm.so.0.1.0
b6e36000-b6e3d000 r-xp 00000000 08:01 4854579 /usr/lib/i386-linux-gnu/libkrb5support.so.0.1
b6e3d000-b6e3e000 r--p 00006000 08:01 4854579 /usr/lib/i386-linux-gnu/libkrb5support.so.0.1
b6e3e000-b6e3f000 rw-p 00007000 08:01 4854579 /usr/lib/i386-linux-gnu/libkrb5support.so.0.1
b6e3f000-b6e42000 r-xp 00000000 08:01 1442631 /lib/i386-linux-gnu/libcom_err.so.2.1
b6e42000-b6e43000 r--p 00002000 08:01 1442631 /lib/i386-linux-gnu/libcom_err.so.2.1
b6e43000-b6e44000 rw-p 00003000 08:01 1442631 /lib/i386-linux-gnu/libcom_err.so.2.1
b6e44000-b6e6a000 r-xp 00000000 Aborted (core dumped)
2d000-b6e2e000 rw-p 00000000 00:00 0
b6e2e000-b6e34000 r-xp 00000000 08:01 4854546 /usr/lib/i386-linux-gnu/libheimntlm.so.0.1.0
b6e34000-b6e35000 r--p 00005000 08:01 4854546 /usr/lib/i386-linux-gnu/libheimntlm.so.0.1.0
b6e35000-b6e36000 rw-p 00006000 08:01 4854546 /usr/lib/i386-linux-gnu/libheimntlm.so.0.1.0
b6e36000-b6e3d000 r-xp 00000000 08:01 4854579 /usr/lib/i386-linux-gnu/libkrb5support.so.0.1
b6e3d000-b6e3e000 r--p 00006000 08:01 4854579 /usr/lib/i386-linux-gnu/libkrb5support.so.0.1
b6e3e000-b6e3f000 rw-p 00007000 08:01 4854579 /usr/lib/i386-linux-gnu/libkrb5support.so.0.1
b6e3f000-b6e42000 r-xp 00000000 08:01 1442631 /lib/i386-linux-gnu/libcom_err.so.2.1
b6e42000-b6e43000 r--p 00002000 08:01 1442631 /lib/i386-linux-gnu/libcom_err.so.2.1
b6e43000-b6e44000 rw-p 00003000 08:01 1442631 /lib/i386-linux-gnu/libcom_err.so.2.1
b6e44000-b6e6a000 r-xp 00000000 Aborted (core dumped)
October 21, 2013, 08:11:18 AM
Trying this again since I never got a response...
I'm running bfgminer on a Pi.
Thanks to the help of DrGuns4Hands, it can boot up and run unassisted.
However, when the pool was experiencing the recent DDoS attacks,
I heard the fan slow down for a long period but couldn't see the fault messages that would have been displayed if I had opened a terminal and started bfgminer manually.
So, how do I automatically start it with the output displayed or,
even better, how do I see the output messages using SSH?
I know this is really simple for you guys. A little help, please.
I'm running bfgminer on a Pi.
Thanks to the help of DrGuns4Hands, it can boot up and run unassisted.
However, when the pool was experiencing the recent DDoS attacks,
I heard the fan slow down for a long period but couldn't see the fault messages that would have been displayed if I had opened a terminal and started bfgminer manually.
So, how do I automatically start it with the output displayed or,
even better, how do I see the output messages using SSH?
I know this is really simple for you guys. A little help, please.
hang in there bud. im still working out some bugs in a setup for ya. sorry its taken so long
I appreciate the help you've already been.
I've tried messing with a few things with screen, bfgminerstart.sh and rc.local but haven't found what I should be doing.
I thought what I wanted would be easy for a linux person.
October 21, 2013, 02:19:19 AM
Trying this again since I never got a response...
I'm running bfgminer on a Pi.
Thanks to the help of DrGuns4Hands, it can boot up and run unassisted.
However, when the pool was experiencing the recent DDoS attacks,
I heard the fan slow down for a long period but couldn't see the fault messages that would have been displayed if I had opened a terminal and started bfgminer manually.
So, how do I automatically start it with the output displayed or,
even better, how do I see the output messages using SSH?
I know this is really simple for you guys. A little help, please.
I'm running bfgminer on a Pi.
Thanks to the help of DrGuns4Hands, it can boot up and run unassisted.
However, when the pool was experiencing the recent DDoS attacks,
I heard the fan slow down for a long period but couldn't see the fault messages that would have been displayed if I had opened a terminal and started bfgminer manually.
So, how do I automatically start it with the output displayed or,
even better, how do I see the output messages using SSH?
I know this is really simple for you guys. A little help, please.
hang in there bud. im still working out some bugs in a setup for ya. sorry its taken so long
Jump to: