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

[kano]

I am using minepeon (cgminer3.6.4) with a Jalapeno and observing that DAcc (Difficulty Accepted) is 60-85% when mining with the eligius pool and 100-105% when mining with BTCguild. (both pools had min difficulty set to auto, but even when I changed BTCguild to 8+GH/s, the difference in percentage roughly stayed the same)
Can someone elaborate a bit on the Dacc calculation and the difference I am observing between the two pools, does it affect my share contribution accordingly???
I checked github, but I was a bit lost. I also asked at the minepeon forum but the dev just parsed the DAcc value and could not elaborate on the calculation method.

Thank you in advance

Have I asked in the wrong thread? :-)
Please advise if so...

DA is the value in 1diff of all shares accepted.
If you submit 10 50diff shares and all are accepted then DA would be 500

I've no idea what you mean those % numbers are.

[1714165217]

1714165217

[1714165217]

1714165217

[-ck]

Can you try fff again and this time when it gets into the loop of errors, enable debug in the display menu and continue logging for a bit please?

OK, done.  Aside: The previous overnight run of 3.5.1 went for 14 hours, no faults.

Started cgminer-fff again.  After about 3 hours I got several LEDs full on for a few seconds. Two of them went out and resumed mining but the 3rd appeared in the display as a zombie.  I was sitting next to the PC at the time, so turned on debug straight away.  I left it running for a further 5 minutes then stopped it.

Logfile here, but I suspect it's not going to help:
  https://dl.dropboxusercontent.com/u/44240170/logfile-fff2.txt

And...... Back to 3.5.1 again :/

Thanks very much for that. Believe it or not I am (very slowly) making progress.

Here's the next test please:
http://ck.kolivas.org/apps/cgminer/temp/cgminer-ffs.exe

[Amph]

are vga still supported?

and why i can't copy past anymore with cgminer?

[os2sam]

are vga still supported?

New release: Version 3.8.1, 10th November 2013

GPU mining in any form is gone. Long live GPU mining (see previous post). New hardware support in this release and massive change with removal of GPU mining, but only bugfixes to the remainder of the code so to existing users this should be a safe upgrade, in keeping with even number releases sounding more stable.

[Amph]

yeah, i searched for it after my post

[jmc1517]

Thanks very much for that. Believe it or not I am (very slowly) making progress.

Here's the next test please:
http://ck.kolivas.org/apps/cgminer/temp/cgminer-ffs.exe

