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

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: BlackPrapor on July 31, 2012, 05:25:14 AM

Here are the results I've got for both miners running around 45k shares across 3 longpolls both:

Unfortunately this is ONLY over 2 longpolls as can be seen by NB being 3, but that's enough to tell there's a difference. The more longpolls, the greater the difference.

Summary:
Jesusminer
Hashrate 51.8GH (51.4U recognised)
Rejects: 85
U: 718.3

cgminer
Hashrate 51.8GH
Rejects: 30
U:719.5

PLONK
FUD DEBUNKED

The fact is that cgminer discards half a work item on average across longpolls with BFL, and it does NOT count that half a work item artificially. So the reject rate is lower by not working on useless work and then submitting it. But the REAL KICKER is that it also does half a useful work item MORE at the same time which is why the utility was actually higher on cgminer.

Now once again, luke-jr fuck off with your fud and seriously stay the fuck out of my thread with your horseshit.

BlackPrapor

hero member

Activity: 628

Merit: 504

Here are the results I've got for both miners running around 45k shares across 3 longpolls both:

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: BlackPrapor on July 31, 2012, 03:52:54 AM

Quote from: Luke-Jr on July 31, 2012, 03:37:40 AM

Quote from: BlackPrapor on July 30, 2012, 11:13:04 PM

I've got mini rigs hanging after some time with cgminer 2.6.1 so I switched back to bfgminer 2.5.1. It does produce almost 1% more rejects (cgminer had almost none 0.07%), but at least it works Roll Eyes

.

No, CGMiner has them - it just hides them from you, along with other shares that would have been accepted...

So, you're saying that I should see a difference in U or shares accepted between cgminer and bfgminer? I'll check it. Atm I'm having 51.7Ghs very stable speed with cgminer 2.6.1b. Do you mind telling me how to update bfgminer from 2.5.1, so I can make a fair comparison of both up to date miners?

His 2.5.1 should be enough to tell...

BlackPrapor

hero member

Activity: 628

Merit: 504

Quote from: Luke-Jr on July 31, 2012, 03:37:40 AM

Quote from: BlackPrapor on July 30, 2012, 11:13:04 PM

I've got mini rigs hanging after some time with cgminer 2.6.1 so I switched back to bfgminer 2.5.1. It does produce almost 1% more rejects (cgminer had almost none 0.07%), but at least it works Roll Eyes

.

No, CGMiner has them - it just hides them from you, along with other shares that would have been accepted...

So, you're saying that I should see a difference in U or shares accepted between cgminer and bfgminer? I'll check it. Atm I'm having 51.7Ghs very stable speed with cgminer 2.6.1b. Do you mind telling me how to update bfgminer from 2.5.1, so I can make a fair comparison of both up to date miners?

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: BlackPrapor on July 30, 2012, 11:13:04 PM

I've got mini rigs hanging after some time with cgminer 2.6.1 so I switched back to bfgminer 2.5.1. It does produce almost 1% more rejects (cgminer had almost none 0.07%), but at least it works Roll Eyes

.

No, CGMiner has them - it just hides them from you, along with other shares that would have been accepted...

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Anyone who got 2.6.1a from my git downloads - I've made a 2.6.1b that has the problematic BFL commit removed
(and deleted 2.6.1a)

https://github.com/kanoi/cgminer/downloads

cgminer-2.6.1b — cgminer-2.6.1b = Distro cgminer 2.6.1 executable file compiled on Xubuntu 11.04 with all device + scrypt support included - and the BFL bug removed

Edit: FYI 2.6.1a didn't ever fail on my BFL (25.5 hours) - which is rather odd considering the problems with my BFL

Anyway, I'm running 2.6.1b on all my 3 setups.

BlackPrapor

hero member

Activity: 628

Merit: 504

Quote from: -ck on July 30, 2012, 11:29:17 PM

Quote from: BlackPrapor on July 30, 2012, 11:13:04 PM

I've got mini rigs hanging after some time with cgminer 2.6.1 so I switched back to bfgminer 2.5.1. It does produce almost 1% more rejects, but at least it works Roll Eyes

. Since my computer is running on Linux and I'm a noob in linux, please don't ask me to send you debug files or anything like that Grin

. I didn't have "bitforce:" line for every device btw, if that helps.

Um, why bfgminer 2.5.1 and not cgminer 2.5.0?

EDIT: never mind that question, I suspect people actually believe luke-jr's FUD.

I think the minirig is probably burnt by the same thing affecting the singles.

Well, I had 2.5.1 installed, so I run that one. Don't know how to update, and I guess since you guys share the code, I would've got the same issue with bfgminer 2.6.1. Maybe its a good thing I still have 2.5.1 Grin

...but I do need to learn how to use linux

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: BlackPrapor on July 30, 2012, 11:13:04 PM

I've got mini rigs hanging after some time with cgminer 2.6.1 so I switched back to bfgminer 2.5.1. It does produce almost 1% more rejects, but at least it works Roll Eyes

. Since my computer is running on Linux and I'm a noob in linux, please don't ask me to send you debug files or anything like that Grin

. I didn't have "bitforce:" line for every device btw, if that helps.

Um, why bfgminer 2.5.1 and not cgminer 2.5.0?

EDIT: never mind that question, I suspect people actually believe luke-jr's FUD.

I think the minirig is probably burnt by the same thing affecting the singles.

BlackPrapor

hero member

Activity: 628

Merit: 504

I've got mini rigs hanging after some time with cgminer 2.6.1 so I switched back to bfgminer 2.5.1. It does produce almost 1% more rejects (cgminer had almost none 0.07%), but at least it works Roll Eyes

. Since my computer is running on Linux and I'm a noob in linux, please don't ask me to send you debug files or anything like that Grin

. I didn't have "bitforce:" line for every device btw, if that helps.

farfie

newbie

Activity: 63

Merit: 0

Quote from: -ck on July 30, 2012, 10:02:33 PM

Quote from: farfie on July 30, 2012, 09:55:36 PM

Quote from: kano on July 30, 2012, 06:44:16 PM

What are you running on?

There seems to be an ongoing bug fix on bug fix on bug fix for this at the moment (nothing to do with me)

The first bugfix pshep did was mostly to remove the 2 lines of luke-jr's commit
(which has gone in the chain of bug fixes and not returned)

I might be able to make a version that just removes that commit and compile it for you until the mess is sorted out by the others.
If it's windows - then yep that's OK also I can make one of them.

Let me know.

It is indeed Windows 7 x64.

Here try this executable with that one change backed out:
http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe

Half an hour so far with no problems on either machine. Going to bed soon, so I'll just lettem do their thing and report in the morning.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: farfie on July 30, 2012, 09:55:36 PM

Quote from: kano on July 30, 2012, 06:44:16 PM

What are you running on?

There seems to be an ongoing bug fix on bug fix on bug fix for this at the moment (nothing to do with me)

The first bugfix pshep did was mostly to remove the 2 lines of luke-jr's commit
(which has gone in the chain of bug fixes and not returned)

I might be able to make a version that just removes that commit and compile it for you until the mess is sorted out by the others.
If it's windows - then yep that's OK also I can make one of them.

Let me know.

It is indeed Windows 7 x64.

Here try this executable with that one change backed out:
http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe

farfie

newbie

Activity: 63

Merit: 0

Quote from: kano on July 30, 2012, 06:44:16 PM

What are you running on?

There seems to be an ongoing bug fix on bug fix on bug fix for this at the moment (nothing to do with me)

The first bugfix pshep did was mostly to remove the 2 lines of luke-jr's commit
(which has gone in the chain of bug fixes and not returned)

I might be able to make a version that just removes that commit and compile it for you until the mess is sorted out by the others.
If it's windows - then yep that's OK also I can make one of them.

Let me know.

It is indeed Windows 7 x64.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: os2sam on July 30, 2012, 06:39:10 AM

Does 2.60 not leak shares to backup pools anymore?
Sam

It does, but likely less than before.

ShadesOfMarble

donator

Activity: 543

Merit: 500

I'll turn debug on the next time this problem happens, thanks for the hint.

I'm using Windows 7 32-bit SP1. (Don't moan because of windows, my rigs are usually running for months witout interruption...)

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: ShadesOfMarble on July 30, 2012, 06:46:33 PM

I had to restart cgminer 2.6.1 on two different rigs because the API did no longer respond to any request (it did not even time out!?)
Mining was still working and this has never happened with earlier versions.

Anyone experienced the same problem?

The API reports all incoming requests and out going replies when debug is turned on -D
(of course turning on debug produces a whole heap of other stuff)
What OS? (and version)

Edit: of course you can turn on debug from the cgminer screen at any time ... i.e. when the problem occurs

ShadesOfMarble

donator

Activity: 543

Merit: 500

I had to restart cgminer 2.6.1 on two different rigs because the API did no longer respond to any request (it did not even time out!?)
Mining was still working and this has never happened with earlier versions.

Anyone experienced the same problem?

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: farfie on July 30, 2012, 05:36:00 PM

Quote from: kano on July 30, 2012, 04:50:52 PM

Does the problem occur during throttling?

Do you always specify "bitforce:" on the front of the serial device specification?

