And very thankful for you work and efforts.....
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 159. (Read 5805670 times)
December 09, 2013, 11:28:31 PM
Ahh the joys of doing something cool and then getting pulled every direction... I would be willing to let you play with mine if you wanted to mine on my pool account and mail it back when done
And very thankful for you work and efforts.....
And very thankful for you work and efforts.....
December 09, 2013, 11:22:57 PM
I just got a hex16b, there is a patch for cgminer but i cant figure out or find info on how to apply patch.
Any help appreciated. And thanks
Any help appreciated. And thanks
See the following quote:
If Kano and/or I have been offered new hardware, or offered support to develop drivers for hardware, we will develop and include the code in cgminer and actively maintain and develop it. With various manufacturers we have been engaged on this level at wildly different stages in development. Some very early in hardware development (like cointerra and hashfast), some just before distribution of the product (like BFLSC and bi*fury devices), some after the fact when manufacturer code and hardware has been out for a while (like kncminer and much later for avalon). These examples by no means include everyone. Our involvement in the driver has been proportional to the duration of our involvement.
If someone wishes to develop their own driver and are happy to maintain it for cgminer, they are welcome to submit a pull request for their code to the cgminer git tree - Note that it will not be instantly accepted but usually it's simply a matter of making their code consistent with cgminer and Kano and/or I will provide comments about what changes need to be made for the code to be included. While I can keep the code building satisfactorily with changes to cgminer, the onus will then fall upon the person who pushed the original code to maintain it and keep it up to date since neither Kano nor I can test changes to the driver without actually having the hardware ourselves. If down the track the original maintainer has not been keeping up to date with cgminer, and users report that the driver has stopped working, the original driver author will be contacted for fixes. If no fixes are forthcoming, the driver will then be removed from cgminer (this happened in the case of the ztex driver). With the very rapid pace of development of code in cgminer lately, this can happen all too easily. Historically this sort of code does not stand the test of time.
If there are drivers out there based on forked earlier cgminer code that we have never heard about, and the original author makes no attempt to get the code incorporated into cgminer, that code cannot be meaningfully incorporated into cgminer even if we're made aware of its existence for the same reason we cannot maintain code for hardware we don't have.
The device you're talking about belongs to the last categoryIf someone wishes to develop their own driver and are happy to maintain it for cgminer, they are welcome to submit a pull request for their code to the cgminer git tree - Note that it will not be instantly accepted but usually it's simply a matter of making their code consistent with cgminer and Kano and/or I will provide comments about what changes need to be made for the code to be included. While I can keep the code building satisfactorily with changes to cgminer, the onus will then fall upon the person who pushed the original code to maintain it and keep it up to date since neither Kano nor I can test changes to the driver without actually having the hardware ourselves. If down the track the original maintainer has not been keeping up to date with cgminer, and users report that the driver has stopped working, the original driver author will be contacted for fixes. If no fixes are forthcoming, the driver will then be removed from cgminer (this happened in the case of the ztex driver). With the very rapid pace of development of code in cgminer lately, this can happen all too easily. Historically this sort of code does not stand the test of time.
If there are drivers out there based on forked earlier cgminer code that we have never heard about, and the original author makes no attempt to get the code incorporated into cgminer, that code cannot be meaningfully incorporated into cgminer even if we're made aware of its existence for the same reason we cannot maintain code for hardware we don't have.
December 09, 2013, 11:15:02 PM
I just got a hex16b, there is a patch for cgminer but i cant figure out or find info on how to apply patch.
Any help appreciated. And thanks
Any help appreciated. And thanks
December 09, 2013, 06:42:33 PM
New version: 3.8.5 - 10th December 2013
I had to release a new stable version just before moving house as I may be busy and not have great internet access for a bit. Apologies for I've upgraded my desktop to Ubuntu 13.10 a little earlier than usual so the ubuntu x86_64 binaries are for that version now (though they will probably still work with 13.04).
Human readable changelog:
- BFL SC devices will now throttle 3 degrees below cutoff (82 degrees) and cut off work at the lower 85 degrees, restarting when they get below 80. If you wish to aim for a higher maximum, use the --temp-cutoff feature (90 was the old maximum). If you set it to zero it will disable this behaviour. (I'm preparing for our summer here
)
- BFL SC devices will be less aggressive with their fan control now, allowing temps to drift up a little more before going to maximum speed.
- Fixes for builds with --with-system-libusb enabled not working with older libusbs. (Note that using this option is not recommended unless you can't install udev anyway).
- Fixes for warnings with ./autogen.sh
- Code cleanups of unused GPU code
- Cgminer will now try to issue a USB reset on devices that have failed to hopefully get them back up and running again.
- Dramatically improved communications for USB1.1 devices on hubs that don't have multiple transaction translators or have none (like USB3 hubs). The USB1.1 devices currently affected are Asicminer Block Erupters and Red/Blue fury USB sticks.
- Fixes for leaving too many open files problem with repeatedly hotplugging devices on low resource systems (eg RPi).
- Fix a potential API crash.
- The build will be much quieter around the jansson part now.
- More hashfast driver additions (no, the real hardware still doesn't exist).
Full changelog:
- Increase the BFLSC overtemp to 75 for fanspeed to maximum.
- Set bflsc cutoff temperature to 85 degrees and throttle 3 degrees below the
cutoff temperature.
- Only set LIBUSB_TRANSFER_ADD_ZERO_PACKET for libusb versions we know include
support for.
- Provide a helper function that can reset cgsems to zero.
- Add to cgminer_CPPFLAGS instead of redefining them.
- Attempt a libusb reset device on usb devices that have stopped responding.
- Replace deprecated use of INCLUDES with _CPPFLAGS.
- Remove more unused GPU code.
- Attempt USB device resets on usb read/write errors that will normally cause
the device to drop out.
- Quieten down jansson component of build.
- Cache the bool value for usb1.1 in _usb_write
- Initialise usb locks within usbutils.c instead of exporting them.
- Imitate a transaction translator for all usb1.1 device writes to compensate
for variable quality hubs and operating system support.
- Rationalise variables passed to usb_bulk_transfer.
- Unlink files opened as semaphores on releasing them.
- Remove user configuration flag from pll bypass enabling in hashfast driver.
- Provide an hfa-dfu-boot option for resetting hashfast devices for
reprogramming.
- Fixed one byte stack overflow in mcast recvfrom.
- Having changed C_MAX means we don't calloc enough for usb stats, off by one.
- Don't free the info struct on hashfast shutdown since it's still accessed
after a device is removed.
I had to release a new stable version just before moving house as I may be busy and not have great internet access for a bit. Apologies for I've upgraded my desktop to Ubuntu 13.10 a little earlier than usual so the ubuntu x86_64 binaries are for that version now (though they will probably still work with 13.04).
Human readable changelog:
- BFL SC devices will now throttle 3 degrees below cutoff (82 degrees) and cut off work at the lower 85 degrees, restarting when they get below 80. If you wish to aim for a higher maximum, use the --temp-cutoff feature (90 was the old maximum). If you set it to zero it will disable this behaviour. (I'm preparing for our summer here
)- BFL SC devices will be less aggressive with their fan control now, allowing temps to drift up a little more before going to maximum speed.
- Fixes for builds with --with-system-libusb enabled not working with older libusbs. (Note that using this option is not recommended unless you can't install udev anyway).
- Fixes for warnings with ./autogen.sh
- Code cleanups of unused GPU code
- Cgminer will now try to issue a USB reset on devices that have failed to hopefully get them back up and running again.
- Dramatically improved communications for USB1.1 devices on hubs that don't have multiple transaction translators or have none (like USB3 hubs). The USB1.1 devices currently affected are Asicminer Block Erupters and Red/Blue fury USB sticks.
- Fixes for leaving too many open files problem with repeatedly hotplugging devices on low resource systems (eg RPi).
- Fix a potential API crash.
- The build will be much quieter around the jansson part now.
- More hashfast driver additions (no, the real hardware still doesn't exist).
Full changelog:
- Increase the BFLSC overtemp to 75 for fanspeed to maximum.
- Set bflsc cutoff temperature to 85 degrees and throttle 3 degrees below the
cutoff temperature.
- Only set LIBUSB_TRANSFER_ADD_ZERO_PACKET for libusb versions we know include
support for.
- Provide a helper function that can reset cgsems to zero.
- Add to cgminer_CPPFLAGS instead of redefining them.
- Attempt a libusb reset device on usb devices that have stopped responding.
- Replace deprecated use of INCLUDES with _CPPFLAGS.
- Remove more unused GPU code.
- Attempt USB device resets on usb read/write errors that will normally cause
the device to drop out.
- Quieten down jansson component of build.
- Cache the bool value for usb1.1 in _usb_write
- Initialise usb locks within usbutils.c instead of exporting them.
- Imitate a transaction translator for all usb1.1 device writes to compensate
for variable quality hubs and operating system support.
- Rationalise variables passed to usb_bulk_transfer.
- Unlink files opened as semaphores on releasing them.
- Remove user configuration flag from pll bypass enabling in hashfast driver.
- Provide an hfa-dfu-boot option for resetting hashfast devices for
reprogramming.
- Fixed one byte stack overflow in mcast recvfrom.
- Having changed C_MAX means we don't calloc enough for usb stats, off by one.
- Don't free the info struct on hashfast shutdown since it's still accessed
after a device is removed.
December 09, 2013, 02:26:45 PM
I'm running 2 5970s for scrypt mining on cgminer using xubuntu 13.10
cgminer no longer supports scrypt or GPU mining. Check here for some folks that may be able to help: https://litecointalk.org/index.php?topic=6925.0
What was the last official version that works with GPUs?
Version 3.7.2 for GPU scrypt mining
ok thanks
December 09, 2013, 02:12:39 PM
I'm running 2 5970s for scrypt mining on cgminer using xubuntu 13.10
cgminer no longer supports scrypt or GPU mining. Check here for some folks that may be able to help: https://litecointalk.org/index.php?topic=6925.0
What was the last official version that works with GPUs?
Version 3.7.2 for GPU scrypt mining
December 09, 2013, 01:55:18 PM
I'm running 2 5970s for scrypt mining on cgminer using xubuntu 13.10
cgminer no longer supports scrypt or GPU mining. Check here for some folks that may be able to help: https://litecointalk.org/index.php?topic=6925.0
What was the last official version that works with GPUs?
December 09, 2013, 12:30:19 PM
Alrighty, try the rc I posted next please then.
"rc" has been running for 7 hours now and has auto-replugged 5 of my devices, so I have 0-33 (with gaps) and 34-38, but no zombies. Pool hash rate seems OK. I am seeing regular solid LEDs coming on and then going off again after a few seconds, sometimes in batches, which presumably indicates something "not-quite right", but at least any errors that do happen are being recovered from :-) I forgot to log this run. I can stop and restart if necessary. Do you think you might need the log? 
December 09, 2013, 11:46:51 AM
Sorry for the off topic:
Con have you made a firmware for the 60GH singles like you did for the Jallys?
I did a search and found nothing.
Con have you made a firmware for the 60GH singles like you did for the Jallys?
I did a search and found nothing.
December 09, 2013, 11:18:49 AM
I'm running 2 5970s for scrypt mining on cgminer using xubuntu 13.10
cgminer no longer supports scrypt or GPU mining. Check here for some folks that may be able to help: https://litecointalk.org/index.php?topic=6925.0
Yeah, I saw that already, forgot my pass etc
No, I'm running it on cgminer 3.7.2 or the latest version to support scrypt
December 09, 2013, 11:13:52 AM
I'm running 2 5970s for scrypt mining on cgminer using xubuntu 13.10
cgminer no longer supports scrypt or GPU mining. Check here for some folks that may be able to help: https://litecointalk.org/index.php?topic=6925.0
December 09, 2013, 09:40:48 AM
Bro, I appreciate your program, but I need your help.
I'm running 2 5970s for scrypt mining on cgminer using xubuntu 13.10
I have amd catalyst 12.8 and AMD APP SDK v2.9
When I run cgminer as
./cgminer --scrypt -o stratum+tcp://mypool:port -u user -p x --shaders 3200 --intensity 13 my screen blacks out
If I use the same command, but replace shaders to 1600 my pc freezes.
So I've trued and find my max thread-concurrency, and it looks like it can't get higher then --thread-concurrency 1024
I've been searching for a week and was able to get my rig to 1500khash/s but wasn't getting any shares.
Could you please try and help me?
I'm running 2 5970s for scrypt mining on cgminer using xubuntu 13.10
I have amd catalyst 12.8 and AMD APP SDK v2.9
When I run cgminer as
./cgminer --scrypt -o stratum+tcp://mypool:port -u user -p x --shaders 3200 --intensity 13 my screen blacks out
If I use the same command, but replace shaders to 1600 my pc freezes.
So I've trued and find my max thread-concurrency, and it looks like it can't get higher then --thread-concurrency 1024
I've been searching for a week and was able to get my rig to 1500khash/s but wasn't getting any shares.
Could you please try and help me?
December 09, 2013, 09:20:29 AM
Finally got an error - AMIU 27 LED full on but no zombie reported. The hash rate is sitting at zero. Screenshot in logfile. I enabled debug for a while then tried manual re-plugging. Device appeared as zombie when removed, then when re-plugged it appeared as AMU 34. 2nd screenshot also in file. Test then ended. I'll try w2d10 next.
Logfile here:
https://dl.dropboxusercontent.com/u/44240170/logfile-w1d10.txt
Note: Just started w2d10 and it does the same strange thing as w1d10 at startup - all AMU LEDs go off as normal, then they all come back on again. It takes a second or so for a few to go out, then it works a while with just those few, then the rest go out and mining continues with all devices.
Note 2: I have a zombie AMU 10 already after only a a few minutes...
Manually re-plugged as AMU 34. Test continuing.
Try this one instead then please:Logfile here:
https://dl.dropboxusercontent.com/u/44240170/logfile-w1d10.txt
Note: Just started w2d10 and it does the same strange thing as w1d10 at startup - all AMU LEDs go off as normal, then they all come back on again. It takes a second or so for a few to go out, then it works a while with just those few, then the rest go out and mining continues with all devices.
Note 2: I have a zombie AMU 10 already after only a a few minutes...
Manually re-plugged as AMU 34. Test continuing.http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe
Me too or shall I stay with w2d10 which is still clean, 11 hours in?
Thanks - I got 13 hours on that run, then had an unrelated major system crash. Eventually got things fixed and another 11 hours on w2d10 which performed well throughout. I'll grab the release candidate next if I can, but w2d10 is very well behaved for me.
December 09, 2013, 05:18:53 AM
Started latest trial version of cgminer, renamed as cgminer-2013-12-08. The AMU LEDs initially all go off, then come back on again and it seems to take ages for all AMU LEDs to go out, then hash rates initially all show 150/ for a while, then 252/ ... afterwards increasing to the normal 335/ - see screenshots in logfile. I haven't seen this behaviour before!
Test was left running overnight. When I came back this morning there were 6 zombies and a couple with zero hash rates, please see 2nd screenshot in logfile. Test stopped
Logfile here:
https://dl.dropboxusercontent.com/u/44240170/logfile-2013-12-08.txt
Alrighty, try the rc I posted next please then. Test was left running overnight. When I came back this morning there were 6 zombies and a couple with zero hash rates, please see 2nd screenshot in logfile. Test stopped
Logfile here:
https://dl.dropboxusercontent.com/u/44240170/logfile-2013-12-08.txt
December 09, 2013, 05:12:33 AM
Started latest trial version of cgminer, renamed as cgminer-2013-12-08. The AMU LEDs initially all go off, then come back on again and it seems to take ages for all AMU LEDs to go out, then hash rates initially all show 150/ for a while, then 252/ ... afterwards increasing to the normal 335/ - see screenshots in logfile. I haven't seen this behaviour before!
Test was left running overnight. When I came back this morning there were 6 zombies and a couple with zero hash rates, please see 2nd screenshot in logfile. Test stopped
Logfile here:
https://dl.dropboxusercontent.com/u/44240170/logfile-2013-12-08.txt
Test was left running overnight. When I came back this morning there were 6 zombies and a couple with zero hash rates, please see 2nd screenshot in logfile. Test stopped
Logfile here:
https://dl.dropboxusercontent.com/u/44240170/logfile-2013-12-08.txt
December 09, 2013, 04:15:08 AM
My site (ck.kolivas.org) will be down for some scheduled maintenance for a few hours shortly.
Here's a windows release candidate for what I'm likely to release as a new version tomorrow in case people want something to play with before it goes down:http://ck.kolivas.org/apps/cgminer/temp/cgminer-rc.exe
Contains the TT fixes discussed earlier, and auto usb reset of devices that have failed comms.
December 08, 2013, 07:04:42 PM
Finally got an error - AMIU 27 LED full on but no zombie reported. The hash rate is sitting at zero. Screenshot in logfile. I enabled debug for a while then tried manual re-plugging. Device appeared as zombie when removed, then when re-plugged it appeared as AMU 34. 2nd screenshot also in file. Test then ended. I'll try w2d10 next.
Logfile here:
https://dl.dropboxusercontent.com/u/44240170/logfile-w1d10.txt
Note: Just started w2d10 and it does the same strange thing as w1d10 at startup - all AMU LEDs go off as normal, then they all come back on again. It takes a second or so for a few to go out, then it works a while with just those few, then the rest go out and mining continues with all devices.
Note 2: I have a zombie AMU 10 already after only a a few minutes... Manually re-plugged as AMU 34. Test continuing.
Try this one instead then please:Logfile here:
https://dl.dropboxusercontent.com/u/44240170/logfile-w1d10.txt
Note: Just started w2d10 and it does the same strange thing as w1d10 at startup - all AMU LEDs go off as normal, then they all come back on again. It takes a second or so for a few to go out, then it works a while with just those few, then the rest go out and mining continues with all devices.
Note 2: I have a zombie AMU 10 already after only a a few minutes...
Manually re-plugged as AMU 34. Test continuing.http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe
Me too or shall I stay with w2d10 which is still clean, 11 hours in?
December 08, 2013, 06:51:40 PM
Finally got an error - AMIU 27 LED full on but no zombie reported. The hash rate is sitting at zero. Screenshot in logfile. I enabled debug for a while then tried manual re-plugging. Device appeared as zombie when removed, then when re-plugged it appeared as AMU 34. 2nd screenshot also in file. Test then ended. I'll try w2d10 next.
Logfile here:
https://dl.dropboxusercontent.com/u/44240170/logfile-w1d10.txt
Note: Just started w2d10 and it does the same strange thing as w1d10 at startup - all AMU LEDs go off as normal, then they all come back on again. It takes a second or so for a few to go out, then it works a while with just those few, then the rest go out and mining continues with all devices.
Note 2: I have a zombie AMU 10 already after only a a few minutes... Manually re-plugged as AMU 34. Test continuing.
Try this one instead then please:Logfile here:
https://dl.dropboxusercontent.com/u/44240170/logfile-w1d10.txt
Note: Just started w2d10 and it does the same strange thing as w1d10 at startup - all AMU LEDs go off as normal, then they all come back on again. It takes a second or so for a few to go out, then it works a while with just those few, then the rest go out and mining continues with all devices.
Note 2: I have a zombie AMU 10 already after only a a few minutes...
Manually re-plugged as AMU 34. Test continuing.http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe
Me too or shall I stay with w2d10 which is still clean, 11 hours in?
December 08, 2013, 05:51:25 PM
Finally got an error - AMIU 27 LED full on but no zombie reported. The hash rate is sitting at zero. Screenshot in logfile. I enabled debug for a while then tried manual re-plugging. Device appeared as zombie when removed, then when re-plugged it appeared as AMU 34. 2nd screenshot also in file. Test then ended. I'll try w2d10 next.
Logfile here:
https://dl.dropboxusercontent.com/u/44240170/logfile-w1d10.txt
Note: Just started w2d10 and it does the same strange thing as w1d10 at startup - all AMU LEDs go off as normal, then they all come back on again. It takes a second or so for a few to go out, then it works a while with just those few, then the rest go out and mining continues with all devices.
Note 2: I have a zombie AMU 10 already after only a a few minutes... Manually re-plugged as AMU 34. Test continuing.
Try this one instead then please:Logfile here:
https://dl.dropboxusercontent.com/u/44240170/logfile-w1d10.txt
Note: Just started w2d10 and it does the same strange thing as w1d10 at startup - all AMU LEDs go off as normal, then they all come back on again. It takes a second or so for a few to go out, then it works a while with just those few, then the rest go out and mining continues with all devices.
Note 2: I have a zombie AMU 10 already after only a a few minutes...
Manually re-plugged as AMU 34. Test continuing.http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe
December 08, 2013, 05:12:22 PM
I am trying to sort through the getwork logic in Anubis, given the fact that with the stratum protocol getwork != number of shares the calculations are off.
...
The number pretty much means nothing any more....
In stratum, you get work from the pool once every so often (~30s) and can generate enough work in that 30s for 16million TH/s without using a larger than default nonce2 or roll-n-time.
Increasing the size of nonce2 by 32 bits will allow you to generate more than another 9 orders of magnitude larger amount of work ...
Also the numbers were never similar before, unless someone was using the old getwork protocol to a pool that didn't support roll-n-time and was hashing with REALLY slow hardware.
I would suggest you make it display information appropriate for current hardware.
Jump to: