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

New stable release - Version 2.7.7,  7th October 2012

Another stable release update before bringing out a release with the massive changes of stratum support.

Human readable changelog

Fixed the many hardware errors bug and occasional crash with HW errors.
Other minor stuff

Full changelog
- Fix unused warnings on ming build.
- Fix sign warning in ocl.c
- fds need to be zeroed before set in modminer.
- Put scrypt warning on separate line to avoid 0 being shown on windows as
bufsize.
- Display correct pool number when block is found.
- Prevent corrupt values returned from the opencl code from trying to read
beyond the end of the buffer by masking the value to a max of 15.
- Icarus USB write failure is also a comms error
- api.c DEBUG message has no paramter
- Icarus catch more USB errors and close/reopen the port
- API-README update cgminer verison number
- hashmeter fix stats kh/s on 32bit windows

Thanks for the reply kano. Here is hoping for your speedy delivery.!!!  I'm not at all concerned with the TML bitstream as I for one will not use it, just stating that it was the firmware version that my MMQ was flashed to.
I would like to try the new Stratum on my MMQ's as it is working extremely well on my video cards. I may try to backwards flash the cards tomorrow and see what happens. Will let everyone know if I do.

Okay I've done quite a bit of investigation around this "0" displayed issue. Ironically, that is a display bug in windows. The buffer size is actually being worked out to something like 1.5 billion, and if it's put on a separate line you can see that bufsize is  not zero (I'll do it in the next version). However this does not fix your original complaint that you can't set very high thread concurrency counts like you could on raper [sic]. But you've reminded me of what happened when I investigated this originally.

There are a number of problems with the way raper uses the padbuffer there. Firstly it is reused between threads which means that if you set multiple threads per device they fight over and can trash the data in the buffer. That's not a huge problem with raper because its threading is pretty primitive, unlike cgminer which is heavily multithreaded. However, the main problem is that there is NO error checking on setting values to run the opencl commands. If it  returns invalid values, raper just does it again, and assumes the hashes have been done. So it intermittently works, and intermittently just counts up a number of hashes that never happened. So what happens is you get a displayed hash rate that is really high that does not translate into a proportional rise in number of shares generated.

Summary: I implore you to compare the best share generation rate of raper to cgminer rather than the displayed hashrate.

My MMQ should be arriving shortly
A 3rd party USPS EMC tracking site said it was somewhere near Alice Springs on Saturday ... But I think that was just their version of 'somewhere in Australia' - in the middle
and then I'll be working on and supporting MMQ soon after that.

Edit: however, TML support is questionable - it depends on how the bitstream is implemented - if it's opensource and not using his restricted servers but allow direct pool mining, then that's fine, if on the other hand it requires his proprietary miner - then of course the answer is no.

Edit2: I just realised that the forum time was Sat when I made this post - so that 'Sat' above was 'today' for anyone not east of UTC 0 ... I live in the future

Okay I'll restart, test and get back to you, do you know reasons why it would say it cant connect to pool even though my pool info is correct?

EDIT: Just as I thought. restarted, giving me same error like my pool info is wrong for BOTH pools.

I've been bitcoin mining so I know how to setup the pool info after I joined two litecoin pools

doesn't even engage my gpu's as evident from my kill-a-watt showing idle usage about 230watts for my 3x5970's

0.13BTC reward to get me litecoin mining

Well as long as you ONLY have litecoin pools when mining - it should be OK.
If you have both BTC and Litcoin pools in the same cgminer - it won't work properly.
You can't mine 2 coins in the same instance of cgminer (as per the README)

Just so you know in advance, if you get to tuning the settings and mining performance, I got no idea
(other than to say you must me running at least SDK 2.6)

Does anyone know if CGMINER supports the new firmware version of tml on the modminer quad?
Reason I ask is that I have mine flashed with newest firmware and can't get either to run on the new version of CGMINER 2.7.6  Linux 32 git or windows 64 bit or the older 2.7.4 version.

TIA for any info.

WORKING! Now trying to get litecoin mining working; suggesting my pool info was wrong but,

tried two pools, and tried to run compiling with the javascript setup: http://forum.litecoin.net/index.php/topic,36.0.html

Should I restart? as cgminer for bitcoin has my memory speed low, i think i only have 2GB of ram but I have 3x5970's

I do have win7 64-bit...

EDIT: looks like it isn't balancing right. was balanced, then its becoming lopsided on the side that isn't the rolln or whatever type pool... or maybe just using the pool most thats on top of my list

... and then if it works ... good
If it doesn't it's then possible to try and work out why without wasting time looking at old versions.

7zip

M

Alright lets see how it goes

... update ...

2.7.4 I get error cgminer.exe has stopped working, when using old settings or new --balance parameter, every other setting the same

You should probably update then.

that parameter doesn't work ese

-balance or --balance, returns error

Use balance instead. Load balance will heavily favor pools with rollntime enabled.

using v2.6.5 and load balance two pools but one is getting only 5mhash->100Mhash out of my 2.1ghash/s

any fixes for this problem in new versions?

Now that is just bizarre. I tried it even on a windows machine and it didn't give me zero...

EDIT: Nm, can now reproduce.

--scrypt -I 20 -g 1 -v 1 -w 256 --shaders 1792 --thread-concurrency 12288 or 24000

Off the top of my head

It's been a noted bug in the windows version since the tittiez beta builds

I'm unable to reproduce this anywhere. Can you give me your whole command line minus any account details?