How update a 3.7.2 to 3.8 in a Rpi?
Have I to do all the process like new?
Thx!
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 175. (Read 5805527 times)
November 11, 2013, 07:02:31 AM
November 11, 2013, 05:23:50 AM
I've finally bitten the bullet and killed off GPU mining from the code and it will not be in the release I'm about to post. I have given ample warning that this was coming for some time on this forum thread and IRC about this and its time has come. It's also worth noting that even GPU mining has been used lately for botnets so cgminer once again is being flagged inappropriately as malware or a virus by various "authorities". I have left a 3.7 branch on git that is based on the last code that support GPU, OpenCL and scrypt code for those who wish to use it, but it is basically unchanged in terms of its mining code for GPUs compared with 3.7.2 which will be the last official release with GPU support. You are most welcome to fork, maintain, extend etc. the existing code provided you abide by the GPLv3 copyright restrictions that cgminer is released under. I am making a conscious decision and taking a stance to only support bitcoin by doing this and will consider all discussions regarding alternative cryptocurrencies as offtopic from here on. It is absolutely clear that we are in a stage where only ASICs matter in mining bitcoin, and cgminer is moving with the rapidly changing landscape that is bitcoin mining.
On the other hand, I think it's time to remind people of a warning I put up on this very forum thread almost 1 year to date, as I seriously worry about the massive amounts of money people are pouring into bitcoin mining hardware without being completely informed of the fact that they're unlikely to ever recoup the costs of the hardware they're purchasing.
Yes I am most aware of the apparently hypocritical nature of only supporting ASIC mining for bitcoin and then saying it's a waste of money to do so. I believe this situation is transient for the next few months though and we need to ride it out as best we can for the future of bitcoin.
On the other hand, I think it's time to remind people of a warning I put up on this very forum thread almost 1 year to date, as I seriously worry about the massive amounts of money people are pouring into bitcoin mining hardware without being completely informed of the fact that they're unlikely to ever recoup the costs of the hardware they're purchasing.
Yes I am most aware of the apparently hypocritical nature of only supporting ASIC mining for bitcoin and then saying it's a waste of money to do so. I believe this situation is transient for the next few months though and we need to ride it out as best we can for the future of bitcoin.
Thank you for keeping scrypt in cgminer for the past year
November 10, 2013, 08:40:59 PM
Why is it I need to run Zadig to run CGminer and the Alpha driver for BFGminer and bitminter for the BF1
We chose early on in our support of USB devices to talk directly to them via USB unlike all the other software out there. This means we deal with the Microsoft supplied WinUSB driver for any and all types of USB devices instead of using a separate 3rd party driver for every different device (eg ftdi_sio, sil, alpha etc). There are advantages to doing this in that it's much lower overhead and is more flexible in terms of what we can communicate with the device, but is more work for us to write the drivers to begin with, but then all operating systems end up using the same direct USB communications. Zadig is simply a tool that associates devices with whatever driver you choose (i.e. Zadig is NOT a driver) and happens to be the easiest way to associate the WinUSB driver with usb devices. Windows happens to be the only operating system that needs this sort of driver set up because on Linux and OSX we don't even use a driver to talk direct USB, bypassing the need for a driver entirely. 
November 10, 2013, 08:23:56 PM
Why is it I need to run Zadig to run CGminer and the Alpha driver for BFGminer and bitminter for the BF1
November 10, 2013, 06:45:18 PM
For anyone who has a V1 BlackArrow Bitfury board - the latest cgminer 3.8.1 (3.8.0 also) has the RPi source for a driver now - consider it an early release since there are certain improvements I'll make to it that I've already sorted out what to do - in future versions - but it already runs with great performance.
The configure option is --enable-bab
It runs at 39.9GH/s valid shares with a bit under 10% HW errors above the 39.9GH/s on a standard board
i.e. if you were to also count bad nonces returned (which I prefer not to but I will mention in case anyone wishes to compare that number) it's returning 44GH/s of good+bad nonces.
I've run it with a single board on Raspbian to write and test it - it's based on the V1 initialisation of a single board.
I based the I/O code on the chainminer GPIO/SPI code as should be obvious for anyone who looks at my driver-bab.c and chainminer (as I also mention that at the top of driver-bab.c)
It's a bit CPU hungry so soon I'll be spending more effort on reducing that - 20% CPU with a single board - I've only tested with a single board.
It also doesn't tune the chip at all - so there is also assured performance improvement there - it runs at default settings at the moment.
That's the next effort I'll expend on the driver.
If anyone has a standard V1 BitFury board I'd also be curious to know if it works with them.
The configure option is --enable-bab
It runs at 39.9GH/s valid shares with a bit under 10% HW errors above the 39.9GH/s on a standard board
i.e. if you were to also count bad nonces returned (which I prefer not to but I will mention in case anyone wishes to compare that number) it's returning 44GH/s of good+bad nonces.
I've run it with a single board on Raspbian to write and test it - it's based on the V1 initialisation of a single board.
I based the I/O code on the chainminer GPIO/SPI code as should be obvious for anyone who looks at my driver-bab.c and chainminer (as I also mention that at the top of driver-bab.c)
It's a bit CPU hungry so soon I'll be spending more effort on reducing that - 20% CPU with a single board - I've only tested with a single board.
It also doesn't tune the chip at all - so there is also assured performance improvement there - it runs at default settings at the moment.
That's the next effort I'll expend on the driver.
If anyone has a standard V1 BitFury board I'd also be curious to know if it works with them.
November 10, 2013, 05:35:35 PM
Since a new version came out before I was able to get my Win7 w/49 Port Hub rebooted, again, I went with the new version 3.8.1.
So far so good. One instance with 40 BE's and one with one Jalapeno.
Wonder if my 1 Ths BE's will recur again?
Thanks,
Sam
Thanks for quick testing. Unless the improved usb writes change helps indirectly, then nothing was done directly for that particular problem. So far so good. One instance with 40 BE's and one with one Jalapeno.
Wonder if my 1 Ths BE's will recur again?
Thanks,
Sam
November 10, 2013, 05:26:04 PM
Since a new version came out before I was able to get my Win7 w/49 Port Hub rebooted, again, I went with the new version 3.8.1.
So far so good. One instance with 40 BE's and one with one Jalapeno.
Wonder if my 1 Ths BE's will recur again?
Thanks,
Sam
So far so good. One instance with 40 BE's and one with one Jalapeno.
Wonder if my 1 Ths BE's will recur again?
Thanks,
Sam
November 10, 2013, 04:53:40 PM
Thanks very much for your quick testing guys. Posting a hotfix 3.8.1 release for windows users. Linux/osx users should be unaffected.
BFL devices are now working, but my 2 BEs are not. Who really cares about 2 BE's anyways? I'm gonna keep 3.8. Thanks for the fix!
Weird. Now 3.8.1 is working with my BEs. Well as I said, thanks for your hard work!
November 10, 2013, 04:51:49 PM
3.8.0 doesn't return anything for me - I get:
[2013-11-10 09:31:14] FAIL: USB get_lock not found (4:1)
[2013-11-10 09:31:14] FAIL: USB remove not already in use (4:1)
[2013-11-10 09:31:14] FAIL: USB get_lock not found (4:1)
[2013-11-10 09:31:14] FAIL: USB remove not already in use (4:1)
Weee what a fun ride, not. Apologies to windows users.
Windows users having trouble try this binary instead please:
http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe
Windows users having trouble try this binary instead please:
http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe
BFL devices are now working, but my 2 BEs are not. Who really cares about 2 BE's anyways? I'm gonna keep 3.8. Thanks for the fix!
November 10, 2013, 04:49:30 PM
Thanks very much for your quick testing guys. Posting a hotfix 3.8.1 release for windows users. Linux/osx users should be unaffected.
November 10, 2013, 04:47:50 PM
Weee what a fun ride, not. Apologies to windows users.
Windows users having trouble try this binary instead please:
http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe
Windows users having trouble try this binary instead please:
http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe
It's working on the Vista machine.
I'm in the process of rebooting the Win7 machine. It takes a while.
The new version is working for me so far, Win7, living dangerously without a reboot.
November 10, 2013, 04:42:52 PM
Weee what a fun ride, not. Apologies to windows users.
Windows users having trouble try this binary instead please:
http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe
Windows users having trouble try this binary instead please:
http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe
It's working on the Vista machine.
I'm in the process of rebooting the Win7 machine. It takes a while.
November 10, 2013, 04:13:47 PM
Weee what a fun ride, not. Apologies to windows users.
Windows users having trouble try this binary instead please:
http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe
Windows users having trouble try this binary instead please:
http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe
November 10, 2013, 03:57:07 PM
I can't remember the last time, if there was one, when I used .0 version for any length of time.
3.8.0 doesn't work for me either. Here is the text from a Vista 32 bit machine
3.8.0 doesn't work for me either. Here is the text from a Vista 32 bit machine
Same results for me on a Windows 7 x64 machine. Same LibUSB timeout errors. cgminer doesn't detect any devices.
November 10, 2013, 02:38:57 PM
But i want to tell "What To Use", no "To use what is in not in use".
When i plug the 6USB Erupter, CGMiner stops work if i'm working with the Bitburner.
When i plug the 6USB Erupter, CGMiner stops work if i'm working with the Bitburner.
Well like my daddy always used to say "want in one hand and crap in the other and see what fills up first"
Check the advanced USB options and see if there is a --usb command that does it the way you want it to. I tell my instances what I don't want them to use and how many of the devices that I do want them to use.
To tell it to use 6 BE's use
"--usb ICA:6,
I don't know the bitburner interface type/drivername.
Ok! Thank you so much.
November 10, 2013, 02:28:33 PM
... people must be pressing F5 lots on this forum 
...
Yes I was about to edit and add ...
If on the other hand it is indeed returning mostly rubbish results, it will affect the calculations of the hash rate also.
The good old saying: garbage in garbage out.
Yes the driver is not designed to correct the 'garbage in'
Aside: I do have a long standing TODO: comment in the code ...
https://github.com/ckolivas/cgminer/blob/master/driver-icarus.c#L1204
and the line after it.
But that is to do with timing mode also.
...Yes I was about to edit and add ...
If on the other hand it is indeed returning mostly rubbish results, it will affect the calculations of the hash rate also.
The good old saying: garbage in garbage out.
Yes the driver is not designed to correct the 'garbage in'
Aside: I do have a long standing TODO: comment in the code ...
https://github.com/ckolivas/cgminer/blob/master/driver-icarus.c#L1204
and the line after it.
But that is to do with timing mode also.
When you say "But that is to do with timing mode also." do you mean overriding the default timings? Or that the default timings may be an issue as well?
I had two more BE's start reporting GHash rates overnight with 3.7.2.
November 10, 2013, 02:15:24 PM
But i want to tell "What To Use", no "To use what is in not in use".
When i plug the 6USB Erupter, CGMiner stops work if i'm working with the Bitburner.
When i plug the 6USB Erupter, CGMiner stops work if i'm working with the Bitburner.
Well like my daddy always used to say "want in one hand and crap in the other and see what fills up first"
Check the advanced USB options and see if there is a --usb command that does it the way you want it to. I tell my instances what I don't want them to use and how many of the devices that I do want them to use.
To tell it to use 6 BE's use
"--usb ICA:6,
I don't know the bitburner interface type/drivername.
November 10, 2013, 02:12:13 PM
New release: Version 3.8.0, 10th November 2013
in keeping with even number releases sounding more stable.
in keeping with even number releases sounding more stable.
I can't remember the last time, if there was one, when I used .0 version for any length of time.
3.8.0 doesn't work for me either. Here is the text from a Vista 32 bit machine
Code:
cgminer version 3.8.0 - Started: [2013-11-10 11:27:12]
------------------------------------------------------------------------------
(5s):0.000 (avg):0.000h/s | A:0 R:0 HW:0 WU:0.0/m
ST: 11 SS: 0 NB: 1 LW: 0 GF: 0 RF: 0
Connected to pit.deepbit.net diff 1 with LP as user [email protected]_erupter
Block: 81e15399... Diff:511M Started: [11:27:11] Best share: 0
------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
------------------------------------------------------------------------------
[2013-11-10 11:27:04] Started cgminer 3.8.0
[2013-11-10 11:27:07] AMU 0 SendWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
[2013-11-10 11:27:07] FAIL: USB get_lock not found (5:4)
[2013-11-10 11:27:07] FAIL: USB remove not already in use (5:4)
[2013-11-10 11:27:10] No devices detected!
[2013-11-10 11:27:10] Waiting for USB hotplug devices or press q to quit
[2013-11-10 11:27:10] Probing for an alive pool
[2013-11-10 11:27:11] Pool 2 difficulty changed to 2
[2013-11-10 11:27:11] Switching to pool 2 http://stratum.btcguild.com:3333 -
rst alive pool
[2013-11-10 11:27:11] Network diff set to 511M
[2013-11-10 11:27:11] Pool 1 http://pit.deepbit.net:8332 alive, testing stabi
ty
[2013-11-10 11:27:11] Switching to pool 1 http://pit.deepbit.net:8332
[2013-11-10 11:27:11] Long-polling activated for http://pit.deepbit.net:8332/
stenChannel
[2013-11-10 11:27:13] Pool 0 slow/down or URL or credentials invalid
Had to reboot the machine to get 3.7.2 to work again. I also rebooted the machine before trying 3.8.0.
Sam
November 10, 2013, 02:09:18 PM
Hi guys, i'm running CGMiner under Windows 7.
I have 1 Bitburner Fury and 6 USB Erupter
With command i must use to tell CGMiner to use Only Bitburner Fury or Only 6 Usb Erupter?
Thank you
I have 1 Bitburner Fury and 6 USB Erupter
With command i must use to tell CGMiner to use Only Bitburner Fury or Only 6 Usb Erupter?
Thank you
To tell it not to use BE's use
"--usb ICA:0"
Read the advanced usb options in the readme for the proper name for the other device plus many more useful options.
But i want to tell "What To Use", no "To use what is in not in use".
When i plug the 6USB Erupter, CGMiner stops work if i'm working with the Bitburner.
November 10, 2013, 02:06:20 PM
Hi guys, i'm running CGMiner under Windows 7.
I have 1 Bitburner Fury and 6 USB Erupter
With command i must use to tell CGMiner to use Only Bitburner Fury or Only 6 Usb Erupter?
Thank you
I have 1 Bitburner Fury and 6 USB Erupter
With command i must use to tell CGMiner to use Only Bitburner Fury or Only 6 Usb Erupter?
Thank you
To tell it not to use BE's use
"--usb ICA:0"
Read the advanced usb options in the readme for the proper name for the other device plus many more useful options.
Jump to: