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

I was time, when 64KB total ram+rom+video was enough to do great things. Now this is forgotten.
If I can make something smaller and still working - why not? Accesing to HDD is 1000x slower than ram, sometimes 1MB more space on pen or CD/DVD is need.
I made this bins for myself - I not need USB and/or FPGA and other stuff, just GPU.
There are alot of ppl that only mine and have no clue about compiling or setting up git or mingw on windows.
It is only up to them to use or not use my binaries. I`m putting then to skydrive to have them accesible from my other machine where I not have mingw.

1. Why would anyone need to compress an executable or dll now a days (in reference to upx)?
2. Why would anyone ever download and run an executable version of cgminer from anyone other than the author. And even then, if one is worried still they can compile their own binary. It only takes 30 minutes or less to set up a build environment on Windows.

And GPU only + scrypt version on my skydrive ;]
All DLLs also UPXed to make all of them as compact as possible.

cut/paste ...

2.10.2
An Xubuntu 11.04 x86_64 executable is in my github called cgminer-2.10.2a
https://github.com/kanoi/cgminer-binaries
(it also works on Fedora 16 and 17)

Yes I had to create a seperate git for the binaries since github has disabled the download feature

To get the binary simply:
wget https://github.com/kanoi/cgminer-binaries/raw/master/cgminer-2.10.2a
chmod +x cgminer-2.10.2a
md5sum cgminer-2.10.2a
272104efde383cac7e287190127e51a9  cgminer-2.10.2a

For anyone who didn't realise, it's just the executable file to put in place of 'cgminer'
Nothing else needs changing
First get and extract the full binary release from ckolivas and then copy my file in place of 'cgminer'

No problems so far (10 minutes) on my GPU, BFL or 'MMQ+2xICA'

Since I'm no longer GPU mining, I just run it for a while on my single 6950 to see what happens

MMQ+ICAs (1.6GH/s) on OzCoin Stratum with fixed 8 diff
BFL (858MH/s) on OzCoin Stratum with fixed 8 diff (BFL now on 864 bitstream)

The same configure options as cvolivas' binary version
In case anyone was wondering:
CFLAGS="-O2 -W -Wall" ./autogen.sh --enable-icarus --enable-bitforce --enable-ztex --enable-modminer --enable-scrypt
make clean
make

New version: 2.10.2, 19th December 2012

Various bugfixes and minor feature improvements.


Human readable changelog:

Should have fixed the various ways stratum pools would go dead and not recover to be in use.
When unable to connect to a pool at startup, previously if it eventually connected the menus wouldn't work - fixed.
On stratum disconnect, cgminer now throws away all work from that pool and stops any of that work in progress since it is all invalid and can only lead to rejects.
The best share count could get corrupted on fast machines artificially showing a higher share than was ever found.
Scrypt stratum support.
Kano updated the MMQ code to be much better at handling overheats.
Update API features.
Updated miner.php


Full changelog:

- Stop all work from the current pool if it's a stratum pool once it is
disconnected since it will be invalid upon reconnecting.
- Discard all staged work from stratum pools as well as the shares upon
disconnection since all the work becomes invalid.
- Use correct cbreak after 15 second delay when no pool is found alive.
- MMQ missing firmware -> ERR not DEBUG
- Allow stratum to work with scrypt.
- MMQ ensure delta clock can never exceed limits
- MMQ lowercase new string constants
- MMQ add api pgaset for clock
- API V1.23 - new pgaset command, to be used soon
- Protect the best_share/best_diff values under control lock.
- MMQ style police
- MMQ count work check timeout failures
- MMQ allow partial work replies and count them
- Check a stratum pool hasn't gone dead while being a backup pool and missed
having its idle flag cleared.
- MMQ overheat: remove clockdown (doesn't help) + ensure no lost shares
- API-README grammar
- API-README explain custom page extensions in miner.php
- miner.php add a sample group pool report
- miner.php allow where,group,having on cumstom pages

cgminer 2.10.1, Win7 x64, 12.10 driver, still hashing after 4 days (no more Win crashes)
...thanks for the good work.

That's what I was suspecting... Now it is running fine with the SDK that came with 12.10 driver

That driver and that SDK are incompatible. It broke that SDK after the 12.3 driver.

cgminer 2.10.1, Win7 x64, 12.10 driver, 2.1SDK, AMD 5850.
It hashes at full speed, but shows 0 accepted, 0 rejected shares.

When I use the same settings on cgminer 2.8.7, I got the error -42 Building Program (clBuildProgram). Is this related? But on 2.10.1, i didn't see the error message.

darn, i went 4 days w/o a crash but today 2/3 miners win7 just shut off.

The first stratum pool is available for scrypt:
https://bitcointalksearch.org/topic/ann-ltc-pps-otp-2fa-stratum-only-ltcmine-pps-mining-pool-33-92522

Can you please add support?  I don't know if that just involves removing the return false from detect_stratum in cgminer.c

Also, did you do anything weird to the kernel?  I lost 35% of my hash rate going to 2.10.1 from 2.8.7 with a 6970

edit: rolled back to 2.8.7 and I'm still getting weird rates -- I guess something is wrong with the 12.10 display driver or something

Hopefully these issues are now fixed in git.

I also noticed a problem when my stratum pool went down it switched to my backup, declared pool 0 DEAD, and when the pool came back up it never reconnected just said DEAD and kept on mining pool 1. I had to manually restart cgminer for it to show pool 0 as alive again. This was on 2.10.1

EDIT: I am using the debug version if that matters? this one (http://ck.kolivas.org/apps/cgminer/debug/): 14-Dec-2012 14:53   1.1M

I've noticed that if primary pool is down when starting cgminer, it won't start mining there when the pool returns. I'm running 2.10.1 and pools 0 & 1 are stratum. If pool 0 goes down after startup, switching to pool 1 and back to pool 0 works fine. But if pool 0 is down during startup, cgminer doesn't switch to it when it comes back alive. The pool is marked alive and has priority 0, but cgminer keeps mining at pool 1 seemingly forever. This should be easy to reproduce: temporarily block network access to pool 0 with a firewall or hosts file, and then remove the block after cgminer has started mining on pool 1.

Just started cgminer 2.10.1 on all my rigs and it works well.
So seems that bug is fixed...

Just wanted to report that I haven't had any crashes with 2.10.1 in the past few days (knocks on wood).   

I should add, I (think I) saw that immediately after restoring the network connection.  I was assuming at the time it was just coincidence that a new block happened then - but maybe it's an artifact of the network outage...

And that helps too, thanks.

Just to add, in this state I see cgminer maintaining TCP connections to all pools (including the ones it thinks are still dead) and I'm 90% sure i've seen it report that pool 3 (slush) saw a new block, even when it thought pool 3 was dead.

So some part of cgminer knows the pools are alive and is talking Stratum to them, but for whatever reason they're not getting marked as alive for pool  management purporses.

roy

It's a problem with the balancing with plain non-rolltime getwork based pools in the current version. This can be alleviated with the failover-only option for the time being which can be enabled on the command line or via the menu under pools. You should hardly ever get share leakage or run out of work with the latest work scheduler anyway so I'm considering making failover only the default.