OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB

[Taugeran]

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?

[Taugeran]

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 

[ewibit]

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

[greek_hephaestus]

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.
You can see the (working) code-in-progress in the git "knc" branch.

Thank you very much for your answer!!!

[ewibit]

Code:

 apt-cache search bfgminer

bfgminer no more availlable in Ubuntu 13.10?

[HellDiverUK]

Code:

 apt-cache search bfgminer

bfgminer no more availlable in Ubuntu 13.10?

Was it ever? 

[juhakall]

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.

[Luke-Jr]

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

[ewibit]

Was it ever? 

yes in 13.04 via synaptic...

[juhakall]

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 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 / Elapsed

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.

[Luke-Jr]

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

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

Yep, already adding a bunch of new info for 3.4

[HellDiverUK]

Was it ever? 

yes in 13.04 via synaptic...

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. 

[Mattster28]

On BFGminer start-up im getting 20 or more (duped/stale) not sure which. Only get them when I first start the miner.

Looks like this...BFL 0: 64C | 61.45/61.11/60.52Gh's | A:10153 R:46+20(.45%) HW:1910/.58%
                                                                                                      ^^
Anybody know whats causing these?

Edit: Figured it out. I think...lol

[xzempt]

how to get bfgminer to work on v2 blades?

[Taugeran]

how to get bfgminer to work on v2 blades?

compile it with the network server, set the ports with --http-port.

set the blades server ip to bfgminer ip and each blade must have a unique username and password; doesnt matter what it is.

[smiley123]

Is there an easy way to increase the number of lines for the messages at the bottom of bfgminer? It's not enough lines to see the menu's.  If not, could someone point me to the right location in the code and I'll just recompile it.

[xzempt]

how to get bfgminer to work on v2 blades?

compile it with the network server, set the ports with --http-port.

set the blades server ip to bfgminer ip and each blade must have a unique username and password; doesnt matter what it is.

compile?  im a windows 7 user

[Mudbankkeith]

Is there an easy way to increase the number of lines for the messages at the bottom of bfgminer? It's not enough lines to see the menu's.  If not, could someone point me to the right location in the code and I'll just recompile it.

Right click in the process window and you are in the settings, click on properties

[smiley123]

Is there an easy way to increase the number of lines for the messages at the bottom of bfgminer? It's not enough lines to see the menu's.  If not, could someone point me to the right location in the code and I'll just recompile it.

Right click in the process window and you are in the settings, click on properties

Thanks for the reply, but maybe I should have stated that I have too many block erupters so it fills the status window to maximum height. I can still scroll up and down with the arrow keys to see all the erupters, but it only leaves like 2 lines for bottom text witch is not enough to see the menus to select pools and stuff. 

[Mudbankkeith]

Is there an easy way to increase the number of lines for the messages at the bottom of bfgminer? It's not enough lines to see the menu's.  If not, could someone point me to the right location in the code and I'll just recompile it.

Right click in the process window and you are in the settings, click on properties

Thanks for the reply, but maybe I should have stated that I have too many block erupters so it fills the status window to maximum height. I can still scroll up and down with the arrow keys to see all the erupters, but it only leaves like 2 lines for bottom text witch is not enough to see the menus to select pools and stuff. 

Change text height in the font setting from (8*12 default) to 6*8

Then increase the height till you find a size that fills your screen(try120)