OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 102.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: JPoet on April 10, 2014, 09:05:54 AM

Hello, I apologize of I did this wrong, I am new and have tried to mine bitcoins solo, to see it work.

Three weeks ago I used cgminer to mine bitcoins using "cgminer.exe -o http://127.0.0.1:xxxx -u xxx -p xxxx". Everything worked ok I got the messages as per the cgminer output.

A week later I went back to bitcoin after a break pool mining bitcoins.

Now I get an error "bit coin address is invalid 15qSxp..." seems to be the default address for a mandatory field.

So now I am getting back blockchain size and diff but am not mining. I no longer see the messages" accepted ccccc from anu0". For example.

So I set btc-address to the address in my bitcoin wallet from the receive menu. I do not understand the instruction to set it to bitcoind.

So now I can't solo mine, can anybody help? Thanks

Basically what btc-address do I use as the default no longer seems to work.

Just pick any valid btc address that you own. It does not even matter if the wallet that contains that address isn't on the bitcoind you are mining to.

JPoet

newbie

Activity: 59

Merit: 0

Hello, I apologize of I did this wrong, I am new and have tried to mine bitcoins solo, to see it work.

Three weeks ago I used cgminer to mine bitcoins using "cgminer.exe -o http://127.0.0.1:xxxx -u xxx -p xxxx". Everything worked ok I got the messages as per the cgminer output.

A week later I went back to bitcoin after a break pool mining bitcoins.

Now I get an error "bit coin address is invalid 15qSxp..." seems to be the default address for a mandatory field.

So now I am getting back blockchain size and diff but am not mining. I no longer see the messages" accepted ccccc from anu0". For example.

So I set btc-address to the address in my bitcoin wallet from the receive menu. I do not understand the instruction to set it to bitcoind.

So now I can't solo mine, can anybody help? Thanks

Basically what btc-address do I use as the default no longer seems to work.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: thrym on April 10, 2014, 07:41:17 AM

Currently I use version 4.1.0

Anyone got an Idea what to check next?

This.

thrym

newbie

Activity: 3

Merit: 0

Hi all, and hi ckolivas - thank you for your excellent work.

I have been using cgminer for a while on my raspberry pi with 8 Antminers U1 and U2 mixed.

There is no big Problem, especially at startup everything works fine - but after a while (5min-1Hour) I get this:

Code:

[2014-04-10 10:16:01] ANU 8: No valid hashes for over 53 secs, attempting to reset
[2014-04-10 10:16:01] ANU 8 attempted reset got err:(0) LIBUSB_SUCCESS
[2014-04-10 10:17:23] ANU 8: No valid hashes for over 53 secs, attempting to reset
[2014-04-10 10:17:24] ANU 8 attempted reset got err:(0) LIBUSB_SUCCESS
[2014-04-10 10:18:24] ANU 8: Device failed to respond to restart
[2014-04-10 10:18:24] ANU 8 failure, disabling!

The device is then listed as OFF.

