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

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: Inaba on May 05, 2012, 09:21:57 AM

Quote from: -ck on May 04, 2012, 05:33:05 PM

Quote from: Inaba on May 04, 2012, 02:21:18 PM

CGminer keeps exiting with this error:
[2012-05-04 19:12:37] Failed to tq_push work in submit_work_sync

I have to restart it manually at this point.

Usually this would imply something drastically wrong like running out of resources to spawn a new thread such as out of memory or hitting some thread limit. Given that people have successfully run cgminer on openwrt routers, I can't really envision what sort of set up would hit those limits unless you had massive hashrates, lots of pools set up, and minimal memory on the machine.

edit: Certainly in older versions cgminer would spawn lots and lots of communication threads but that shouldn't be the case in 2.4.0+

It's version 2.4. 8 pools, hashrate of that machine is about 14 GH/s, it's got 2 gigs of RAM. Am I seriously coming up against a wall at only 14 GH/s? I had planned on adding another 20 - 30 GH/s to that machine.

No in fact that is totally unexpected, though I don't have 14GH in one machine to kick around so I'm not sure how much ram that would require. Unless you have some kind of low limit on number of threads, pid_max, some ulimit set, some cgroup limitation or otherwise, I've tried hard so far to keep resource usage low on cgminer.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: check_status on May 05, 2012, 10:01:49 AM

Quote from: -ck on May 05, 2012, 08:36:24 AM

Quote from: check_status on May 05, 2012, 08:31:33 AM

I upgraded to 2.4.0 and had issues with not being able to alter the engine and mem clocks, they were using the old config file. After deleting the config file in the .cgminer directory, engine and mem clock changing functionality returned.

Is cgminer smart enough to know that if I use cammand line arguments to not use the config file?

No, it adds any command line arguments to any config file it loads. It will display which config file was loaded though so you know it was used.

There appears to be some conflict with the logic in how the config file + command line arguments are working together, from what I could tell.

The 2.3.2 config file had
gpu-engine "850,"
gpu-memclock "300,"

When I unpacked and ran the new built 2.4.0 I used the command line argument:
--gpu-engine 900,850 --gpu-memclock 250

Once it started I hit 'G' to see what the clocks were set at and the clocks were engine 850, memory 300, not what I used in the command line. Stopping and restarting had no effect on being able to alter the clocks. The only solution was to delete the config file.

It adds command line arguments after it has loaded the config file. So the config file was setting clock speed as you can see and your command line arguments were trying to set devices that don't exist.

os2sam

legendary

Activity: 3583

Merit: 1094

Think for yourself

Quote from: Hyphen on May 05, 2012, 11:59:24 AM

Every version of cgminer after I think 2.3.2 or 2.3.3 has crashed after a small amount of use.
Lost a good deal of money the last week using cgminer.
Confused as to why it just randomly exits with the newer versions?
Is there a new change I should be aware of that could possibly cause this with my settings?

With the overwhelming wealth of information you provided in your post I would have to say.... No.
Sam

Hyphen

newbie

Activity: 20

Merit: 0

Every version of cgminer after I think 2.3.2 or 2.3.3 has crashed after a small amount of use.
Lost a good deal of money the last week using cgminer.
Confused as to why it just randomly exits with the newer versions?
Is there a new change I should be aware of that could possibly cause this with my settings?

Inaba

legendary

Activity: 1260

Merit: 1000

Definitely version 2.4.0. RAM doesn't appear to be an issue... only using about 380MB out of 2G... 1.4G free. 120 threads total on the system.

It's been running for about 20 hours without a crash this iteration.

I am not explicitly enabling or using CPU mining.

check_status

full member

Activity: 196

Merit: 100

Web Dev, Db Admin, Computer Technician

Quote from: -ck on May 05, 2012, 08:36:24 AM

Quote from: check_status on May 05, 2012, 08:31:33 AM

I upgraded to 2.4.0 and had issues with not being able to alter the engine and mem clocks, they were using the old config file. After deleting the config file in the .cgminer directory, engine and mem clock changing functionality returned.

Is cgminer smart enough to know that if I use cammand line arguments to not use the config file?

No, it adds any command line arguments to any config file it loads. It will display which config file was loaded though so you know it was used.

There appears to be some conflict with the logic in how the config file + command line arguments are working together, from what I could tell.

The 2.3.2 config file had
gpu-engine "850,"
gpu-memclock "300,"

When I unpacked and ran the new built 2.4.0 I used the command line argument:
--gpu-engine 900,850 --gpu-memclock 250

