Topic: (OLD) BFGMiner: modular FPGA/GPU, GBT, Stratum, RPC, Avalon/Lnx/OpnWrt/PPA/W64 - page 33. (Read 260061 times)

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.

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.

I'm working on something for that.

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.

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.

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

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

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

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

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!

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.

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

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

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

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?

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

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

NEW VERSION - 2.4.1, MAY 6 2012

While Kano continues to try rewriting his own hashrate measurements for CGMiner's Icarus driver, BFGMiner's Icarus driver was already (and still is) more accurate. I did take the opportunity to give it even more specific calibration, though.

As BFL+Icarus owners might have known, BFGMiner has worked with both devices together from the start.

Finally, Kano recently injected RPC API code through the device driver API in CGMiner. While I made an attempt to sanitize it upstream, Con didn't merge it in time for 2.4.1; BFGMiner of course includes this cleanup, since it is important to a sane (and secure!) device driver API.

Human readable changelog:

• --benchmark won't crash
• A pool will only be disabled if it rejects shares for at least 3 minutes in a row. Then it will be checked every longpoll to see if it is accepting shares, and if so, will be re-enabled.
• More accurate hashrate on Icarus
• Ztex quad 1.15y support
• Extra device stats in RPC API

Full changelog

• Icarus: Calibrate hashrate yet even more accurately
• In the unlikely event of finding a block, display the block solved count with the pool it came from for auditing.
• Display the device summary on exit even if a device has been disabled.
• Use correct pool enabled enums in api.c.
• Import Debian packaging configs
• Ensure we test for a pool recovering from idle so long as it's not set to disabled.
• Fix pool number display.
• Give BFGMiner -T message only if curses is in use.
• Reinit_adl is no longer used.
• API 'stats' allow devices to add their own stats also for testing/debug
• API add getwork stats to BFGMiner - accesable from API 'stats'
• Don't initialise variables to zero when in global scope since they're already initialised.
• Get rid of unitialised variable warning when it's false.
• Move a pool to POOL_REJECTING to be disabled only after 3 minutes of continuous rejected shares.
• Some tweaks to reporting and logging.
• API support new pool status
• Add a temporarily disabled state for enabled pools called POOL_REJECTING and use the work from each longpoll to help determine when a rejecting pool has started working again. Switch pools based on the multipool strategy once a pool is re-enabled.
• Removing extra debug
• Fix the benchmark feature by bypassing the new networking code.
• Reset sequential reject counter after a pool is disabled for when it is re-enabled.
• ztex updateFreq was always reporting on fpga 0
• Trying harder to get 1.15y working
• Specifying threads on multi fpga boards extra cgpu
• Missing the add cgpu per extra fpga on 1.15y boards
• API add last share time to each pool
• Don't try to reap curls if benchmarking is enabled.

It seems that there is no libcurl.pc existing (for pkg-config)
curl-config --version shows  libcurl 7.22.0[/quote]It's part of libcurl4-gnutls-dev for Debian/Ubuntu.