Interrestingly enough, when I press U + U + 8 (in this case it was Cool

it redetects the miner without problem and hashes away happily for the next 1-10 hours.

I suspected the power supply on my USB-Hubs, but no matter wich one or how many (I have 3 hubs with 3.5Amp supply per hub) I use, I keep running into that error. Currently I use version 4.1.0

Anyone got an Idea what to check next?

Also @ckolivas, is it possible to automize the USB-Unplug for disbled devices somehow?

Thanks in advance for any replies.

KNK

hero member

Activity: 692

Merit: 502

Quote from: kano on April 10, 2014, 06:32:38 AM

Unless you invalidate the work when it finds one nonce (which of course you can't since it can find multiple nonces) then of course a duplicate share is possible if the driver or device can return duplicate nonces.

In my driver i know when the chip has switched to the next job and then I call work_completed for the old one ... i don't see how the same job could be processed again

Quote

Quite normal for Bitfury chips since it is hard to ensure you don't lose work without getting lots of HW errors

Not exactly ... when the chip switches to the new job - the next nonces will never be from the old one, so it's safe to drop it and not loose nonces.

Quote

The only way, in this case, to avoid duplicate shares, would be to keep a history of valid nonces per work item and don't submit the duplicates.

Duplicates should not happen (in my driver logic) except when the chip has started working on the same job, because it was asked to ... then again i don't see how that could happen except if i missed a whole work and the job was switched twice
... hmm this may happen when there are few bad reads caused by hardware problems, which may well be my case, as there are some bad chips in the chain

Quote

Heh funny how while explaining something (as is common) you can see something you missed before

Seems to be the same here thanks Wink

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: KNK on April 10, 2014, 03:32:49 AM

Quote from: -ck on April 09, 2014, 05:34:20 PM

Is this in your own code because that doesn't look familiar. It doesn't look like you're actually removing the work item from the hash list before unlocking the write lock, you're only finding it so the work remains on the hash list.

Yes, this in my own code and I am not removing the work (by design), just mark it as started (tv_work_start) and send it to the chip, by keeping a pointer to it inside the chip data structure. Later on when chip is done with the job, I call work_completed() under the same private lock and request a new work.
This approach allows to avoid keeping another list, but just a pointer to the queue.
My plan is to set subid to the chip number which will work on it, so i can detect if the job is somehow sent to another chip ... it seems to be safe to have duplicate subid, as it is not used anywhere except from the driver

Unless you invalidate the work when it finds one nonce (which of course you can't since it can find multiple nonces) then of course a duplicate share is possible if the driver or device can return duplicate nonces.

Quite normal for Bitfury chips since it is hard to ensure you don't lose work without getting lots of HW errors ... why my BaB driver has such a good error rate, but on occasion I get duplicate shares.
The only way, in this case, to avoid duplicate shares, would be to keep a history of valid nonces per work item and don't submit the duplicates.
Hmm yeah I can add that to the BaB driver easily enough!
Heh funny how while explaining something (as is common) you can see something you missed before Cheesy

Michael_KMS

newbie

Activity: 4

Merit: 0

Quote from: -ck on April 10, 2014, 04:12:04 AM

Quote from: Michael_KMS on April 10, 2014, 04:10:01 AM

Hi, I just compiled cgminer 4.2.3 on Linux Mint with the additional technobit drivers. After starting cgminer I cant see the status window, also i cant interact with cgminer via the console. Same problem with cgminer 3.12.3. Raspberry Pi works great...

can someone help me?

thanks in advance!

Well, you're asking for help with something you patched that isn't our code... However your problem is the classic one of not installing the libncurses development library prior to building it.

And I really appreciate your help! Thanks a lot.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: Michael_KMS on April 10, 2014, 04:10:01 AM

Hi, I just compiled cgminer 4.2.3 on Linux Mint with the additional technobit drivers. After starting cgminer I cant see the status window, also i cant interact with cgminer via the console. Same problem with cgminer 3.12.3. Raspberry Pi works great...

can someone help me?

thanks in advance!

Well, you're asking for help with something you patched that isn't our code... However your problem is the classic one of not installing the libncurses development library prior to building it.

Michael_KMS

newbie

Activity: 4

Merit: 0

Hi, I just compiled cgminer 4.2.3 on Linux Mint with the additional technobit drivers. After starting cgminer I cant see the status window, also i cant interact with cgminer via the console. Same problem with cgminer 3.12.3. Raspberry Pi works great...

can someone help me?

thanks in advance!

KNK

hero member

Activity: 692

Merit: 502

Quote from: -ck on April 09, 2014, 05:34:20 PM

Is this in your own code because that doesn't look familiar. It doesn't look like you're actually removing the work item from the hash list before unlocking the write lock, you're only finding it so the work remains on the hash list.

Yes, this in my own code and I am not removing the work (by design), just mark it as started (tv_work_start) and send it to the chip, by keeping a pointer to it inside the chip data structure. Later on when chip is done with the job, I call work_completed() under the same private lock and request a new work.
This approach allows to avoid keeping another list, but just a pointer to the queue.
My plan is to set subid to the chip number which will work on it, so i can detect if the job is somehow sent to another chip ... it seems to be safe to have duplicate subid, as it is not used anywhere except from the driver

crazyates

legendary

Activity: 952

Merit: 1000

Quote from: JPoet on April 09, 2014, 08:51:59 PM

Three weeks ago I used cgminer to mine Zetacoins

I understand it was one page back, so I'll quote it for you:

Quote from: -ck on April 06, 2014, 04:26:25 AM

We don't care about anything but bitcoin.

JPoet

newbie

Activity: 59

Merit: 0

Hello,

Three weeks ago I used cgminer to mine Zetacoins using "cgminer.exe -o http://127.0.0.1:17335 -u xxx -p xxxx". Everything worked ok I mined over 60 Zetacoins.

A week later I went back to Zetacoin after a break pool mining bitcoins.

Now I get an error "bit coin address is invalid 15qSxp..." seems to be the default address for a mandatory field.

So now I am getting back blockchain size and diff but am not mining.

So I set btc-address to the address in my Zetacoin wallet from the receive menu. I do not understand the instruction to set it to bitcoind.

So now I can't solo mine, can anybody help? Thanks

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: KNK on April 09, 2014, 03:22:58 PM

I am having a problem with rejected duplicate shares, which is weird, because there is no way that could happen:

Code:

wr_lock(&cgpu->qlock);
HASH_ITER(hh, cgpu->queued_work, work, tmp) {
if ( !work->stale && !(work->tv_work_start.tv_sec) ) {
	cgtime(&work->tv_work_start);
	wr_unlock(&cgpu->qlock);
	return work;
}

1. Iteration is inside a wr_lock
2. Once accepted the work is marked as used/started again inside the lock
3. The whole function is called inside a thread private lock and no other thread is calling that function at all
4. Adding a job to the queue is also done under the same private lock

but still there are duplicates returned from different chips (if the same chip that may be just delayed chip scanning and work reuse), which points to the same work being returned in two consecutive calls or sending a work to the wrong chip.

Any pointers how to debug this?
Is the (struct work) job_id unique enough to identify that or subid (any driver as example?) should be used instead?

Is this in your own code because that doesn't look familiar. It doesn't look like you're actually removing the work item from the hash list before unlocking the write lock, you're only finding it so the work remains on the hash list.

KNK

hero member

Activity: 692

Merit: 502

I am having a problem with rejected duplicate shares, which is weird, because there is no way that could happen:

Code:

wr_lock(&cgpu->qlock);
HASH_ITER(hh, cgpu->queued_work, work, tmp) {
if ( !work->stale && !(work->tv_work_start.tv_sec) ) {
	cgtime(&work->tv_work_start);
	wr_unlock(&cgpu->qlock);
	return work;
}

1. Iteration is inside a wr_lock
2. Once accepted the work is marked as used/started again inside the lock
3. The whole function is called inside a thread private lock and no other thread is calling that function at all
4. Adding a job to the queue is also done under the same private lock

but still there are duplicates returned from different chips (if the same chip that may be just delayed chip scanning and work reuse), which points to the same work being returned in two consecutive calls or sending a work to the wrong chip.

Any pointers how to debug this?
Is the (struct work) job_id unique enough to identify that or subid (any driver as example?) should be used instead?

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: everest556 on April 08, 2014, 07:24:09 PM

I think that's a patch from the official Technobit site, not a third-party patch:
http://technobit.eu/index.php?controller=attachment&id_attachment=23

Sure but they've not tried submitting it for inclusion. You seem to be missing how the process works despite me describing it a few times.

everest556

newbie

Activity: 38

Merit: 0

I think that's a patch from the official Technobit site, not a third-party patch:
http://technobit.eu/index.php?controller=attachment&id_attachment=23

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: everest556 on April 08, 2014, 05:55:46 PM

Quote from: -ck on April 07, 2014, 06:55:54 PM

Quote from: everest556 on April 07, 2014, 05:46:20 PM

Any chance there'll be support for Technobit's HEX16A2 boards?

If they submit their code in a way consistent with other driver submissions, or provide one of us devs hardware to help massage the code to get into mainline cgminer then sure.

There is a patch for these boards: https://bitcointalksearch.org/topic/cgminer-patch-fur-hex16a2-355031
Is it possible to integrate it into the main code?

No, we do not go out of our way to scrounge up patches from elsewhere and make them work in the master cgminer code. I already described the process above.

everest556

newbie

Activity: 38

Merit: 0

Quote from: -ck on April 07, 2014, 06:55:54 PM

Quote from: everest556 on April 07, 2014, 05:46:20 PM

Any chance there'll be support for Technobit's HEX16A2 boards?

If they submit their code in a way consistent with other driver submissions, or provide one of us devs hardware to help massage the code to get into mainline cgminer then sure.

There is a patch for these boards: https://bitcointalksearch.org/topic/cgminer-patch-fur-hex16a2-355031
Is it possible to integrate it into the main code?

oskuro

sr. member

Activity: 294

Merit: 251

Quote from: Zich on April 05, 2014, 12:16:43 AM

Quote from: jomant on April 05, 2014, 12:08:38 AM

Are those steps apply for the Raspberry pi as well. I was looking for a detailed Installation instruction like this a page before and ended up with backing up my previews version 1.8 or so. I am mining on 2GH/s with a Antminer U2 with a 14% error rate.

Yes

The different is you don't need sudo while compile cgminer & add --enable-icarus

Code:

1. git clone https://github.com/ckolivas/cgminer.git
2. mv cgminer cgminer-4.2.3
3. cd cgminer-4.2.3
4. ./autogen.sh --enable-ants1 --enable-avalon --enable-bitfury --enable-icarus
5. make

Hi guys.

I have a raspberry pi with a rosewill hub with 2 antminers U2.

I installed minepeon last version for raspberry pi and im mining with default bfgminer. Im getting default 1.95GH/s per miner.

I would like to know if its best to use cgminer instead of default bfgminer, and what are the steps to install it, and then run it.

That quote will work for me? thanks

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: everest556 on April 07, 2014, 05:46:20 PM

Any chance there'll be support for Technobit's HEX16A2 boards?

If they submit their code in a way consistent with other driver submissions, or provide one of us devs hardware to help massage the code to get into mainline cgminer then sure.

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