EDIT: Or is your concern existing solo miners? The previous versions of cgminer could not meaningfully mine solo so I didn't think anyone was trying to.
I did not know this. I have frequently solo-mined with my few Block Erupters in the past, and even with my GPUs in years past, thinking I was essentially playing the lottery. I'm a little disappointed to learn that I was basically doing nothing. (But only a little disappointed; I knew my chance of actually hitting anything was pretty darn close to zero.) 
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 114. (Read 5805649 times)
March 18, 2014, 03:31:54 PM
March 18, 2014, 03:04:55 PM
Thanks for the release.
However, I don't think it's the right thing to do to make solo miners mine by default to an address owned by you, unless they pay attention to the documentation and add the --btc-address option.
Some people like me mine solo even if they have a low hashing power. They do so because pool mining wouldn't provide a significant income, and they rather take their chance with the solo mining lottery. You shouldn't assume that somebody doing solo mining has millions worth of equipment so if they don't pay attention to your documentation it's only fair to punish them by ripping them off of their mining.
In any case, simply upgrading a piece of software shouldn't require the user to add an option in order to keep the previous behaviour. And in this case the change in behaviour is quite dramatic: all mining will go to your address instead of the one belonging to the user!
This is a bad default because it is most likely not what a user would want to do by default, and the most sensible default behaviour should be for cgminer to refuse to start and print an error.
The problem here is that obviously there are money involved, and I think this really reflects negatively on your reputation and the reputation of cgminer.
The fact that a piece of software is given away for free doesn't mean that the developer doesn't have to behave professionally and treat his users with respect.
Other high profile open source software like Linux or Apache certainly would never do anything like that.
No you're reading it wrong. It will not mine solo unless you go to the effort of setting up bitcoind AND adding it as a pool and NOT follow the instructions that discretely say to add a btc address. It does NOT change default behaviour one bit for existing miners with existing configurations.However, I don't think it's the right thing to do to make solo miners mine by default to an address owned by you, unless they pay attention to the documentation and add the --btc-address option.
Some people like me mine solo even if they have a low hashing power. They do so because pool mining wouldn't provide a significant income, and they rather take their chance with the solo mining lottery. You shouldn't assume that somebody doing solo mining has millions worth of equipment so if they don't pay attention to your documentation it's only fair to punish them by ripping them off of their mining.
In any case, simply upgrading a piece of software shouldn't require the user to add an option in order to keep the previous behaviour. And in this case the change in behaviour is quite dramatic: all mining will go to your address instead of the one belonging to the user!
This is a bad default because it is most likely not what a user would want to do by default, and the most sensible default behaviour should be for cgminer to refuse to start and print an error.
The problem here is that obviously there are money involved, and I think this really reflects negatively on your reputation and the reputation of cgminer.
The fact that a piece of software is given away for free doesn't mean that the developer doesn't have to behave professionally and treat his users with respect.
Other high profile open source software like Linux or Apache certainly would never do anything like that.
EDIT: Or is your concern existing solo miners? The previous versions of cgminer could not meaningfully mine solo so I didn't think anyone was trying to.
March 18, 2014, 02:16:06 PM
Thanks for the release.
However, I don't think it's the right thing to do to make solo miners mine by default to an address owned by you, unless they pay attention to the documentation and add the --btc-address option.
Some people like me mine solo even if they have a low hashing power. They do so because pool mining wouldn't provide a significant income, and they rather take their chance with the solo mining lottery. You shouldn't assume that somebody doing solo mining has millions worth of equipment so if they don't pay attention to your documentation it's only fair to punish them by ripping them off of their mining.
In any case, simply upgrading a piece of software shouldn't require the user to add an option in order to keep the previous behaviour. And in this case the change in behaviour is quite dramatic: all mining will go to your address instead of the one belonging to the user!
This is a bad default because it is most likely not what a user would want to do by default, and the most sensible default behaviour should be for cgminer to refuse to start and print an error.
The problem here is that obviously there are money involved, and I think this really reflects negatively on your reputation and the reputation of cgminer.
The fact that a piece of software is given away for free doesn't mean that the developer doesn't have to behave professionally and treat his users with respect.
Other high profile open source software like Linux or Apache certainly would never do anything like that.
However, I don't think it's the right thing to do to make solo miners mine by default to an address owned by you, unless they pay attention to the documentation and add the --btc-address option.
Some people like me mine solo even if they have a low hashing power. They do so because pool mining wouldn't provide a significant income, and they rather take their chance with the solo mining lottery. You shouldn't assume that somebody doing solo mining has millions worth of equipment so if they don't pay attention to your documentation it's only fair to punish them by ripping them off of their mining.
In any case, simply upgrading a piece of software shouldn't require the user to add an option in order to keep the previous behaviour. And in this case the change in behaviour is quite dramatic: all mining will go to your address instead of the one belonging to the user!
This is a bad default because it is most likely not what a user would want to do by default, and the most sensible default behaviour should be for cgminer to refuse to start and print an error.
The problem here is that obviously there are money involved, and I think this really reflects negatively on your reputation and the reputation of cgminer.
The fact that a piece of software is given away for free doesn't mean that the developer doesn't have to behave professionally and treat his users with respect.
Other high profile open source software like Linux or Apache certainly would never do anything like that.
March 18, 2014, 01:57:31 PM
@ckolivas
THX for the fast Fix and i will test it with U1 HW 1.2 and with U2+
regards
THX for the fast Fix and i will test it with U1 HW 1.2 and with U2+
regards
March 18, 2014, 07:18:32 AM
New version: 4.2.0, 18th March 2014
Major feature upgrades - main one being low overhead scaleable solo mining to bitcoind, bugfixes and driver improvements.
Human readable changelog:
- Low overhead ultra-scaleable solo mining to bitcoind. Quote from the documentation update:
- Massive improvements to mining efficiency when using pooled GBT mining.
- Stratum low level bugfixes that may have caused random corruption/crashes.
- Miner.php updates
- Drillbit updates
- Antminer S1 updates
- Fix for repeatedly trying to reset a usb device when it has failed.
- Fix for Icarus devices (such as antminer U1 or block erupters) being switched off and not restarting.
- More accurate hashrates on cointerra devices, with a more reliable bitmap of working cores and now a count such as:
- Fix for memory leak on hashfast devices.
- Fix for crashes on multiple failed inits on hashfast devices.
- Show what quadrant of a hashfast core has failed if possible
- Fix for hashfast API stats output being invalid json
- Hashfast api stats output names are unique making them more easily parseable
- Inputting URLs without a prefix (such as http:// or stratum+tcp://) will now assume stratum to speed up initial connections.
- On linux we no longer use sysv semaphores to prevent multiple instances of cgminer trying to use the same device, meaning you will no longer run out of semaphore resources or have failures to grab devices on restarting.
- Numerous other low level fixes and improvements.
Full changelog:
- Fix missing htobe16 on windows and meaningless >u32 string warning.
- Software ntime roll for all hashfast devices.
- Silence harmless warning.
- Drop a failed restart icarus device to allow it to be rehotplugged if
possible.
- Work with more than one transaction.
- Kill gbt solo pools that don't respond to the gbt request 5 times
sequentially.
- Fix ser_number for no remaining val byte.
- Create a work item and stage it when updating the gbt solo template to allow
new block detection and restart code to work.
- Test block hash as well as block height when solo mining to ensure we haven't
been mining on an orphan branch.
- Fix transaction processing for gbt solo.
- Encode height using integer varint format.
- Make new block detection message not show in gbt solo from test_work_current
- Add block detection via getblockcount polling in gbt solo and update gbt
template every 60 seconds.
- Iterate over transactions twice to malloc only once when copying all the
transaction data.
- Update solo coinbase regularly and submit as gbt work
- Only show merkle hashes for solo mining in debug mode.
- Set correct flag for solo work.
- Generate gbt solo work emulating stratum work construction.
- Set the diff as a double sdiff from gbt solo data.
- Move swork.diff out of the stratum work section to be shared as sdiff.
- Generate a header bin from gbt solo as per the cached stratum one.
- Store strings similar to stratum's when decoding gbt solo
- Avoid allocing and freeing stratum strings that should be fixed length.
- Run parser through detect_stratum after stratum+tcp:// is force added
- Remove unnecessary header length calculation for stratum header binary and
only binary convert the correct length of the header.
- Share more fields between stratum and gbt
- Share coinbase_len variable b/w stratum and gbt and setup more gbt solo
parameters.
- Generate a valid coinbase and set nonce2offset for gbt solo
- Move scriptsig header bin conversion to setup gbt solo
- Create our own custom scriptsig base.
- Add helper functions for creating script signature templates and beging
building template.
- Do gbt solo decoding under gbt lock.
- Add more gbt variable decoding from gbt solo information.
- Store all the transaction data in binary form when using GBT
- When setting up solo mining, check validity of bitcoin address against
bitcoind
- Make pooled GBT mining use merkle bin optimisations slated for solo mining.
- Abstract out the merkle bin calculation for gbt solo
- Implement efficient merkle tree base from solo GBT information.
- miner.php custom formatting and row counter '#'
- Drillbit: Fix for underestimating hash rate from Bitfury devices
- Send per-core hashrates at regular ~5min intervals back to cta devices.
- Calculate the cta per core hashrate at 5 minute intervals.
- Check the bits of the correct core in cta bit count.
- Display the bit count along with the bitmap for each cta core in the API stats
output.
- Store and display the per core hashrate on cta relative to each work restart.
- Decrease the time we wait for unsetting a core on the cta bitmap to correspond
with the lower max diff of 32.
- Set max diff on cointerra devices to 32 which is still only 11 shares per
second but allows for earlier confirmation of per core hashrates.
- Keep track of when the last restart and work updates were triggered and
provide helper functions for knowing the time since then.
- hashfast make api stats field names unique
- Fix gcc longjmp warning in api.c
- Add a per-core hashrate to the cta API stats.
- miner.php support edevs and estats
- API - put edevstatus where it was supposed to be
- Icarus - allow timing mode to work with ANU and not slow it down
- drillbit - remove warnings
- drillbit - minor code tidy up
- Drillbit: Change language around 'void' to warning about limiter disabled
- Drillbit: Fix accidental over-counting of HW errors
- Drillbit: --drillbit-auto parameter for tweakable custom tuning of ASIC speeds
- Drillbit: Output warning if board reports void warranty
- Drillbit: Add Avalon & drillbit-autotune notes to ASIC-README
- Drillbit: Limit work sent out to 8 units in a single pass, was DoSing a full
double scroll
- Drillbit: Move drillbit_empty_buffer calls to only when errors occur, were
limiting performance on Windows
- Fix Windows bug with libusb_reset_device returning SUCCESS for disconnected
device
- Drillbit: Fix some warnings
- Drillbit: Add --drillbit-autotune option for device to dynamically alter clock
speed
- Drillbit: Fix typo in previous commit
- Drillbit: Remove default config in cgminer, rely on defaults in firmware
- Drillbit: Combine split USB transfer for sending new work, reduce overhead
- Drillbit: Add support for protocol V4, with device-agnostic board
configuration data
- Drillbit driver: Add support for Avalon-based Drillbit miners
- API - add edevs and estats - to only show enabled devices
- Check device data exists on a hfa instance before trying to reinit it.
- Print off what quadrant regulator failed if known in hfa driver.
- Reset all the stats on autovoltage complete in cta driver.
- Use correct diff instead of diffbits in cta driver.
- Whitelist all firmwares <= 0.5 on hfa for software rolling of ntime.
- Avoid a memory leak by reusing the ntime field when rolling stratum work.
- Clear the pipe bitmap on cta only when no share has occurred for 2 hours
instead of 1.
- Cta share_hashes should be added, and we can base it on device wdiff instead
of pool work difficulty for more accurate hashrates.
- Since the device runtime is now reset, the Raw hashrate entry in the cta API
output is no longer meaningful.
- Look for autovoltage returning to zero on cta driver and reset stats at that
point since the hashrate is unreliable till then.
- ants1 - cgminerise applog calls
- Default to stratum+tcp:// on any urls that don't have a prefix instead of
http.
- Trivial cta style changes.
- ants1 - fix/enable temperature checking and remove unneeded temp_old
- ants1 - move local cgpu variables to info structure
- ants1 use a klist to store work and copied work
- Simplify dramatically the cross-process cgminer locking through use of flock
instead of sysv semaphores.
Major feature upgrades - main one being low overhead scaleable solo mining to bitcoind, bugfixes and driver improvements.
Human readable changelog:
- Low overhead ultra-scaleable solo mining to bitcoind. Quote from the documentation update:
Code:
Solo mining can be done efficiently as a single pool entry or a backup to
any other pooled mining and it is recommended everyone have solo mining set up
as their final backup in case all their other pools are DDoSed/down for the
security of the network. To enable solo mining, one must be running a local
bitcoind/bitcoin-qt or have one they have rpc access to. To do this, edit your
bitcoind configuration file (bitcoin.conf) with the following extra lines,
using your choice of username and password:
rpcuser=username
rpcpassword=password
Restart bitcoind, then start cgminer, pointing to the bitcoind and choose a
btc address with the following options, altering to suit their setup:
cgminer -o http://localhost:8332 -u username -p password --btc-address 15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ
Note that I have NOT had the pleasure of mining a real solo bitcoin block with this latest code, only on various test networks, so you must accept the risks associated with using it on the real network. It rigidly follows bitcoind rules for transaction processing, updating transactions every 60 seconds and checking for block changes every 0.5 seconds. Be aware this involved a great deal of work and I would not have completed it but for the fact it was partially sponsored. However it was something that was going to be needed at some stage as I think it's mandatory everyone can use solo as their final backup. If you do NOT specify a btc address, you WILL be mining solo for me instead.any other pooled mining and it is recommended everyone have solo mining set up
as their final backup in case all their other pools are DDoSed/down for the
security of the network. To enable solo mining, one must be running a local
bitcoind/bitcoin-qt or have one they have rpc access to. To do this, edit your
bitcoind configuration file (bitcoin.conf) with the following extra lines,
using your choice of username and password:
rpcuser=username
rpcpassword=password
Restart bitcoind, then start cgminer, pointing to the bitcoind and choose a
btc address with the following options, altering to suit their setup:
cgminer -o http://localhost:8332 -u username -p password --btc-address 15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ
- Massive improvements to mining efficiency when using pooled GBT mining.
- Stratum low level bugfixes that may have caused random corruption/crashes.
- Miner.php updates
- Drillbit updates
- Antminer S1 updates
- Fix for repeatedly trying to reset a usb device when it has failed.
- Fix for Icarus devices (such as antminer U1 or block erupters) being switched off and not restarting.
- More accurate hashrates on cointerra devices, with a more reliable bitmap of working cores and now a count such as:
Code:
Asic0Core0 120:fffefffefffefffefffefffefffefffe
- Per core cointerra hashrates- Fix for memory leak on hashfast devices.
- Fix for crashes on multiple failed inits on hashfast devices.
- Show what quadrant of a hashfast core has failed if possible
- Fix for hashfast API stats output being invalid json
- Hashfast api stats output names are unique making them more easily parseable
- Inputting URLs without a prefix (such as http:// or stratum+tcp://) will now assume stratum to speed up initial connections.
- On linux we no longer use sysv semaphores to prevent multiple instances of cgminer trying to use the same device, meaning you will no longer run out of semaphore resources or have failures to grab devices on restarting.
- Numerous other low level fixes and improvements.
Full changelog:
- Fix missing htobe16 on windows and meaningless >u32 string warning.
- Software ntime roll for all hashfast devices.
- Silence harmless warning.
- Drop a failed restart icarus device to allow it to be rehotplugged if
possible.
- Work with more than one transaction.
- Kill gbt solo pools that don't respond to the gbt request 5 times
sequentially.
- Fix ser_number for no remaining val byte.
- Create a work item and stage it when updating the gbt solo template to allow
new block detection and restart code to work.
- Test block hash as well as block height when solo mining to ensure we haven't
been mining on an orphan branch.
- Fix transaction processing for gbt solo.
- Encode height using integer varint format.
- Make new block detection message not show in gbt solo from test_work_current
- Add block detection via getblockcount polling in gbt solo and update gbt
template every 60 seconds.
- Iterate over transactions twice to malloc only once when copying all the
transaction data.
- Update solo coinbase regularly and submit as gbt work
- Only show merkle hashes for solo mining in debug mode.
- Set correct flag for solo work.
- Generate gbt solo work emulating stratum work construction.
- Set the diff as a double sdiff from gbt solo data.
- Move swork.diff out of the stratum work section to be shared as sdiff.
- Generate a header bin from gbt solo as per the cached stratum one.
- Store strings similar to stratum's when decoding gbt solo
- Avoid allocing and freeing stratum strings that should be fixed length.
- Run parser through detect_stratum after stratum+tcp:// is force added
- Remove unnecessary header length calculation for stratum header binary and
only binary convert the correct length of the header.
- Share more fields between stratum and gbt
- Share coinbase_len variable b/w stratum and gbt and setup more gbt solo
parameters.
- Generate a valid coinbase and set nonce2offset for gbt solo
- Move scriptsig header bin conversion to setup gbt solo
- Create our own custom scriptsig base.
- Add helper functions for creating script signature templates and beging
building template.
- Do gbt solo decoding under gbt lock.
- Add more gbt variable decoding from gbt solo information.
- Store all the transaction data in binary form when using GBT
- When setting up solo mining, check validity of bitcoin address against
bitcoind
- Make pooled GBT mining use merkle bin optimisations slated for solo mining.
- Abstract out the merkle bin calculation for gbt solo
- Implement efficient merkle tree base from solo GBT information.
- miner.php custom formatting and row counter '#'
- Drillbit: Fix for underestimating hash rate from Bitfury devices
- Send per-core hashrates at regular ~5min intervals back to cta devices.
- Calculate the cta per core hashrate at 5 minute intervals.
- Check the bits of the correct core in cta bit count.
- Display the bit count along with the bitmap for each cta core in the API stats
output.
- Store and display the per core hashrate on cta relative to each work restart.
- Decrease the time we wait for unsetting a core on the cta bitmap to correspond
with the lower max diff of 32.
- Set max diff on cointerra devices to 32 which is still only 11 shares per
second but allows for earlier confirmation of per core hashrates.
- Keep track of when the last restart and work updates were triggered and
provide helper functions for knowing the time since then.
- hashfast make api stats field names unique
- Fix gcc longjmp warning in api.c
- Add a per-core hashrate to the cta API stats.
- miner.php support edevs and estats
- API - put edevstatus where it was supposed to be
- Icarus - allow timing mode to work with ANU and not slow it down
- drillbit - remove warnings
- drillbit - minor code tidy up
- Drillbit: Change language around 'void' to warning about limiter disabled
- Drillbit: Fix accidental over-counting of HW errors
- Drillbit: --drillbit-auto parameter for tweakable custom tuning of ASIC speeds
- Drillbit: Output warning if board reports void warranty
- Drillbit: Add Avalon & drillbit-autotune notes to ASIC-README
- Drillbit: Limit work sent out to 8 units in a single pass, was DoSing a full
double scroll
- Drillbit: Move drillbit_empty_buffer calls to only when errors occur, were
limiting performance on Windows
- Fix Windows bug with libusb_reset_device returning SUCCESS for disconnected
device
- Drillbit: Fix some warnings
- Drillbit: Add --drillbit-autotune option for device to dynamically alter clock
speed
- Drillbit: Fix typo in previous commit
- Drillbit: Remove default config in cgminer, rely on defaults in firmware
- Drillbit: Combine split USB transfer for sending new work, reduce overhead
- Drillbit: Add support for protocol V4, with device-agnostic board
configuration data
- Drillbit driver: Add support for Avalon-based Drillbit miners
- API - add edevs and estats - to only show enabled devices
- Check device data exists on a hfa instance before trying to reinit it.
- Print off what quadrant regulator failed if known in hfa driver.
- Reset all the stats on autovoltage complete in cta driver.
- Use correct diff instead of diffbits in cta driver.
- Whitelist all firmwares <= 0.5 on hfa for software rolling of ntime.
- Avoid a memory leak by reusing the ntime field when rolling stratum work.
- Clear the pipe bitmap on cta only when no share has occurred for 2 hours
instead of 1.
- Cta share_hashes should be added, and we can base it on device wdiff instead
of pool work difficulty for more accurate hashrates.
- Since the device runtime is now reset, the Raw hashrate entry in the cta API
output is no longer meaningful.
- Look for autovoltage returning to zero on cta driver and reset stats at that
point since the hashrate is unreliable till then.
- ants1 - cgminerise applog calls
- Default to stratum+tcp:// on any urls that don't have a prefix instead of
http.
- Trivial cta style changes.
- ants1 - fix/enable temperature checking and remove unneeded temp_old
- ants1 - move local cgpu variables to info structure
- ants1 use a klist to store work and copied work
- Simplify dramatically the cross-process cgminer locking through use of flock
instead of sysv semaphores.
March 18, 2014, 06:15:15 AM
Good Day after longer running the new Cgminer i have Problems with the Antminer HW1.2!
greets and thanks for help
Yes it shouldn't disable like that. It should unplug it and allow it to be re-hotplugged. will fix. Code:
[U]SB device management [P]ool management [S]ettings [D]isplay options [Q]uit
0: ANU 0: | OFF /264.4Th/s | A: 8321 R: 50 HW: 454 WU: 7.0/m
1: ANU 1: | OFF /299.1Mh/s | A: 3601 R: 45 HW: 180 WU: 3.1/m
2: ANU 2: | 1.790G/264.4Th/s | A:24883 R:270 HW:1284 WU: 21.1/m
3: ANU 3: | 1.820G/264.4Th/s | A:26404 R:522 HW:1298 WU: 20.9/m
4: ANU 4: | 1.814G/1.804Gh/s | A:23617 R:417 HW:1327 WU: 21.0/m
5: ANU 5: | OFF /359.8Mh/s | A: 3952 R: 42 HW: 222 WU: 3.5/m
6: ANU 6: | OFF /264.4Th/s | A: 8182 R:178 HW: 467 WU: 7.2/m
--------------------------------------------------------------------------------------------------
[2014-03-16 23:52:33] ANU 1 failure, disabling!
[2014-03-17 00:31:46] ANU 5: Device failed to respond to restart
[2014-03-17 00:31:46] ANU 5 failure, disabling!
[2014-03-17 04:06:01] ANU 0: Device failed to respond to restart
[2014-03-17 04:06:01] ANU 0 failure, disabling!
[2014-03-17 04:06:03] ANU 6: Device failed to respond to restart
[2014-03-17 04:06:03] ANU 6 failure, disabling!
After a restart the Cgminer all runs good as before???0: ANU 0: | OFF /264.4Th/s | A: 8321 R: 50 HW: 454 WU: 7.0/m
1: ANU 1: | OFF /299.1Mh/s | A: 3601 R: 45 HW: 180 WU: 3.1/m
2: ANU 2: | 1.790G/264.4Th/s | A:24883 R:270 HW:1284 WU: 21.1/m
3: ANU 3: | 1.820G/264.4Th/s | A:26404 R:522 HW:1298 WU: 20.9/m
4: ANU 4: | 1.814G/1.804Gh/s | A:23617 R:417 HW:1327 WU: 21.0/m
5: ANU 5: | OFF /359.8Mh/s | A: 3952 R: 42 HW: 222 WU: 3.5/m
6: ANU 6: | OFF /264.4Th/s | A: 8182 R:178 HW: 467 WU: 7.2/m
--------------------------------------------------------------------------------------------------
[2014-03-16 23:52:33] ANU 1 failure, disabling!
[2014-03-17 00:31:46] ANU 5: Device failed to respond to restart
[2014-03-17 00:31:46] ANU 5 failure, disabling!
[2014-03-17 04:06:01] ANU 0: Device failed to respond to restart
[2014-03-17 04:06:01] ANU 0 failure, disabling!
[2014-03-17 04:06:03] ANU 6: Device failed to respond to restart
[2014-03-17 04:06:03] ANU 6 failure, disabling!
greets and thanks for help
March 17, 2014, 11:26:25 AM
The new CGMiner also support the new Antminer U2?
I mean yes, only the Heatsink is new?
regards
Try it and let us know I mean yes, only the Heatsink is new?
regards
We don't have any U2's but I think they are the same with just a better heat sink?
Running about 30 sticks of the U2 and --anu-freq 250 runs really well at 1.95 GH-2 GH, tried running it at 275 and HW error goes crazy.
March 17, 2014, 10:06:52 AM
Good Day after longer running the new Cgminer i have Problems with the Antminer HW1.2!
greets and thanks for help
Quote
SB device management [P]ool management ettings [D]isplay options [Q]uit
0: ANU 0: | OFF /264.4Th/s | A: 8321 R: 50 HW: 454 WU: 7.0/m
1: ANU 1: | OFF /299.1Mh/s | A: 3601 R: 45 HW: 180 WU: 3.1/m
2: ANU 2: | 1.790G/264.4Th/s | A:24883 R:270 HW:1284 WU: 21.1/m
3: ANU 3: | 1.820G/264.4Th/s | A:26404 R:522 HW:1298 WU: 20.9/m
4: ANU 4: | 1.814G/1.804Gh/s | A:23617 R:417 HW:1327 WU: 21.0/m
5: ANU 5: | OFF /359.8Mh/s | A: 3952 R: 42 HW: 222 WU: 3.5/m
6: ANU 6: | OFF /264.4Th/s | A: 8182 R:178 HW: 467 WU: 7.2/m
--------------------------------------------------------------------------------------------------
[2014-03-16 23:52:33] ANU 1 failure, disabling!
[2014-03-17 00:31:46] ANU 5: Device failed to respond to restart
[2014-03-17 00:31:46] ANU 5 failure, disabling!
[2014-03-17 04:06:01] ANU 0: Device failed to respond to restart
[2014-03-17 04:06:01] ANU 0 failure, disabling!
[2014-03-17 04:06:03] ANU 6: Device failed to respond to restart
[2014-03-17 04:06:03] ANU 6 failure, disabling!
After a restart the Cgminer all runs good as before???0: ANU 0: | OFF /264.4Th/s | A: 8321 R: 50 HW: 454 WU: 7.0/m
1: ANU 1: | OFF /299.1Mh/s | A: 3601 R: 45 HW: 180 WU: 3.1/m
2: ANU 2: | 1.790G/264.4Th/s | A:24883 R:270 HW:1284 WU: 21.1/m
3: ANU 3: | 1.820G/264.4Th/s | A:26404 R:522 HW:1298 WU: 20.9/m
4: ANU 4: | 1.814G/1.804Gh/s | A:23617 R:417 HW:1327 WU: 21.0/m
5: ANU 5: | OFF /359.8Mh/s | A: 3952 R: 42 HW: 222 WU: 3.5/m
6: ANU 6: | OFF /264.4Th/s | A: 8182 R:178 HW: 467 WU: 7.2/m
--------------------------------------------------------------------------------------------------
[2014-03-16 23:52:33] ANU 1 failure, disabling!
[2014-03-17 00:31:46] ANU 5: Device failed to respond to restart
[2014-03-17 00:31:46] ANU 5 failure, disabling!
[2014-03-17 04:06:01] ANU 0: Device failed to respond to restart
[2014-03-17 04:06:01] ANU 0 failure, disabling!
[2014-03-17 04:06:03] ANU 6: Device failed to respond to restart
[2014-03-17 04:06:03] ANU 6 failure, disabling!
greets and thanks for help
March 15, 2014, 04:30:11 PM
Well, I think I may have used an inaccurate phrase in "not quite stable".
It seems to run and doesn't crash. But it does turn off several erupters on both machines I use, erupters that run just fine on 3.8.4 and 3.11.0.
Any idea what the message is when they're turned off? Is it the not giving valid hashes for greater than X seconds one?It seems to run and doesn't crash. But it does turn off several erupters on both machines I use, erupters that run just fine on 3.8.4 and 3.11.0.
Don't know. I'll just notice that a green light is on and when I look they are just listed as off.
I'll fire up 4.1.0 again and see if I can catch it when it turns one off.
Thanks,
Sam
March 15, 2014, 04:09:22 PM
Well, I think I may have used an inaccurate phrase in "not quite stable".
It seems to run and doesn't crash. But it does turn off several erupters on both machines I use, erupters that run just fine on 3.8.4 and 3.11.0.
Any idea what the message is when they're turned off? Is it the not giving valid hashes for greater than X seconds one? It seems to run and doesn't crash. But it does turn off several erupters on both machines I use, erupters that run just fine on 3.8.4 and 3.11.0.
March 14, 2014, 03:19:04 PM
What is wrong with my config? Cgminer says Start cgminer with -T to see what failed to load but when I do that, I don't see any errors..
"gridseed-options": {
"scrypt": true,
"gridseed-options": {
"scrypt": true,
I'm using the cgminer with gridseed support, I have one main issue which is really annoying can you tell me if it's fixed and which version it's fixed on. The problem is that I have to unplug the USB for my gridseed before cgminer starts, once cgminer has started only then I can plug the USB in otherwise the cgminer just freezes or crashes. If I'm accessing the rig remotely and I need to restart the windows computer then I'm stuck as some one physically needs to be at the rig.
Official cgminer contains no gridseed support so you have to seek support from gridseed or whoever is maintaining the cgminer fork with gridseed support. March 14, 2014, 01:22:03 PM
"scrypt": true,
If you're running new bitcoin ASICS (Gridseed) then you shouldn't have this in there.
If you're actually trying to scrypt mine, watch out, this forum is meant for new cgminer development and troubleshooting. General troubleshooting of old cgminer versions should be asked elsewhere. There's nothing wrong with your config if you run with an older version of cgminer (<3.6 or something).
Yes running cgminer 3.72 and scrypt mining with gridseed 5-chip devices.
I should clarify that although there's nothing *wrong*, it wont work. You *cannot* use cgminer for script mining with a Gridseed. Script mining with a Gridseed device requires some voodoo that does not concern this forum thread. Good day.
March 14, 2014, 11:48:47 AM
"scrypt": true,
If you're running new bitcoin ASICS (Gridseed) then you shouldn't have this in there.
If you're actually trying to scrypt mine, watch out, this forum is meant for new cgminer development and troubleshooting. General troubleshooting of old cgminer versions should be asked elsewhere. There's nothing wrong with your config if you run with an older version of cgminer (<3.6 or something).
Yes running cgminer 3.72 and scrypt mining with gridseed 5-chip devices.
March 14, 2014, 10:54:01 AM
"scrypt": true,
If you're running new bitcoin ASICS (Gridseed) then you shouldn't have this in there.
If you're actually trying to scrypt mine, watch out, this forum is meant for new cgminer development and troubleshooting. General troubleshooting of old cgminer versions should be asked elsewhere. There's nothing wrong with your config if you run with an older version of cgminer (<3.6 or something).
March 14, 2014, 10:07:10 AM
What is wrong with my config? Cgminer says Start cgminer with -T to see what failed to load but when I do that, I don't see any errors..
{
"pools": [
{
"url": "stratum+tcp://ltc.ghash.io:3333",
"user": "worker.something",
"pass": "x"
},
{
"url": "stratum+tcp://ny.clevermining.com:3333",
"user": "worker.something",
"pass": "x"
}
],
"gridseed-options": {
"baud": "115200",
"freq": "850",
"chips": "5",
"modules": "1",
"usefifo": "0"
},
"api-listen": true,
"api-mcast-port": "4028",
"api-port": "4028",
"expiry": "120",
"hotplug": "5",
"log": "5",
"no-pool-disable": true,
"queue": "1",
"scan-time": "30",
"scrypt": true,
"shares": "0",
"kernel-path": "/usr/local/bin",
"api-allow": "W:127.0.0.1"
}
{
"pools": [
{
"url": "stratum+tcp://ltc.ghash.io:3333",
"user": "worker.something",
"pass": "x"
},
{
"url": "stratum+tcp://ny.clevermining.com:3333",
"user": "worker.something",
"pass": "x"
}
],
"gridseed-options": {
"baud": "115200",
"freq": "850",
"chips": "5",
"modules": "1",
"usefifo": "0"
},
"api-listen": true,
"api-mcast-port": "4028",
"api-port": "4028",
"expiry": "120",
"hotplug": "5",
"log": "5",
"no-pool-disable": true,
"queue": "1",
"scan-time": "30",
"scrypt": true,
"shares": "0",
"kernel-path": "/usr/local/bin",
"api-allow": "W:127.0.0.1"
}
March 13, 2014, 08:17:02 PM
Hello everyone!
This data will definitely help with tweaking your GridSeed 5 chip USB miner/s.
I just received this data from GRIDSEED via HASHRA.com today. 3-13-14
I'm paraphrasing for general clarity.
I've also added some of my own observations based on direct experience with my own GS5's.
GRIDSEED GS3355 5 Chip USB Miner - Flashing RED and GREEN LED's - What They Actually Mean.
All timings are either approximate or exact, if not darn close!
Your clock speed may vary slightly.
GREEN flashing LED means - 5V is ON / drive electronics are powered up.
GREEN LED is ON for 1 second, OFF for 1 second.
RED flashing LED - ON 3 seconds / OFF 3 seconds means - Miner Is Hashing /
Processing Data.
RED flashing LED - ON 60 to 70 seconds - OFF 60 to 70 seconds:
Miner is Not Hashing / Processing Data.
If Fan is OFF and RED LED IS STUCK ON or OFF i.e. not flashing:
12V is OFF - 5V is ON.
FAN is ON but no GREEN OR RED LED's are flashing ON or OFF, means:
12V ON - 5V OFF.
When first powering the miner on, the best sequence I have found is:
First, 12V ON
Second, 5V (USB POWER) ON
After 5V power is turned ON, after a few seconds, the GREEN LED's will start
to flash ON/OFF as written above.
After 12V power is turned ON, in about 60 to 70 seconds,
the RED LED's will start to sequence ON/OFF as written above.
Hope this helps!
Peace
Wolfey2014
LR6U7jB2Fb4pJYogbergqQHZgBRQ5UAqBG (LTC)
1G9uTT2YvygQXPMw4CaLWPJmg6asJBqM5f (BTC)
DMtMWd492Y4PrzZBA6fvkXywnGtgNcFdBd (DOGE)
This data will definitely help with tweaking your GridSeed 5 chip USB miner/s.
I just received this data from GRIDSEED via HASHRA.com today. 3-13-14
I'm paraphrasing for general clarity.
I've also added some of my own observations based on direct experience with my own GS5's.
GRIDSEED GS3355 5 Chip USB Miner - Flashing RED and GREEN LED's - What They Actually Mean.
All timings are either approximate or exact, if not darn close!
Your clock speed may vary slightly.
GREEN flashing LED means - 5V is ON / drive electronics are powered up.
GREEN LED is ON for 1 second, OFF for 1 second.
RED flashing LED - ON 3 seconds / OFF 3 seconds means - Miner Is Hashing /
Processing Data.
RED flashing LED - ON 60 to 70 seconds - OFF 60 to 70 seconds:
Miner is Not Hashing / Processing Data.
If Fan is OFF and RED LED IS STUCK ON or OFF i.e. not flashing:
12V is OFF - 5V is ON.
FAN is ON but no GREEN OR RED LED's are flashing ON or OFF, means:
12V ON - 5V OFF.
When first powering the miner on, the best sequence I have found is:
First, 12V ON
Second, 5V (USB POWER) ON
After 5V power is turned ON, after a few seconds, the GREEN LED's will start
to flash ON/OFF as written above.
After 12V power is turned ON, in about 60 to 70 seconds,
the RED LED's will start to sequence ON/OFF as written above.
Hope this helps!
Peace
Wolfey2014
LR6U7jB2Fb4pJYogbergqQHZgBRQ5UAqBG (LTC)
1G9uTT2YvygQXPMw4CaLWPJmg6asJBqM5f (BTC)
DMtMWd492Y4PrzZBA6fvkXywnGtgNcFdBd (DOGE)
March 13, 2014, 05:34:25 PM
...
A bit off topic, but have you or con played with the new 14.04 LTS (beta) release yet? I've had it on one of my laptops for a week or so & it seems to run sweet. Was wondering if you guys have looked at it yet & if cgminer will work with it "as is".
Thanks & Peace.
Not gone near 14.04 yet.A bit off topic, but have you or con played with the new 14.04 LTS (beta) release yet? I've had it on one of my laptops for a week or so & it seems to run sweet. Was wondering if you guys have looked at it yet & if cgminer will work with it "as is".
Thanks & Peace.
I tried 13.10 on a new i7 4771 the other week and it wouldn't boot fully
(Been sitting idle for 2 weeks now)
Maybe I'll have to try that then to get it working ...
March 13, 2014, 03:56:07 PM
In CGMiner, you can disable output by pressing [d] (display), then s (silent) ... but how to you re-enable output? After switching to silent mode I can't seem to get back into the display options. Just wondering how its possible without having to quit and restart the software.
You cannot, it's a permanent shutdown of the display. March 13, 2014, 12:05:13 PM
In CGMiner, you can disable output by pressing [d] (display), then s (silent) ... but how to you re-enable output? After switching to silent mode I can't seem to get back into the display options. Just wondering how its possible without having to quit and restart the software.
March 13, 2014, 03:02:54 AM
I'm using the cgminer with gridseed support, I have one main issue which is really annoying can you tell me if it's fixed and which version it's fixed on. The problem is that I have to unplug the USB for my gridseed before cgminer starts, once cgminer has started only then I can plug the USB in otherwise the cgminer just freezes or crashes. If I'm accessing the rig remotely and I need to restart the windows computer then I'm stuck as some one physically needs to be at the rig.
Thank you guys
Official cgminer contains no gridseed support so you have to seek support from gridseed or whoever is maintaining the cgminer fork with gridseed support. Thank you guys
Jump to: