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

[DeathAndTaxes]

Am i the only one without problems ?  Win7 32, 2.1.1, 2 rigs, zero problems 

I haven't had any problems either.

[-ck]

Yay thank goodness.

By the way, error 503 is a server not responsive, too busy etc. error... though it is possible to generate this artificially from the miner's end by having DNS issues, router problems and so on. Disabling cached connections in 2.1.1 after failure seemed to achieve sweet FA unfortunately. So I'm now officially in the NFI position.

[Turbor]

Sent you one BTC to cheer you up 

[P4man]

Yay thank goodness.

By the way, error 503 is a server not responsive, too busy etc. error... though it is possible to generate this artificially from the miner's end by having DNS issues, router problems and so on. Disabling cached connections in 2.1.1 after failure seemed to achieve sweet FA unfortunately. So I'm now officially in the NFI position.

Networking and internet seems fine even when that happens, though its quite possible a brief network quirk triggers it. Restarting routers does not help.  Next time it happens, Ill see if disconnecting and reconnecting ethernet does anything. Anything else worth testing? Like flushing DNS or whatever?

As for DNS, not sure if its worth mentioning, but Im using Google's DNS servers.

[DeathAndTaxes]

Yay thank goodness.

By the way, error 503 is a server not responsive, too busy etc. error... though it is possible to generate this artificially from the miner's end by having DNS issues, router problems and so on. Disabling cached connections in 2.1.1 after failure seemed to achieve sweet FA unfortunately. So I'm now officially in the NFI position.

Networking and internet seems fine even when that happens, though its quite possible a brief network quirk triggers it. Restarting routers does not help.  Next time it happens, Ill see if disconnecting and reconnecting ethernet does anything. Anything else worth testing? Like flushing DNS or whatever?

Likely unrelated but the only networking issues I have seen is when my switch got too hot.  I got 4 rigs in the garage running on their own switch.  I found that is room ambient temp got too hot the switch (fanless) would go "crazy" and make the miners drop from the network.  I "solved" it by putting the switch closer to the ground (cooler) and putting a small desktop fan next to it.

When your miners indicate the pool is unavailable can you still remote into them (SSH)?

[P4man]

When your miners indicate the pool is unavailable can you still remote into them (SSH)?

Yes. Im pretty much always SSH-ed into them, the ssh connection has never broken.  One of the miners is also used as fileserver.
AFAICT, there are no problems on my LAN. And the miners can access the internet just fine, even when that HTTP 503 happens in cgminer.

[DeathAndTaxes]

When your miners indicate the pool is unavailable can you still remote into them (SSH)?

Yes. Im pretty much always SSH-ed into them, the ssh connection has never broken.  One of the miners is also used as fileserver.
AFAICT, there are no problems on my LAN. And the miners can access the internet just fine, even when that HTTP 503 happens in cgminer.

Weird and weirder.  Only thing I could think of testing is on only one machine try making the pool (or maybe just backup pool) an IP address instead of domain name.  If it is DNS related that should indicate it.  Obviously not something you would want to keep long term but maybe it will help narrow it down.

[P4man]

Weird and weirder.  Only thing I could think of testing is on only one machine try making the pool (or maybe just backup pool) an IP address instead of domain name.  If it is DNS related that should indicate it.  Obviously not something you would want to keep long term but maybe it will help narrow it down.

Actually, the primary pool already uses an IP address, not a domain name. (im renting out my local rigs to mustang for testing his pool, he doesnt have domain name yet).

And it happened again just now. Like second time in an hour.  But this time on both machines.
 I tried pulling and plugging back in the ethernet cable, not sure why, but it didnt help. As always, restarting cgminer does help.

[DeathAndTaxes]

Weird and weirder.  Only thing I could think of testing is on only one machine try making the pool (or maybe just backup pool) an IP address instead of domain name.  If it is DNS related that should indicate it.  Obviously not something you would want to keep long term but maybe it will help narrow it down.

Actually, the primary pool already uses an IP address, not a domain name. (im renting out my local rigs to mustang for testing his pool, he doesnt have domain name yet).

And it happened again just now. Like second time in an hour.  But this time on both machines.
 I tried pulling and plugging back in the ethernet cable, not sure why, but it didnt help. As always, restarting cgminer does help.

