Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 557. (Read 5806088 times)

What are you typing in on the command line? Post what you are putting after cgminer.exe

Easyminer is showing com4.

Don't know about you but I had a hell of a time trying to compile 2.4.3 on older Ubuntu versions as the 2.4.3 binary gave me an error and would not work at all.

I finally managed to get it to compile with the OpenCL detection working on my rigs :

for an older rig

for a newer rig

Thanks but why not stay with 11.04 as nobody is using 12.04 because it sucks for mining

it may have changed to bfl://./COMx

I'm trying to get a bfl to run with cgminer on windows and it keeps telling me that
 [2012-06-15 11:41:22] Started cgminer 2.4.3
 [2012-06-15 11:41:23] Icarus Detect: Failed to open bitforce://./COM4
 [2012-06-15 11:41:22] Started cgminer 2.4.3
 [2012-06-15 11:41:23] Icarus Detect: Failed to open bitforce://./COM4
 [2012-06-15 11:41:23] Found 0 ztex board(s)
 [2012-06-15 11:41:23] Need to specify at least one pool server.

Not sure what to do.

Donation sent

Perfect timing, I was just about to upgrade to 12.04.

is it old versions still supported?

where I can manual download
phatk110817Caymanbitalignv2w256long4.bin
phatk110817Cypressbitalignv2w256long4.bin
phatk110817Juniperbitalignv2w256long4.bin
kernels, because cgminer-2.1.2-win32 can't do that automatically?

kanoi, can i safely upgrade for bfl?

New release: Version 2.4.3, June 14 2012

Human readable changelog:

-Mod miner FPGA support.
-Fixes for load balance and rotate pool strategies
-GPU engine speed changes - will not increase GPU speed if the fanspeed is above the maximum.
-Improvements in detecting lagging pools
-Lots of other minor fixes
-Linux binaries now compiled for Ubuntu 12.04

Full Changelog:

- can_roll and should_roll should have no bearing on the cycle period within the
miner_thread so remove it.
- Check for strategy being changed to load balance when enabling LPs.
- Check that all threads on the device that called get_work are waiting on
getwork before considering the pool lagging.
- Iterate over each thread belonging to each device in the hashmeter instead of
searching for them now that they're a list.
- When using rotate pool strategy, ensure we only select from alive enabled
pools.
- Start longpoll from every pool when load balance strategy is in use.
- Add mandatory and block fields to the work struct. Flag any shares that are
detected as blocks as mandatory to submit, along with longpoll work from a
previously rejecting pool.
- Consider the fan optimal if fanspeed is dropping but within the optimal speed
window.
- Fix typo in some API messages (succeess/success)
- api.c MMQ stat bugs
- Bugfix: Fix warnings when built without libudev support
- Bugfix: slay a variety of warnings
- Bugfix: modminer: Fix unsigned/signed comparison and similar warnings
- API add ModMinerQuad support
- Bugfix: Honour forceauto parameter in serial_detect functions
- modminer: Temperature sensor improvements
- modminer: Make log messages more consistent in format
- Only adjust GPU speed up if the fanspeed is within the normal fanrange and
hasn't been turned to maximum speed under overheat conditions.
- ModMiner use valid .name
- New driver: BTCFPGA ModMiner
- Abstract generally useful FPGA code into fpgautils.c
- API add stats for pool getworks
- miner.php option to hide specific fields from the display
- miner.php add version numbers to the summary page
- Update debian configs to v2.4.2
- Add API and FPGA READMEs into Makefile to be included in source distribution.
- Icarus - fix unit64_t printf warnings

I do appreciate your looking into it. It isn't as though the one single I own stopped working entirely. I would have to say CGminer is still superior. I was able to continue mining just at a reduced rate so thank you for that.
And Thank You for a great program!

Alas both load balance and rotate are the poor cousins of the pool management strategies and none of the issues you described are ideal or expected. I shall look at them further, but the sheer nature of the lack of use of these strategies in the wild means the bugs are only now showing up and may or may not be fixable.

I noticed two things last night when Eclipse was offline for a while.
1. With load balance set as my pool management strategy I had a huge drop in hashrate. Eclipse was marked as dead by CGminer.
I have no way of proving what I witnessed but with Eclipse dead I had server not providing work fast enough for both other pools as long as I used load balance.
2. After swapping to rotate I hoped to only use one pool at a time making possible communication with Eclipse stop. I suddenly had two issues
A. A disabled pool was suddenly getting hashes sent to it despite being disabled. Deleting did fix it but disabling should, I would think, make it not part of the rotation.
B. The rotation stopped every time Eclipse came up for its share of the time. I am not sure this is a bug per se, but it seems like a marked dead pool shouldn't get a full share of time with 0 work being sent or submitted. Possibly there is no failover in rotate and that would be my mistake.

I suppose I could have switched to a failover system and thereby curtailed the issue. This would leave me at a loss of hashing power at my secondary pool. I was using multiple pools to test if proportionally mining in relation to pool hashrate truely reduced my variance. So far the theory seems to hold with my results, more frequent smaller payouts.

Likely this is all expected. rotate just rotates with no logic applied besides the timer, load balance tries to send shares regardless of pool being dead or not. I appreciate the program very much. It is great. Normally I do not have much time with a pool down so I after more then a month finally noticed this.

Alright, I guess I'll keep it on 10 for a while; rejects seem to be minimal still. Let me know if you need any more info on the thread problem.

Nothing to lose by trying. CPU usage often shoots up but it depends on the device and the driver combination, and bear in mind you will only be running 1 thread so it is slightly different. You can always change it on the fly from the menu and see.

You mean set it up to 10? I thought that was supposed to be a bad idea.

Yah I know, I'm not ignoring you, I just can't see wtf is happening for you. The performance advantage of 2 threads versus 1 isn't that huge mind you, so I'd suggest just bumping up the intensity by 1 on the dedicated mining GPUs and use 1 thread until I find the bug (whatever it is). No one needs the level of control to set the number of threads on a per-gpu basis really...

Just throwing ideas out there since nobody seems to be in a hurry to try and figure it out.

Sounds like you want me to fix a possible bug by adding a feature instead?

FirePro V4900 should work with any opencl miner, including cgminer.  You can probably get 100-120 Mh/s out of it. Hint: 480 stream cores same as HD 6670

re: your problem with slower performance

Download afterburner:

http://event.msi.com/vga/afterburner/download.htm

unlock it:

http://forums.overclockersclub.com/index.php?showtopic=182403

See if you can set the core/memory clocks to where you want them to be.

If AB cannot reset the clocks, flash the BIOS with techpowerup images and try again.

Your clocks were probably locked when you down/upgraded.