One change that I added (that's in 2.6.0 and 2.6.1) is there is now a timeout in BFL if you specify "bitforce:"
(there was always a timeout for BFL if you didn't specify "bitforce:" so I changed it work the same way in both situations)

Thus in the log there should be a message saying there was a timeout at the time the problem occurred if that is the cause of it.
(BFL needs to be able to timeout rather than hang if something goes wrong on linux - it used to hang sometimes when there were comm errors)
However, I guess it could be LP related when it tries to abort work that could be during a throttle?
If you can get it to fail either see if there is a timeout message (and post a pastebin of the log for up to 1 minute before it happens) or if there is no timeout message, run it in "-D" debug mode and post a pastebin of the last minute or so of that log up to when it fails
Or course, visiting FreeNode IRC #cgminer will be easier ...

My testing of this is on my BFL that has hardware issues lately so I put the fastest bitstream on it and thus was expecting to see any possible problems

But if it is during an LP then that's not easy to make happen ...

Edit: oh there was also another change that luke-jr did at the same time (I didn't notice) - so I guess it could be either of our changes.
https://github.com/ckolivas/cgminer/commit/cf36331d815e7b87131d547b92b9ceaa218d114d

My devices aren't throttling, and yes I always specify "bitforce:". I also don't believe the problem would be related to a long poll, since both machines would have received long polls near the same time, but one started having singles stop hashing much sooner than the other. I think that makes sense anyway, I'm no expert.

What are you running on?

There seems to be an ongoing bug fix on bug fix on bug fix for this at the moment (nothing to do with me)

The first bugfix pshep did was mostly to remove the 2 lines of luke-jr's commit
(which has gone in the chain of bug fixes and not returned)

I might be able to make a version that just removes that commit and compile it for you until the mess is sorted out by the others.
If it's windows - then yep that's OK also I can make one of them.

Let me know.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: -ck on July 30, 2012, 06:04:48 PM

Quote from: kano on July 30, 2012, 05:18:17 PM

Quote from: Luke-Jr on July 30, 2012, 05:03:30 PM

FWIW, any BFGMiner issues (including bugs in the FPGA drivers, that CGMiner copied from BFGMiner) should be reported in detail here.
I'm also available in #Eligius for real-time troubleshooting.

Hmm - well the actual correct term is a pull request you sent to cgminer ... but anyway ...

That's fine, I can't see what luke-jr says anyway since ignoring him unless someone else quotes him and only allow him to speak to me in c code. Since he still seems to have the same attitude and spams my thread, I can just ignore his code as well. Rather than showing humility it seems he is getting worse, so perhaps it's time to refuse to take any more code.

And so Con's fork deviates yet even further... guess that means he'll be rejecting the bitforce bugfix.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: kano on July 30, 2012, 05:18:17 PM

Quote from: Luke-Jr on July 30, 2012, 05:03:30 PM

FWIW, any BFGMiner issues (including bugs in the FPGA drivers, that CGMiner copied from BFGMiner) should be reported in detail here.
I'm also available in #Eligius for real-time troubleshooting.

Hmm - well the actual correct term is a pull request you sent to cgminer ... but anyway ...

That's fine, I can't see what luke-jr says anyway since ignoring him unless someone else quotes him and only allow him to speak to me in c code. Since he still seems to have the same attitude and spams my thread, I can just ignore his code as well. Rather than showing humility it seems he is getting worse, so perhaps it's time to refuse to take any more code.

farfie

newbie

Activity: 63

Merit: 0

Quote from: kano on July 30, 2012, 04:50:52 PM

Does the problem occur during throttling?

Do you always specify "bitforce:" on the front of the serial device specification?

One change that I added (that's in 2.6.0 and 2.6.1) is there is now a timeout in BFL if you specify "bitforce:"
(there was always a timeout for BFL if you didn't specify "bitforce:" so I changed it work the same way in both situations)

Thus in the log there should be a message saying there was a timeout at the time the problem occurred if that is the cause of it.
(BFL needs to be able to timeout rather than hang if something goes wrong on linux - it used to hang sometimes when there were comm errors)
However, I guess it could be LP related when it tries to abort work that could be during a throttle?
If you can get it to fail either see if there is a timeout message (and post a pastebin of the log for up to 1 minute before it happens) or if there is no timeout message, run it in "-D" debug mode and post a pastebin of the last minute or so of that log up to when it fails
Or course, visiting FreeNode IRC #cgminer will be easier ...

My testing of this is on my BFL that has hardware issues lately so I put the fastest bitstream on it and thus was expecting to see any possible problems

But if it is during an LP then that's not easy to make happen ...

Edit: oh there was also another change that luke-jr did at the same time (I didn't notice) - so I guess it could be either of our changes.
https://github.com/ckolivas/cgminer/commit/cf36331d815e7b87131d547b92b9ceaa218d114d

My devices aren't throttling, and yes I always specify "bitforce:". I also don't believe the problem would be related to a long poll, since both machines would have received long polls near the same time, but one started having singles stop hashing much sooner than the other. I think that makes sense anyway, I'm no expert.

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