(OLD) BFGMiner: modular FPGA/GPU, GBT, Stratum, RPC, Avalon/Lnx/OpnWrt/PPA/W64

[kano]

[1713963020]

1713963020

[1713963020]

1713963020

[1713963020]

1713963020

[1713963020]

1713963020

[Hpman]

Code:

[quote author=Hpman link=topic=78192.msg881895#msg881895 date=1336121371]checking for LIBCURL... no
checking for LIBCURL... no
configure: error: Missing required libcurl dev >= 7.10.1

It seems that there is no libcurl.pc existing (for pkg-config)
curl-config --version shows  libcurl 7.22.0

It's part of libcurl4-gnutls-dev for Debian/Ubuntu.

I've installed libcurl4-gnutls-dev but it doesn't help , previously i used libcurl4-openssl-dev.  Is it possible that 12.04 changes the way for  version check of libcurl?

Thanks Hpman

[kentrolla]

are there any plans to add the option to cpu mine with windows?

[Luke-Jr]

are there any plans to add the option to cpu mine with windows?

I don't want to make it too easy for botnets to abuse BFGMiner. Is there a legitimate need for CPU mining for people who don't know how to compile themselves?

[kentrolla]

are there any plans to add the option to cpu mine with windows?

I don't want to make it too easy for botnets to abuse BFGMiner. Is there a legitimate need for CPU mining for people who don't know how to compile themselves?

yes, my friend says he gets 30mh/s with his cpu. every little extra bit helps imo.

[Luke-Jr]

are there any plans to add the option to cpu mine with windows?

I don't want to make it too easy for botnets to abuse BFGMiner. Is there a legitimate need for CPU mining for people who don't know how to compile themselves?

yes, my friend says he gets 30mh/s with his cpu. every little extra bit helps imo.

The electricity to mine 30 MH/s with a CPU costs more than you'll get.

[kentrolla]

not if you're someone like me that thinks the price of bitcoins is going to skyrocket some day.

[kano]

not if you're someone like me that thinks the price of bitcoins is going to skyrocket some day.

If you believe that, then you would of course have no issue with buying a $100-$200 GPU that will mine bitcoins 10-50x faster than your CPUs and thus also make CPU mining pointless.

[rjk]

Also, search for pooler's fork of cpuminer. It's been better optimized than what is in cgminer' sources anyways. Maybe you will get 40 mhash/s instead of 30!

[Luke-Jr]

NEW VERSION - 2.4.2, JUNE 2 2012

This release cycle, I finally got around to cleaning up the old (from cpuminer days) "work_restart" flag array that indicated longpolls to the actual mining threads. This should have been totally uncontroversial, as it has no practical behaviour change in itself, but Con decided not to pull it in favour of a more complex and less efficient solution that probably nobody will ever care to write - too bad he didn't bring that up when I'd discussed making this change a month or so ago. As a result, cgminer and BFGMiner have drifted further apart for what I think is fair to describe as no reason whatsoever. It also means cgminer 2.4.2 doesn't have the new functionality based on that cleanup (also to blame is Kano removing epoll support from the Icarus driver in past releases): BFGMiner 2.4.2 no longer sits in a loop of "wait for data from Icarus; check if there's a longpoll; ..." on Linux, it simply sleeps the full timeout (11.2 seconds generally) and is interrupted by the operating system if the Icarus finds a share or a longpoll occurs. This might seem trivial, but should shave some small percentage off longpoll stales and improve CPU time on low-powered FPGA rigs (some of us are running their FPGAs on routers or Raspberry Pis now!).

On the bright side, Kano finally rewrote my code (that he had removed from cgminer) to improve Icarus hashrate reporting, so I took his version over mine to bring BFGMiner closer to the cgminer codebase. I kept my more accurate Icarus timing measurements (and recalibrated them with the new code), though, so it should be just as accurate as before.

Human readable changelog:

• epoll is used when available (ie, just Linux) to allow Icarus reads to sleep the full duration without waking the thread, and provides faster interruption for longpolls
• Longpoll will now finally only connect to the main pool unless you switch pools, and then it will drop the longpoll on the next block if you are still on the new pool. This should complete the rework to make cgminer have the absolute optimum number of connections open at any one time - the minimum possible while having the best hashrate, and will likely decrease the lost work across block changes. No solution to multipool+LP here was going to be perfect but this seemed the best overall to miners and pools alike.
• The windows crash at 7 days which occurred thanks to the AMD driver screwup should be fixed. Now it will behave the way it used to behave: you'll just lose your fan monitoring once the driver is broken.
• New Icarus code should scan more of each work item and has some hidden advanced timing options (see new readme file)
• Saved config file when there are no GPUs should no longer be corrupt.
• Separate READMEs for API and FPGA evolving.

Full changelog

• API.class compiled with Java SE 6.0_03 - works with Win7x64
• miner.php highlight devs too slow finding shares (possibly failing)
• API update version to V1.11 and document changes
• API save default config file if none specified
• api.c save success incorrectly returns error
• api.c replace BUFSIZ (linux/windows have different values)
• Move RPC API content out of README to API-README
• Open a longpoll connection if a pool is in the REJECTING state as it's the only way to re-enable it automatically.
• Use only one longpoll as much as possible by using a pthread conditional broadcast that each longpoll thread waits on and checks if it's the current pool before
• If shares are known stale, don't use them to decide to disable a pool for sequential rejects.
• Restarting cgminer from within after ADL has been corrupted only leads to a crash. Display a warning only and disable fanspeed monitoring.
• Icarus: fix abort calculation/allow user specified abort
• Icarus: make --icarus-timing hidden and document it in FPGA-README
• Icarus: high accuracy timing and other bitstream speed support
• add-MIPSEB-to-icarus-for-BIG_ENDIAN
• work_decode only needs swab32 on midstate under BIG ENDIAN
• add compile command to api-example.c
• save config bugfix: writing an extra ',' when no gpus
• Add dpkg-source commits

[kano]

You need to update your git links to gitorious coz there's no links to the source code in the first post any more ...

[iopq]

not if you're someone like me that thinks the price of bitcoins is going to skyrocket some day.

then buy some, it's more efficient

so say instead of spending extra $50 on the power bill just buy $50 of bitcoins so you get 10 bitcoins instead of like 5 that you would have gotten if you were cpu mining
this keeps the difficulty down for the rest of us

[Luke-Jr]

You need to update your git links to gitorious coz there's no links to the source code in the first post any more ...

Thanks, I pushed the latest code to GitHub. Note the tbz2/zip source links should have worked too.

[rjk]

How about some screenshot action. This is what keeps happening, and this time I decided to make a core dump of the process. The command window when I found it was not accepting button presses, so it seems that the mining process had frozen entirely. Since the U number was so low, it was obvious that the process had continued to run even after the unit stopped hashing, and froze much later - the U is normally around 11-12, and the average hash rate is normally around 865 not 675. As you can see from the screenshot, the last LP that it reported before it froze was at 13:53:09 Eastern Time, and it had stopped considerably before that although I'm not sure when. Screenshot was taken at around 14:30.

In addition, the secondary internal red light on the BFL unit was steady on, and not blinking every 5 seconds as expected. It also was idling and not running at full burn or stuck in a loop. Normally when the machine is idle, the internal red light goes dim.

I am not sure what the core dump contains, so I won't post it, but if Con, Kano, or Luke-Jr want to see it just ask and I will send it over.

[Luke-Jr]

How about some screenshot action. This is what keeps happening, and this time I decided to make a core dump of the process. The command window when I found it was not accepting button presses, so it seems that the mining process had frozen entirely. Since the U number was so low, it was obvious that the process had continued to run even after the unit stopped hashing, and froze much later - the U is normally around 11-12, and the average hash rate is normally around 865 not 675. As you can see from the screenshot, the last LP that it reported before it froze was at 13:53:09 Eastern Time, and it had stopped considerably before that although I'm not sure when. Screenshot was taken at around 14:30.

In addition, the secondary internal red light on the BFL unit was steady on, and not blinking every 5 seconds as expected. It also was idling and not running at full burn or stuck in a loop. Normally when the machine is idle, the internal red light goes dim.

I am not sure what the core dump contains, so I won't post it, but if Con, Kano, or Luke-Jr want to see it just ask and I will send it over.

This is a BitForce FPGA, correct? You can send me the core dump (I imagine it's too big for email), but I'm not sure it will be of much use since you're running on Windows - perhaps I can pick out some strings from it. It does contain all your pool login info, note.

[P_Shep]

I'm working on something for that.

[rjk]

This is a BitForce FPGA, correct? You can send me the core dump (I imagine it's too big for email), but I'm not sure it will be of much use since you're running on Windows - perhaps I can pick out some strings from it. It does contain all your pool login info, note.

Yes it is, and the GPUMAX login for the worker is different than for the website login, so not a problem there. Dump is 20ish MB, I'll see if I can upload it somewhere and give you the link.

EDIT: Not sure if the dump is any good, when I open it in Visual Studio, it says: You cannot debug a 64-bit dump of a 32-bit process, you must collect a 32-bit dump of a 32-bit process. But I'm not sure how to do that.

[rjk]

I'm working on something for that.

What's your plan? Fortunately this time I caught it after about an hour of downtime, instead of last time where it was down for several hours.



And this time the window hadn't frozen, it accepted my 'Q' to quit just as normal.

[P_Shep]

it's here right now:
https://github.com/pshep/cgminer

[Luke-Jr]

I plan to release BFGMiner 2.4.3 soon, but I am hoping to address some reported problems with the modminer driver first. Apparently between the time I finished writing the driver (when it worked), and the time CGMiner 2.4.3 was released with it, something got broken.