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

Seems implausible, as I had the problem with 2.1.0.

And as reported earlier, the problem, in addition to being highly intermittent, is not persistent.  My current session, which started about 16 hours ago and had three rashes of the problem in its first eight hours or so, has since been cruising fine for eight hours.  At this writing there are 111 instances of "LONGPOLL detected" in the log.

But, ever cooperative, I just now restarted with no-longpoll.

Hmmm...

Can you guys try starting it without longpoll? Maybe the longpoll switch code is responsible which is new since 2.1.0

cgminer's stale rate should be exceptionally low even without longpoll, but it will be slightly higher.

do you guys think its possible for a pool to make your cards run funny if the pool is configured in a certain way?

Donation and NAT, but not Google DNS;  failover-only pools in this order:
Eclipse port 9007;
Bitminter;
Eclipse port 8337;
local bitcoind

Mine have worked for weeks without problems, or at least without me noticing. It seems to be happening more and more often now.

Anyway, lets see if we can find anything else in common, besides just cgminer.

- Im using google DNS
- I have donations enabled. (thinking of disabling it, just for testing)
- I have several pools configured in fail-over (but Ive since encountered the problem on several different pools)
- Im behind a NAT router
- hmm?

Ive already ruled out OS and AMD driver versions as its happening on both windows and linux machines here with various drivers and cgminer versions.

That's exactly what triggered my scrolling through the log this morning:  a low average hash rate, E%, U, etc.

No problems since my last post -- two more hours -- in the same session.

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.

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 ?

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.

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. 

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


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.

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

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.

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.

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.

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.

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.

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

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.

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.