Once it started I hit 'G' to see what the clocks were set at and the clocks were engine 850, memory 300, not what I used in the command line. Stopping and restarting had no effect on being able to alter the clocks. The only solution was to delete the config file.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Inaba on May 05, 2012, 09:21:57 AM

Quote from: -ck on May 04, 2012, 05:33:05 PM

Quote from: Inaba on May 04, 2012, 02:21:18 PM

CGminer keeps exiting with this error:
[2012-05-04 19:12:37] Failed to tq_push work in submit_work_sync

I have to restart it manually at this point.

Usually this would imply something drastically wrong like running out of resources to spawn a new thread such as out of memory or hitting some thread limit. Given that people have successfully run cgminer on openwrt routers, I can't really envision what sort of set up would hit those limits unless you had massive hashrates, lots of pools set up, and minimal memory on the machine.

edit: Certainly in older versions cgminer would spawn lots and lots of communication threads but that shouldn't be the case in 2.4.0+

It's version 2.4. 8 pools, hashrate of that machine is about 14 GH/s, it's got 2 gigs of RAM. Am I seriously coming up against a wall at only 14 GH/s? I had planned on adding another 20 - 30 GH/s to that machine.

The issue is we've tested cgminer 2.4.0 with 4 large farms.
One was 91 Icarus ~34GH/s on a single computer - and it ran fine.
Another has a single computer ~12GH/s with 14 BFL and 2 GPUs (again works fine)