Alright you stumped me.  The good news is we know what it isn't.

[The00Dustin]

Im pretty much always SSH-ed into them, the ssh connection has never broken.  One of the miners is also used as fileserver.
AFAICT, there are no problems on my LAN. And the miners can access the internet just fine, even when that HTTP 503 happens in cgminer.

I'm not suggesting hat it's definitely your LAN or Internet connection, but in my experience, at least when connecting to SSH using PuTTY in Windows, a broken network connection doesn't always show up, as the SSH connection will sometimes silently recover when there hasn't been a disconnect notice sent and you try to use it after the network recovers (in an even more irrelevant note, MSTSC does the same thing with RDP connections).  IOW, a couple dropped packets, or even a complete loss of connectivity (at layer 3 or higher) will not necessarily phase your SSH connection even if it phases cgminer.

[gnar1ta$]

P4man have you tried a different miner?  I don't think it's a cgminer issue.  I had the same errors with other miners, cgminer just handles it better...up to 2.0.7 anyway.  I get huge latency jumps to any IP since a lightning strike hit the cable line.  I thought it was cleared up, but apparently I was just overlooking it because the miner recovers and keeps hashing.

[P4man]

Its certainly possible my internet connection isnt 100% perfect, and something flaky may trigger it, but it doesnt explain cgminer's behavior. It should just continue working the moment the internet connection is restored. And it actually does that when I eg unplug the network cable. After plugging it in again, it resumes working as youd expect. Same when my ISP went down for an hour some weeks ago. It didnt require anything for me to get cgminer to start working again.

But once this 503 conditions starts, cgminer will never (*)  resume working correctly until restarted, even though there is definately nothing wrong with my lan or internet connection at that point (and I suspect there never has been, but who knows).

As for different miners, yes I tried bitminter and not had issues with that.

(*) actually, if I saw it correctly, cgminer will occasionally submit valid shares for very short periods of time.

[gnar1ta$]

But once this 503 conditions starts, cgminer will never (*)  resume working correctly until restarted, even though there is definately nothing wrong with my lan or internet connection at that point (and I suspect there never has been, but who knows).

This I see with anything after 2.0.7.  Otherwise it does take hours to recover, or a restart, but it does recover.

Does bitminter use phatk? The other miner I used also used phatk.

[mmortal03]

I'm seeing something broken in 2.1.0 that I wasn't seeing in 2.0.8. When I hit 'Q' to quit the program, it actually doesn't quit and instead keeps running. What it does, however, is start adding odd lines of information at the bottom of the command window, line by line. For context, I'm running cgminer with a command line that looks like this:

cgminer.exe -o http://us.eclipsemc.com:8337/ -u [username] -p [password] -o http://bitcoinpool.com:8334/ -u [username] -p [password] -k phatk -I 9 --submit-stale --auto-fan --auto-gpu --gpu-engine 999 --gpu-memclock 150 -q --donation 1.0

I think this got lost in the shuffle. 

One other thing, is anyone able to start cgminer from a remote desktop session and have it detect their gpus? I can monitor what cgminer is doing on my machine over remote desktop, but if I close cgminer remotely and then try to start it back up from the remote session, it doesn't detect the gpu.

[kano]

I still think it's some curl related issue.
Do the other miners use curl also?
If they do then I guess: see how they handle a 503 may be a possible option?

Anyway, the reason I actually made this post is this:
Is anyone interested in me making some changes to 3 programs and setting up a pool:
Adding a socket interface to bitcoind, a pool (whichever one I or someone else decides) and cgminer.
I also suspect it may resolve a long term issue of pool performance.

I'm probably gonna do some simple testing with bitcoind anyway since I have a web page of my own that already does a a 2016 block access to bitcoind (with a slightly modified getblockbycount) and also a program that reads the whole blockchain and caches it, again using getblockbycount.
Both of these will easily show if there is a major performance gain by using a simple socket interface like I used in the cgminer API instead of curl ... and the same on the bitcoind side
I suspect there will be a performance gain but I'll test it first to be sure
From the cgminer side it would simply be an extra option (something like "--sockets") to use that interface instead of the default standard curl interface to the pool (and for a different LP also)