OK, tested!  Aside [again] The previous run of 3.5.1 lasted 25 hours without problems, although I do remember seeing a few AMU LEDs come on yesterday for a couple of seconds and I noticed some messages which were something like the following (completely from memory, as no logging enabled, can't remember the exact mS timings):
  [2013-11-xx xx:xx:xx] TIMEOUT AMUx something took xxx mS, was xxx mS
  [2013-11-xx xx:xx:xx] TIMEOUT AMUy something took xxx mS, was xxx mS
The above disturbances didn't cause any problems, so it may just be normal network problems, but I haven't noticed them before, so perhaps it's important, perhaps not.

Anyway, the test of cgminer-ffs ran for almost 2 hours, then a zombie appeared.  I turned on debug from the display and let run for a further 5 minutes, then stopped it.

Logfile is here:
  https://dl.dropboxusercontent.com/u/44240170/logfile-ffs.txt

And.... back to 3.5.1 for the evening!

[-ck]

OK, tested!  Aside [again] The previous run of 3.5.1 lasted 25 hours without problems, although I do remember seeing a few AMU LEDs come on yesterday for a couple of seconds and I noticed some messages which were something like the following (completely from memory, as no logging enabled, can't remember the exact mS timings):
  [2013-11-xx xx:xx:xx] TIMEOUT AMUx something took xxx mS, was xxx mS
  [2013-11-xx xx:xx:xx] TIMEOUT AMUy something took xxx mS, was xxx mS
The above disturbances didn't cause any problems, so it may just be normal network problems, but I haven't noticed them before, so perhaps it's important, perhaps not.

Anyway, the test of cgminer-ffs ran for almost 2 hours, then a zombie appeared.  I turned on debug from the display and let run for a further 5 minutes, then stopped it.

Logfile is here:
  https://dl.dropboxusercontent.com/u/44240170/logfile-ffs.txt

Thanks for that. No you were getting the timer overruns previously as well. I saw them on your successful logging when you put it up so even when it's "fine" it's not entirely fine, it's just that it sort of recovers.

Next!
http://ck.kolivas.org/apps/cgminer/temp/cgminer-w00t.exe

EDIT: And one greater than 9000:
http://ck.kolivas.org/apps/cgminer/temp/cgminer-9001.exe

[ChipGeek]

MrTeal and I have developed mining hardware called Chili using BFL chips and it uses the BLF driver.  The driver interface / protocol defines a command (ZTX) that allows cgminer to request three voltages from the hardware.  The 3 values are typically  3.3V, 1.0V, and 12V.  cgminer displays the 3.3V value on the screen but in my opinion this is the least interesting voltage value.  I would prefer it to show the (nominal) 1.0V value as this directly impacts hashing speed and power.  On other BFL hardware, this value is fixed at the factory, but on a Chili, it is configurable by software allowing automatic overclocking.  Thus the interest in displaying this value.

Please consider this reply a formal request to change the displayed value from the 3.3V value to the 1.0V value.  If you have enough screen real estate, it should show 3 digits to the right of the decimal point.  Ex: 1.057V  Thank you.

BTW - We have added a new field to the ZCX command to distinguish our hardware apart from BFL hardware:

Code:

"MANUFACTURER: MrTeal and ChipGeek\n"

[-ck]

MrTeal and I have developed mining hardware called Chili using BFL chips and it uses the BLF driver.  The driver interface / protocol defines a command (ZTX) that allows cgminer to request three voltages from the hardware.  The 3 values are typically  3.3V, 1.0V, and 12V.  cgminer displays the 3.3V value on the screen but in my opinion this is the least interesting voltage value.  I would prefer it to show the (nominal) 1.0V value as this directly impacts hashing speed and power.  On other BFL hardware, this value is fixed at the factory, but on a Chili, it is configurable by software allowing automatic overclocking.  Thus the interest in displaying this value.

Please consider this reply a formal request to change the displayed value from the 3.3V value to the 1.0V value.  If you have enough screen real estate, it should show 3 digits to the right of the decimal point.  Ex: 1.057V  Thank you.

BTW - We have added a new field to the ZCX command to distinguish our hardware apart from BFL hardware:

Code:

"MANUFACTURER: MrTeal and ChipGeek\n"

We're not as scary as we may appear. If you push code via github to cgminer that doesn't affect other drivers, we will probably give you some basic changes we'd prefer before merging the code with cgminer, but are happy to include code with the master cgminer code if you do it that way and are happy to support it. Ideally we prefer to get the hardware ourselves so we can extend/develop/bugfix/support the code for the hardware ourselves until the hardware is no longer relevant, but if not, I'm happy to merge code from you while you personally support the code unless it interferes with other drivers or the code stops being supported as bugs appear (which they always do).

[kano]

MrTeal and I have developed mining hardware called Chili using BFL chips and it uses the BLF driver.  The driver interface / protocol defines a command (ZTX) that allows cgminer to request three voltages from the hardware.  The 3 values are typically  3.3V, 1.0V, and 12V.  cgminer displays the 3.3V value on the screen but in my opinion this is the least interesting voltage value.  I would prefer it to show the (nominal) 1.0V value as this directly impacts hashing speed and power.  On other BFL hardware, this value is fixed at the factory, but on a Chili, it is configurable by software allowing automatic overclocking.  Thus the interest in displaying this value.

Please consider this reply a formal request to change the displayed value from the 3.3V value to the 1.0V value.  If you have enough screen real estate, it should show 3 digits to the right of the decimal point.  Ex: 1.057V  Thank you.

BTW - We have added a new field to the ZCX command to distinguish our hardware apart from BFL hardware:

Code:

"MANUFACTURER: MrTeal and ChipGeek\n"

Yep I'll change it in the next few days

[PenAndPaper]

Wasn't there a scrypt readme somewhere? I can't find it anymore 

No scrypt support any more.

Maybe you want to reconsider that given the latest boom in price, although i don't know the reasons that you stopped in the first place.

[ShadesOfMarble]

Wasn't there a rather big donation to get scrypt support in cgminer in the first place?

[-ck]

Wasn't there a rather big donation to get scrypt support in cgminer in the first place?

Yes, that's why I wrote it -as pure mercenary work- and maintained it for a year and gracefully offered to hand it off, even handholding various people on how to fork the existing code. But it's just a burden on the current code and has nothing in common with bitcoin mining on asics and now earns me nothing but headaches. Plus I don't believe in altcoins of any sort so it's hypocritical of me to maintain it.

[kano]

Wasn't there a rather big donation to get scrypt support in cgminer in the first place?

You donated?

[kslavik]

I'm trying to use JSON API with the following command sent over RPC:
{"command":"pools"}

I'm getting .."status":"E","When":11/28/2013 07:18:45","Code":14","Msg":"Invalid command","Description":"cgminer 3.8.3"...

API works however with regular text request/response and the same call is working fine for cgminer 3.8.1

Did something changed? or is it a bug?

[ShadesOfMarble]

Wasn't there a rather big donation to get scrypt support in cgminer in the first place?

You donated?

No. Why do you ask?

[forzendiablo]

i have API issues with cgwatcher too. I think the least version [or even 2 last ones] are crushed with API ussage.

[Trini8ed]

CG miner isn't displaying any text for me I am on windows 8.1 only way for it to display text is to do -T in the startup parameters without that the windows is completely blank.

[-ck]

I'm trying to use JSON API with the following command sent over RPC:
{"command":"pools"}

I'm getting .."status":"E","When":11/28/2013 07:18:45","Code":14","Msg":"Invalid command","Description":"cgminer 3.8.3"...

API works however with regular text request/response and the same call is working fine for cgminer 3.8.1

Did something changed? or is it a bug?

Looks like a bug with fixing the memory leaks of json usage in the API, thanks, will investigate.

[jmc1517]

Thanks for that. No you were getting the timer overruns previously as well. I saw them on your successful logging when you put it up so even when it's "fine" it's not entirely fine, it's just that it sort of recovers.

Next!
http://ck.kolivas.org/apps/cgminer/temp/cgminer-w00t.exe

EDIT: And one greater than 9000:
http://ck.kolivas.org/apps/cgminer/temp/cgminer-9001.exe

OK, tests done. Usual aside: Previous run of 3.5.1 stopped after 18 hours. No faults.

Test of cgminer-w00t started at 12:50. After about 5 minutes one LED (AMU 16) came on solid but no zombie was reported in the screen display.  I turned on debug and let it run for a few minutes, then I intended to re-plug the offending AMU and continue, but unfortunately I accidentally hit the power button on the hub and turned the whole thing off. D'oh! Test stopped at that point.  I'll run it again if you need more information.

Test of cgminer-9001 started at 13:01.  It ran for over 5 hours before a zombie (AMU27) appeared.  Turned on debug and let it run a bit more, then stopped the test at 18:45.  This one was looking quite promising until the fault popped up. Pity.

Logfiles are here:
  https://dl.dropboxusercontent.com/u/44240170/logfile-w00t.txt
  https://dl.dropboxusercontent.com/u/44240170/logfile-9001.txt

And.... Back to 3.5.1