Thus firstly the question of if you certainly were using 2.4.0
If you are running out of RAM you can of course easily see that yourself (and report that here)
And top will tell you the number of threads also (which you know how to do I'm sure)

Thus if the problem is certainly with 2.4.0 then there must be something different about your setup compared to the other 4 that is triggering this issue and will need more details to try and sort it out

I will add the obvious side comment - I presume you are not compiling and running CPU mining since that is unsupported and is known to cause thread issues.
You can check this with

Code:

cgminer -h

(at the top of the help text) or

Code:

echo -n config | nc 127.0.0.1 4028 ; echo ; echo -n version | nc 127.0.0.1 4028 ; echo

(if the API is enabled)

Inaba

legendary

Activity: 1260

Merit: 1000

Quote from: -ck on May 04, 2012, 05:33:05 PM

Quote from: Inaba on May 04, 2012, 02:21:18 PM

CGminer keeps exiting with this error:
[2012-05-04 19:12:37] Failed to tq_push work in submit_work_sync

I have to restart it manually at this point.

Usually this would imply something drastically wrong like running out of resources to spawn a new thread such as out of memory or hitting some thread limit. Given that people have successfully run cgminer on openwrt routers, I can't really envision what sort of set up would hit those limits unless you had massive hashrates, lots of pools set up, and minimal memory on the machine.

edit: Certainly in older versions cgminer would spawn lots and lots of communication threads but that shouldn't be the case in 2.4.0+

It's version 2.4. 8 pools, hashrate of that machine is about 14 GH/s, it's got 2 gigs of RAM. Am I seriously coming up against a wall at only 14 GH/s? I had planned on adding another 20 - 30 GH/s to that machine.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: check_status on May 05, 2012, 08:31:33 AM

I upgraded to 2.4.0 and had issues with not being able to alter the engine and mem clocks, they were using the old config file. After deleting the config file in the .cgminer directory, engine and mem clock changing functionality returned.

Is cgminer smart enough to know that if I use cammand line arguments to not use the config file?

No, it adds any command line arguments to any config file it loads. It will display which config file was loaded though so you know it was used.

check_status

full member

Activity: 196

Merit: 100

Web Dev, Db Admin, Computer Technician

I upgraded to 2.4.0 and had issues with not being able to alter the engine and mem clocks, they were using the old config file. After deleting the config file in the .cgminer directory, engine and mem clock changing functionality returned.

Is cgminer smart enough to know that if I use cammand line arguments to not use the config file?

Edit: 2.4.0 is running well. E: 30% on P2Pool
Another issue: Hardware errors when I first ran 2.4.0 HW: 9 in 3min. Q and restart errors no longer appeared.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: Inaba on May 04, 2012, 02:21:18 PM

CGminer keeps exiting with this error:
[2012-05-04 19:12:37] Failed to tq_push work in submit_work_sync

I have to restart it manually at this point.

Usually this would imply something drastically wrong like running out of resources to spawn a new thread such as out of memory or hitting some thread limit. Given that people have successfully run cgminer on openwrt routers, I can't really envision what sort of set up would hit those limits unless you had massive hashrates, lots of pools set up, and minimal memory on the machine.

edit: Certainly in older versions cgminer would spawn lots and lots of communication threads but that shouldn't be the case in 2.4.0+

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: Aseras on May 04, 2012, 01:29:01 PM

What I'd love is to have a command to have cgminer reload the config file without restarting.

That way you could change or edit the files and just trigger a restart in the api.

Just restart it from the menu or the API, and it will reload the config file.

fred0

sr. member

Activity: 349

Merit: 250

I recently made a change to cgminer's logging.c to eliminate the accepted/rejected share logging. Basically, I changed the LOG_NOTICE to LOG_WARNING on line 54 of logging.c. It really cuts down on the noise level of the cgminer window.

What I think would be a useful change would be to specify the verbosity of the messages through the command line, rather than the --quiet which eliminates virtually all messages.

Example output follows:

Code:

 [2012-05-04 12:37:45] Pool 0 not providing work fast enough
 [2012-05-04 12:40:22] Pool 0 communication failure, caching submissions
 [2012-05-04 12:40:23] Pool 0 communication resumed, submitting work
 [2012-05-04 13:50:30] Pool 0 not providing work fast enough
 [2012-05-04 14:25:35] Pool 0 not providing work fast enough
 [2012-05-04 16:38:04] Pool 0 not providing work fast enough

Kuma

member

Activity: 107

Merit: 10

I understood from Ztex documentation, than the firmware is flashed to the eeprom (indeed firmware is the same).

If I remember correctly I used

java -cp ZtexBTCMiner-120417.jar BTCMiner -m p -f ztex_ufm1_15y1.ihx

And after that I was able to use cgminer even after Quad and computer reboot. Before this step I had to run btcminer first, to be able to use quad under cgminer.
I hope I'm not mistaken as I tested this only briefly

.

BTW the problem with the user rights was under Fedora, I had to run cgminer or btcminer as a root to be able to use quad for mining.

nelisky

legendary

Activity: 1540

Merit: 1002

Quote from: Kuma on May 04, 2012, 02:20:13 PM

Hi,
I tried Nelisky's code and it works perfectly for my Ztex quad.
Two notices. I think there should be mentioned udev setting regarding access rights (from http://wiki.ztex.de/doku.php?id=en:software:usb_ids) in the README file. I also noticed, I must flash device to the cluster mode using BTCMiner for the first time to be able to use cgminer for Ztex after reboot.

It's funny, I never had to deal with access rights. But I guess that's a byproduct of the distributions I've been using.

As for flashing to the cluster mode, you do have to upload the firmware first using BTCMiner, but there's no 'cluster mode' per se, that's just a mode of operation for the mining software. The firmware is the same in either standalone or cluster mode. I do plan to add the ability to flash the firmware eventually, but since that's a one off operation (well, sort of, once per version upgrade from ztex) it is not something I plan to tackle just yet.

My implementation is seriously lacking in documentation, that much is certainly true, but with my limited environment testing I hope someone that has to deal with the installation from scratch will step up and do that (hint, hint).

zefir

donator

Activity: 919

Merit: 1000

Quote from: Luke-Jr on May 04, 2012, 08:34:55 AM

Quote from: zefir on May 04, 2012, 02:55:04 AM

Is there some event that all USB initializations have been processed in Linux to check before cgminer is started? Other than grep-ing dmesg for ttyUSBx ?

Code:

udevadm settle

Thanks. But after this didn't help I looked deeper and it was something completely different. In short, do:

Code:

sudo apt-get purge modemmanager

to get rid of that component that kicks in after boot and interferes with cgminer.

Inaba

legendary

Activity: 1260

Merit: 1000

CGminer keeps exiting with this error:
[2012-05-04 19:12:37] Failed to tq_push work in submit_work_sync

I have to restart it manually at this point.

Kuma

member

Activity: 107

Merit: 10

Hi,
I tried Nelisky's code and it works perfectly for my Ztex quad.
Two notices. I think there should be mentioned udev setting regarding access rights (from http://wiki.ztex.de/doku.php?id=en:software:usb_ids) in the README file. I also noticed, I must flash device to the cluster mode using BTCMiner for the first time to be able to use cgminer for Ztex after reboot.

Aseras

hero member

Activity: 658

Merit: 500

What I'd love is to have a command to have cgminer reload the config file without restarting.

That way you could change or edit the files and just trigger a restart in the api.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: jamesg on May 04, 2012, 12:24:59 PM

This is a nice request although I have done this with a bash script and the API.

Yeah I got a workaround but it is clunky. As I use the API more and more I am finding I want the ability to never need to remote into the rig. Monitor from the API and have the config file control everything.

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