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

I'm not adding the stratum+tcp:// specification, but the program does add it automatically when I run it even though I am specifically pointing it at http://mint.bitminer.com:8332

I think it might be like Inaba was saying with it being a problem with the pools listed as a failover because I am also attempting to use BitMinter as a failover while receiving this error.

I will test by switching it's order and report back.

You're right, it wasn't tagged. Tagged now (and be aware it's on the 2.9 branch).

Either I was too quick on the draw or you have not updated the version string as a fresh git clone tells me I will compile a version 2.9.6.

New version: 2.9.7, 7th December 2012

Bugfix only release. There are lots of pending changes which will be a new point release, but this is concentrating only on the known bugs that have fixes for 2.9.


Human readable changelog

Fixed the problem where backup stratum pools specified with stratum+tcp:// first would never come online.
Fixed another crash with GBT.
Decrease rejects with stratum by tying in target difficulty only with the work difficulty, as discussed on this forum thread with slush et. al
Don't show WU with scrypt mining since the number is wrong.
Windows builds are built and shipped with a new libcurl (and libusb) dll that hopefully improves stability.
Better load balance with stratum.


Full changelog

- Set pool probed to true on successful authorisation with stratum to avoid it
being pinged later with pool_getswork.
- Allow pool active to be called on stratum or disabled pools in the watchpool
thread if the pool has not been probed.
- Remove unused variable.
- Use a variable length string array in submit_upstream_work to cope with
massive GBT submissions.
- Remove unused getwork times in getswork.
- Don't show broken WU value with scrypt mining.
- The specification for stratum has been elaborated to say that a changed diff
applies only to new work so do not retarget when submitting shares.

I have the same error on v2.9.3 but it works fine on v2.9.5.
Weird.

Yeah, are you specifying the stratum server with stratum+tcp:// ? There's an issue with backup pools specified that way at the moment. Try leaving out the prefix, or specify them as http:// and it will just do stratum.

Seems to be a strange problem with CGMiner and EMC as far as Stratum goes:

If I start cgminer with stratum pointed at one of my servers, it works fine and mines via stratum.  However, if I have one of the servers as backup and it's listed as stratum, it shows as dead and won't switch to it. 

Put another way, if I start with stratum on one of my servers, no problem.  If I try to add/switch to stratum on one of my servers, CGMiner won't work. 

Any ideas?  This is for version 2.9.6, I haven't tried previous versions.

Receiving unusual error when trying to connect to BitMinter:


cgminer works fine at all the other pools I use it at though. Any ideas?

Found an issue, Unsure on the cause but it could just be windows.

Win7 64 bit, CGMiner 2.9.6, BFL single.

Pool: Eclipse.

Eclipse seemed to have failed. US2, US3, on stratum marked dead as well as US3 GBT. US1 marked alive but no hashes submitted in 30 mins. Disabling US1 knocked me back to my backup pool and Bitpenny is working as shares are being submitted.

Debug showed all stratum pools marked dead as initiate failed, but US1 didn't seem to be doing anything. No rolling work messages, just test messages about the failed pools and a dropping hashrate when I re-enabled to double check the messages. Actually it shows a can't initiate for pool 1 (us1.eclipsemc.com:3333) so it should be dropping back to my backup pool and marking US1 dead too right?

Oh when I first came back and saw the issue I had 2 New block detected I can't remember if it was a LP, Stratum, or on network before the pool. Sadly I wish I hadn't tried to correct the lost money first and had typed what I noticed.

EDIT: It looks like there was an underlying issue with my internet connection. After eclipse died on me bitpenny worked for a while. Router log showed some errors. LRP router so the information was some better then consumer units. Once corrected well once a new IP was procured everything is running smooth. Strangely despite a duplicate IP message (unsure if someone was assigned mine or there was a spoof going on) some data still went out. I don't think it should have.

There will shortly be some massive changes to the git master tree - no unfortunately it still isn't any ASIC driver, but it will be stuff to prepare for it. In anticipation, I have created a 2.9 branch for those who want just fixes to the stable tree in the meantime. Some fixes to existing issues have already been committed to the 2.9 branch, but lots of potential breakage will be making its way into the master tree.

One might note that I fixed this in BFGMiner a while ago, thanks to much debugging help from jddebug. It's not the most elegant fix, but it does do the job.

mingw32-curl 7.27.0-1 is what I'm distributing libcurl from.
The one people usually post as a bug is that their own IP address changed or something like that.

You might try downloading the cgminer source and following the windows-build.txt instructions for building your own binary of cgminer. That would get you the latest version of libcurl. If it is a libcurl issue this may fix it as C. kolivas does not update his dependencies  that often. Good Luck

   between linux and mac users, the jabs never end...

Will do on the debug.... I may be working in an uncommon setup which may be compounding the issue. I run plonk to create an ssh tunnel on port 3333 to the pool via my home DDWRT router. Because the SSH tunnel can collapse at the slightest of network hiccups, which we have many, I restart plonk every 30 minutes. I believe the issue only happens when connected via stratum protocols. Too early to tell, I just started with cgminer since my pool switched over to stratum. However, I wish I had looked at it sooner because I am getting much better hash rates with cgminer!

Thanks!!

Longstanding bug on windows for when network goes down; it's my secret way to get people to move to linux.

Obviously not the case, but anyway I've not been able to reproduce it myself so must be some combination of windows or other issue. You could always try helping debug it following instructions in here:
http://ck.kolivas.org/apps/cgminer/debug/

I suspect it's just the libcurl implementation on windows... which would be bad news since it won't be something I can personally fix.

I just started using cgminer after over a year with phoenix and no issues and I am seeing this behavior. If there is a network issue, cgminer crashes in Windows and I get the not responding...searching for a resolution dialog from Windows. I can replicate the behavior like clockwork because I am mining over an SSH tunnel and I have a scheduled task that kills plonk every 30 minutes and restarts it. When plonk gets killed, cgminer crashes. So it does not like losing its network connection at all.

Additionally, I think the issue only happens when connected via the stratum protocol, but I am investigating the details...

Cgminer CPU mining code is obsolete, use another CPU miner you will get 2x hash rate.

As per the README

Could someone tell me how to make a .bat file to mine with both gpu and cpu at same time what is the commands needed to use both gpu and cup at same time usin cgimner and amd cpu??

was (trying) to compile it for 32bit mipseb... I am trying under a 32bit system soon, i will report, this is not a cgminer problem, when googling, found out, that debian has trouble offering the right stuff when cross compiling.


compiling it to run under the 64bit ubuntu is no problem...