Anyone be interested in this?
I wont be chasing a donation limit to do this - since I'm interested in at least doing the initial tests myself anyway
(but of course I'll happily accept donations to get it done anyway)
But I'm more interested in knowing if people would be interested in 2 things:
firstly helping with testing the code on a pool (obviously I'd need some reasonable hash rate to test it and find the problems that occur and implement what should be simple fixes for them)
secondly be interested in using such a pool permanently once it's up a working well

The options would be either some form of PPS or something like DGM (or I don't know what else)

So basically I'm interested in putting a simple socket interface from cgminer all the way through to bitcoind and see if it performs much better and is more reliable (than curl) and should have a VERY low stale/reject rate
(and the cgminer change would be an extra option to run the socket interface instead of the default curl interface - but not both at the same time)

If there is interest I'll start a separate thread on the subject, but I'm posting here first to see if the cgminer users are interested in it.
Also, the pool would of course be charging some small % fee and if ckolivas is interested I guess he can be part of that % so he is actually getting something a bit more than just trivial from all the people using cgminer

[P4man]

Does bitminter use phatk? The other miner I used also used phatk.

I dont think so, I believe DrHaribo handcoded the whole thing.

Is anyone interested in me making some changes to 3 programs and setting up a pool:
Adding a socket interface to bitcoind, a pool (whichever one I or someone else decides) and cgminer.
I also suspect it may resolve a long term issue of pool performance.

Id be interested and wouldnt mind throwing one or two videocards at it during testing, but in the long run, assuming it does provide some benefit, I would like to see this in other pools as well.

[gnar1ta$]

One other thing, is anyone able to start cgminer from a remote desktop session and have it detect their gpus? I can monitor what cgminer is doing on my machine over remote desktop, but if I close cgminer remotely and then try to start it back up from the remote session, it doesn't detect the gpu.

I don't know about windows, but with linux you need DISPLAY=:0 before your launch string if starting over vnc/ssh to detect the GPU's. 

[Proofer]

...
But once this 503 conditions starts, cgminer will never (*)  resume working correctly until restarted, even though there is definately nothing wrong with my lan or internet connection at that point (and I suspect there never has been, but who knows).

As for different miners, yes I tried bitminter and not had issues with that.

(*) actually, if I saw it correctly, cgminer will occasionally submit valid shares for very short periods of time.

Last night, cgminer had pool connection issues during the following intervals:
00:10 - 00:12; duration 2 minutes
03:52 - 04:31; duration 39 minutes
06:55 - 08:05; duration 70 minutes

A problem interval is from the first "not responding!" to the final "recovered" with at most a dozen or two "accepted" between communication-related outputs.

At this writing, 09:25 it's been running normally for 80 minutes.

In sum, at least for its current session, it does seem to resume working correctly.

[bitlane]

I don't want to play Devil's Advocate, as I understand many people seem to be having issues with the latest release (2.1.1), but for me, my performance for Pool mining has actually increased.
The MH/s stats at my pool have never been higher than they are over the last 24 hours or so and my Share/minute rates are up a tiny bit.

What would have changed to allow this to happen ? ....as nothing has changed on my end.
The miner seems to be connecting to the pool more efficiently, as it were.
(Win 7 x64, all cards, Cat 11.9-11.10)

Any ideas ?

[P4man]

...
But once this 503 conditions starts, cgminer will never (*)  resume working correctly until restarted, even though there is definately nothing wrong with my lan or internet connection at that point (and I suspect there never has been, but who knows).

As for different miners, yes I tried bitminter and not had issues with that.

(*) actually, if I saw it correctly, cgminer will occasionally submit valid shares for very short periods of time.

Last night, cgminer had pool connection issues during the following intervals:
00:10 - 00:12; duration 2 minutes
03:52 - 04:31; duration 39 minutes
06:55 - 08:05; duration 70 minutes

A problem interval is from the first "not responding!" to the final "recovered" with at most a dozen or two "accepted" between communication-related outputs.

At this writing, 09:25 it's been running normally for 80 minutes.

In sum, at least for its current session, it does seem to resume working correctly.

Interesting.
And I may have had the same here; there have been mornings when I checked hashrate and it was surprisingly low. Probably because of that error. When I caught it "live" I  never waited 70 minutes, so you are probably correct that at some point it may recover, I just never waited long enough.