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

Maybe we can narrow this down.
Can you get 1 to work by itself by work I mean detected and mining?
Something like cgminer.exe -S \\.\COMn
(where n = the correct device number for the FPGA device)
This is on page one of the thread. Under FPGA's  Substitute A for the and one should work. Once one works then we can improve upon that easily.
-T is a great idea as well as more then a few units will cause a crash. Curses issue.

I have compiled cgminer 2.7.4 with ztex support, but if start i get always:

Ztex check device: Failed to open handle with error -12
prepare device: -12

Whats wrong?

Apparently in my zeal to fix a previous error I over-wrote libcurl.pc. I thought I had gone back and re-edited it again.
I was wrong. Thank you. I now have successfully completed make.

Apparently not. They're still refusing to stop listing the library as a keylogger / trojan or whatever, even though the library is STILL not being used in that way. Lazy jerks.

Plug them in, then read the README, and add -T ...

Hi cgminer gurus!
Please explain me, how get it work my 50x ZTEX quads with last cgminer on Windows 7 prof. 32 bit. Step by step.
Or somebody have a link where this procedure already published.
Thx.

Boolean options are off by default, so you either want to turn them on (true) or not put them in the config file

... well that's how the code works anyway

Did you forget to, or improperly modify "\MinGW\lib\pkgconfig\libcurl.pc"?

As per the documentation...

Edit the file \MinGW\lib\pkgconfig\libcurl.pc and change "-lcurl" to
"-lcurl -lcurldll".

If that is not it, then more of the output from make is needed otherwise I am just guessing.

I see your point. For me it did drop the number of submitted shares. Sure they seemed to be submitted then rejected as prev-blk but it did submit more. My reject rate did drop but I can not gurantee that it was all that configuration option nor that it didn't drop a some shares off accepted. Not all pools request submission of stales. EclipseMC does for me and CGMiner happily sends them (for name coins) and they get rejected as prev-blk. Some I am sure where not rejected and possibly my numbers would be some better without it. I really should try sending stales as I made that config running 2.4.x so it is way old at worst I would only increase my reject ratio. At best I might actually get a valid share from time to time.  

Possibly I mis-stated that. I ment that the 600 second expiry wasn't likely much of an issue except for p2pool. Yes it is a bit over the average block time. It is about right for the expected block time. I know very few blocks will actually land 10 minutes apart. I would guess the number that have is likely very very low. Some are shorter, some longer. 600 seconds on p2pool would be very stupid. it would be about 60 blocks. I couldn't see a way to ask CGMiner nicely to submit all shares from the current block regardless of time except to do that. I wouldn't have messed with it but a pool going down for sometimes less then a second (times for pool disconnects and reconnects matched) would be followed by a series of discarded work. Possibly you can suggest a better setting to fix that issue? EDIT: This may not be an issue at all or was corrected already.


Setting
"net-delay" : false,
"no-submit-stale" : false,

will cause it not to load part of the config file. It seems only the part where those options are false. I tried changing them manually and have found deleting that line entirely will work but changing true to false doesn't work without an error in config file.

I am going out on a limb here and guessing no one has an idea how to fix my problem with mingW.

Well ... there is example.conf that comes with cgminer as stated twice in the README:

Options for command line only:
--config|-c    Load a JSON-format configuration file
See example.conf for an example configuration.
--help|-h           Print this message
--version|-V        Display version and exit

In the README FAQ:

Q: Can I put multiple pools in the config file?
A: Yes, check the example.conf file. Alternatively, set up everything either on
the command line or via the menu after startup and choose settings->write
config file and the file will be loaded on each startup.

However, no, the following is not JUST a p2pool issue.

Do not set "no-submit-stale" : true, without good reason.

As I stated: "It will probably mean a reduction of submitted shares, and ..."

The OP asked for an example. My settings work usually well for my pools. They may not work well for others. But to get someone started it seemed easier to change a couple of settings to match their settings. I was tempted to post it around 2 days ago to help the OP out but I did not as I was sure that someone would point out why my settings are bad for some pool or another. They are bad or P2Pool. I don't use P2Pool. Settings designed for the overly short LP on P2Pool seems as silly as having settings a little excessive the other way. Still I could likely drop the Expiry back to 60 seconds but a 20 second drop out was having discards immediatly after the pool came back up. It seemed like a waste to me. I do see how it could negativly effect people with high hashrates, me I would get 55 shares in 10 minutes give or take a throttle. I have never had it drop for all 10 minutes but I also haven't seen discards because of short dropouts or delays. I assume most of the discards hadn't been successfully submitted before the problems.

Please, no one, follow the above example without understanding the following options he's using:

Do not set "expiry" : "600", without good reason.

That will mean it will hold all shares generated but not able to be submitted for 10 minutes - which is a long time and could cause problems if you have a high hash rate and network instability.

Do not set "no-submit-stale" : true, without good reason.

It will probably mean a reduction of submitted shares, and on p2pool it can mean throwing away valid blocks.

Yes, but I haven't done the math to figure out how much. Luck will make it impossible to see on a simple kernel swap since luck's effect on U is greater than the magnitude of increase this may afford.

Only time I've ever seen it is when my Intensity is set too high. On 12.8 with a 7970, any I > 9 gives me 100% cpu bug.

I have never seen CGMiner use 100% CPU.

Thanks, it's just on dynamic.

I can post my config when I get home from work.

What is your I: ?

Can anyone give an example of a config file? I still can't get cgminer to make one.

Also, does anyone else have their cgminer.exe start using 100% CPU randomly?

So there's a chance that previous kernels were hashing just fine, but weren't finding shares. Will this increase U: even by a small amount?

Having trouble with mingW.
Windows 7 64 bit.
Followed the directions I believe correctly.
Problem:
No errors on the line with configure
CFLAGS="-O2 -msse2" ./configure --disable-opencl --disable-adl --enable-bitforce

Make gives me a bunch of lines that seemed ok. then missing a imp_curl

ending with this
collect2.exe: error: ld returned 1 exit status
make[2]: *** [cgminer.exe] Error 1
make[2]: Leaving directory `/home/user/ckolivas-cgminer-b768758'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/user/ckolivas-cgminer-b768758'
make: *** [all] Error 2