OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[everest556]

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

[1675868288]

1675868288

[1675868288]

1675868288

[1675868288]

1675868288

[1675868288]

1675868288

[1675868288]

1675868288

[-ck]

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.

[KNK]

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]

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.

[JPoet]

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

[crazyates]

Three weeks ago I used cgminer to mine Zetacoins

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

We don't care about anything but bitcoin.

[KNK]

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

[Michael_KMS]

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!

[-ck]

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]

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.

[kano]

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

[KNK]

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

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.

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

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

Seems to be the same here thanks

[thrym]

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 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.

[-ck]

Currently I use version 4.1.0

Anyone got an Idea what to check next?

This.

[JPoet]

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]

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.

[thrym]

Currently I use version 4.1.0

Anyone got an Idea what to check next?

This.

stupid me.

Upgraded the little bugger to 4.2.3, will report results.

[thrym]

stupid me.

Upgraded the little bugger to 4.2.3, will report results.

AAAnd we have a Winner!

Thank you very much!

Code:

[2014-04-10 16:19:16] ANU 4: Device failed to respond to restart
[2014-04-10 16:19:16] ANU 4 failure, disabling!
[2014-04-10 16:19:21] Hotplug: Icarus added ANU 9

[GigaWave]

Kano, would like to know if you have any input on this issue of pool hash rate  being only %1 of cgminer hash rate. Providing links below to 'posts' as the text is on the larger side.

https://bitcointalk.org/index.php?topic=514758.msg6159291#msg6159291
https://bitcointalk.org/index.php?topic=441465.msg6159311#msg6159311

[-ck]

Kano, would like to know if you have any input on this issue of pool hash rate  being only %1 of cgminer hash rate. Providing links below to 'posts' as the text is on the larger side.

https://bitcointalk.org/index.php?topic=514758.msg6159291#msg6159291
https://bitcointalk.org/index.php?topic=441465.msg6159311#msg6159311

This is their custom fork of cgminer + driver. They do not have proper diff checking in their code. That's the sort of thing you get with a poorly done custom driver by a manufacturer. Tell them to fix their driver. In the interim try to use a pool that allows you to use a fixed diff that matches whatever the device is set to.