Slush's document stipulated that it should refresh at least every 60 seconds. If it's much longer than that, since you're dealing with raw sockets that can quietly die, there is no way for the miner software to know if the socket has disappeared, so cgminer uses 90 seconds between messages to say the pool has died so you cannot increase it to much more. Updating it more frequently includes newer transactions but requires more refreshes on your mining software, and vice versa.
|
|
|
Planned features (will be available in next alpha release): These two are for real bitcoin mining cheaters: ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) 1. Non-zero starting nonce. Makes possible to set starting nonce, that is non-zero. For example, let we noticed that nonce value is very seldom less than 0x01000000. So why don't we start with the search of nonces from this starting point? ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) 2. "Nonce-bouncing". Sets new starting nonce value, which depends from the previously found nonce(s). It also can change during the hashing; increase, then decrease, then increase again ... - i.e., "bouncing", or fluctuating around some median value. Logic fail. These will have no effect.
|
|
|
When cg crashes because you may have a card with to low voltage, is there a way to get it working at full speed again without rebooting? I have a card (7950) that does say 650 KH/s and when it crashes will only do 390 even if rebuild the bin files. Not sure why but it does that and only a reboot helps. My system has a boot password and is remote so restarting is impossible without a hour drive. Any thoughts?
Window 7 64-bit
Thanks.
JR
It's a driver crash not a cgminer crash. That it can restart at all is a miracle. No solution, just keep tuning your settings to avoid the crash in the first place.
|
|
|
Primary cgminer binary download site down. Git repo won't allow downloading of files either right now.
FYI
Down for maintenance yet again. There is an alternate download location listed in the opening post. Yep. Hence my comment. Git repo says you can't download files of that size right now. JR I just clicked on one and downloaded it. Works fine. Choose view raw.
|
|
|
Awesome, so basically I have a chance to make some bitcoin profit with my 28nm miner assuming it arrives in a timely fashion.
If history is anything to go by, no. b) Miners are bad at math. They may collectively buy hundreds of PH/s of capacity. So much capacity that collectively miners lose (total hardware cost + total electrical cost
|
|
|
Primary cgminer binary download site down. Git repo won't allow downloading of files either right now.
FYI
Down for maintenance yet again. There is an alternate download location listed in the opening post.
|
|
|
CGMiner seems to be randomly closing. I'm running cgminer-nogpu on Win 8x64 with a BFL Little Single and 2 AMUs. It runs in a batch file that loops, and the batch file keeps restarting it, so it is closing nicely, and I haven't lost any downtime. I think it's done it about 4-5 times since I updated to 3.4.0, which was about 8 days ago? The newest one was this morning, after I had left for work. It had been running for about 2 days solid before that.
It never did this before. The AMUs are pretty new. Is it the AMUs causing it, or upgrading to 3.4.0, or both?
Hard to know without excluding one thing at a time? Try running the AMUs in their own instance and see if one the other or both crashes? Also there are debug builds which would help me find out where it's crashing and fix it. http://ck.kolivas.org/apps/cgminer/debug/I ran 2 instances of CGMiner-nogpu like you suggested, one with 2 SC Single (1x 30GH + 1x 60GH), and one with 2 AMUs. The instance with the 2 BFL miners was the one that crashed. I didn't see it happened, as it was about 45 minutes ago, but again my batch file seems to have restarted it. I'll try 3.4.1 and see if anything changed. It won't debug anything unless you install the debugger as described in the debug readme in there. Anyway see how you go with 3.4.1, I found a few places that could lead to crashes that I fixed in that version. I will also update the debug binaries to be 3.4.1
|
|
|
Big changes to the build process, read changelog for details. If building from git, make sure to do make clean and ./autogen.sh before attempting to build the significantly changed build process.
I am trying to compile from the Git source on OS X. I am cloning into a brand new, clean directory. From there I autogen.sh like I always have, and I get an error: checking that generated files are newer than configure... done configure: creating ./config.status config.status: error: cannot find input file: `Makefile.in' I've tried using autoconf and automake as the readme file suggests under the "Build cgminer for yourself" but that does not help. I have also tried doing make clean but there is no target for 'clean' as nothing has been configured or build yet. - Fixed the broken OSX build from 3.4.0, but so many things were changed after that in the build process that it may be broken again.
Try a release tarball instead of building from git, but I can't guarantee anything on OSX. If that fails, the last known good release for osx on git was git checkout 036c7b73f1244e52a8aedf3990ecf862d03310f4
|
|
|
New release: Version 3.4.12, 1st September 2013
Happy Father's day (in Australia, dunno about rest of the world). Big changes to the build process, read changelog for details. If building from git, make sure to do make clean and ./autogen.sh before attempting to build the significantly changed build process. Sorry I can't provide avalon firmware now since I went to push the reset button on my avalon and instead of it pressing it broke off... so I don't trust myself to make untested brickwarefirmware as I just mine on it via a USB cable to my PC now.
EDIT: 3.4.2 released shortly after with hotfix for crash on BFLSC
Human readable changelog:
3.4.2: - Fixed crash with BFLSC hardware. - Added ability to put arbitrary values in miner.php
3.4.1: - Libusb and jansson have both been updated to the latest version and are now part of the build tree. - Libusb and jansson will both be built into the binary statically so all binaries will include the latest version of these libraries, avoiding the problems associated with older versions. - There is no need for libusb dev or jansson dev to be installed when compiling cgminer now. - Linux users will now need to install libudev dev to build for any usb devices. - API muticast listener option --api-mcast so you can request all cgminer APIs on the local network to identify themselves on request - Also a new $mcast option in miner.php to automatically find all your cgminers that are using the --api-mcast option and related sample Java code MCast.java/MCast.class - New Icarus timing limit option for short and long timing, that can be set appropriately to ensure no device idle time if timing estimates the timeout badly - Bugfixes for numerous causes of corruption/crashes in stratum, usb, avalon and bflsc code. - Some rare errors in BFLSC messages were being ignored, they should now show up. - Fixed the broken OSX build from 3.4.0, but so many things were changed after that in the build process that it may be broken again. - Some hardware errors were being counted in diff1shares in avalon code leading to a mismatch of diff1 vs diffa+diffr. This has been corrected, but it will make the hardware error percentage look higher (though the actual amount will not have changed). - Maximum avalon frequency is now 1000 instead of 450 since some overclockers have pushed beyond 450. - Use higher resolution timers consistently on windows now.
Full changelog:
3.4.2: - take_queued_work_bymidstate should use a write lock. - miner.php coding warning - miner.php disable 'gen' by default - miner.php allow formula generation of new fields - miner.php add doctype - miner.php remove incorrect echo - miner.php optional error if not enough mcast rigs are found
3.4.1: - API mcast add a description option with miner.php - Always use a maxpacketsize buffer in usb_bulk_transfer - bflsc ensure getinfo cannot overflow its storage buffer - Don't decref json values in stratum parsing due to memory corruption. - Use 64 bytes for all libusb control transfers. - Skip dissecting opt->names in parse_config if it doesn't exist. - Use an internal buffer in _usb_transfer_read in case the read is larger than the buffer passed to it. - ICA optional limit timing with short=N or long=N - Revert to old custom tolines function since strtok_r is not portable. - bflsc remove unused commented out code - logging - code mistake - logging - applogsiz() for large messages - Provide base structures for getaddrinfo. - Include string.h in bflsc driver. - Get rid of linear removal of spaces in bflsc text parsing and use strstr throughout instead. - Use reentrant strtok in tolines() function in bflsc to avoid racing on contextless calls. - Show how small a too small result in bflsc is. - Duplicate the buffer in process_results in bflsc since strtok modifies it making debugging output limited to one line. - Only process nonces in bflsc if the breakdown function succeeds. - Ignore zero count messages in bflsc instead of trying to parse them. - Return ok in tolines when it doesn't match inprocess message for bflsc. - Remove inprocess line instead of deleting all following responses in bflsc. - Change ok testing logic in breakdown() in bflsc and return if not ok at any stage. - Check the return value of tolines in bflsc driver. - Use strtok to parse lines in bflsc driver. - Add libusb-1.0 m4 directory and gitignore file. - Properly convert from ranlib to lt_init in configure.ac - Make autoconf always build for libusb. - More autoconf fixes. - Unconditionally build jansson statically from the cgminer source tree. - Only test for all usb devices once in configure.ac - Fix various libusb warnings and possible bugs on linux build. - Add make clean and maintainer-clean to autogen - Remove examples from libusb Makefile and generated autoconf files. - Fix libusb subdirectory builds. - Remove cached files from libusb autoconf on running autogen.sh - Remove unused HAVE_LISBUSB macro and use USE_USBUTILS everywhere. - Use direct auto* files to avoid failure of autoreconf - Remove unused and maintainer cleaned files - Show RT_LIBS in ./configure output. - First import of libusb-1.0 - bflsc xlinkstr use snprintf - Fix win32 build. - Use take_queued_work_bymidstate in the bflsc driver to avoid the rare chance repeated results come back from the same work item. - Provide a function that looks up queued work by midstate and then removes it from the device hash database. - Fix no -rt library on darwin. - Update included jansson to v2.4 - Fix OSX build. - Provide an osx fix for cgtimers and a fallback to timevals for all other platforms !linux !win32 !osx. - Move two more timer functions out of define macros to enable them to be used by future osx code. - cgtimer_sub is now the same since cgtimer_t should be the same on all platforms. - miner.php fix missing global - Only count submitted nonces as diff1shares if they're valid. - Substantially raise the maximum avalon frequency for water-cooled, over-volted designs. - Compile MCast.java with an old java - API Multicast sample MCast.java+MCast.class - BTB show C/MHz/mV for device - api.c remove unused reply string - api.c fix mcast debug message bug - miner.php implement API Multicast handling to automatically find your local net miners - API mcast only reply to remote IP's that are allowed access - Initial API Multicast response v0.1 to find cgminer APIs - Use timespecs on windows as cgtimer_t to capitalise on the higher resolution clock changes. - Abstract out the conversion of system time to an lldiv_t in decimicroseconds. - Use our own gettimeofday implementation on windows for it to be consistent across ming builds and higher resolution.
|
|
|
I just fetched the latest CGMiner, and oh, god, what happened to the share logging? Please change it back.
If you mean A: and R: (and WU:) no it will not be changed back to displaying meaningless information ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif) It was very much meaningful information. It told me how many shares I have submitted. So let me get this straight, rather than have it tell you how much work you've done that the pool will reward you for, you want a variable on the screen from the cpu mining era of diff1 shares that today correlates with absolutely nothing at all unless you happen to mine on one of the last remaining pools that accepts diff1 shares, in which case the result is equal to what's shown in the current cgminer anyway?
|
|
|
i have
1x 7950 and 1x 7850
i need to set gpu-threads to 1 for my 7950 and i need to set gpu-threads to 2 for my 7850
but it seems like setting
-g 1,2
doesnt work?!?!
Correct, it doesn't. -g is a global setting.
|
|
|
Xian - what virus/firewall s/w do you use?
Microsoft Security Essentials. Have not run the debug build yet. I will on next crash. EDIT: 20GH/s rig crashed. Downloaded the cgminer.exe 3.4.0 debug build and started her up. Make sure to set up the debugger as described in the readme in that directory.
|
|
|
Have other pools lost interest in implementing reconnect support?
What pools do and what pools don't support it? As far as I'm aware, only eligius supports it. This is why I'm bringing it back up since it's not in the pool ops' interests to implement it but it is in the miners' interests. I see all the pool ops are doing an excellent job of ignoring this since most users are unaware of the lack of this support, so I'm reminding them to hopefully give this issue a higher profile.
|
|
|
Not sure if it will help.. Problem signature: Problem Event Name: APPCRASH Application Name: cgminer-nogpu.exe Application Version: 0.0.0.0 Application Timestamp: 5214a24a Fault Module Name: mswsock.dll Fault Module Version: 6.1.7601.17514 Fault Module Timestamp: 4ce7b8e8 Exception Code: c00000fd Exception Offset: 00006ae6 OS Version: 6.1.7601.2.1.0.768.3 Locale ID: 1033 Additional Information 1: 065d Additional Information 2: 065d6303ad9ca09b532367badb2eeeae Additional Information 3: 93ac Additional Information 4: 93acfaaf7fada805f2b80ed090bea700 Hmm doesn't even look like it's crashing in cgminer, but can't tell for sure. Possibly related? : https://community.mcafee.com/thread/36486
|
|
|
Any version that uses the new USB drivers eventually crashes on me with mwsock.dll causing the error under Windows ![Sad](https://bitcointalk.org/Smileys/default/sad.gif) Update - confirmed after today's crash, same DLL listed above.. I have a copy/paste of the WIN7 report if needed... haven't run the debug build yet.. doesnt look like Ill have time to tinker until next week... I think my latest run went a day and a half.. Hmm... but that's in the networking code, lemme look back at the changelog and see how that code might have been affected.
|
|
|
CGMiner seems to be randomly closing. I'm running cgminer-nogpu on Win 8x64 with a BFL Little Single and 2 AMUs. It runs in a batch file that loops, and the batch file keeps restarting it, so it is closing nicely, and I haven't lost any downtime. I think it's done it about 4-5 times since I updated to 3.4.0, which was about 8 days ago? The newest one was this morning, after I had left for work. It had been running for about 2 days solid before that.
It never did this before. The AMUs are pretty new. Is it the AMUs causing it, or upgrading to 3.4.0, or both?
Hard to know without excluding one thing at a time? Try running the AMUs in their own instance and see if one the other or both crashes? Also there are debug builds which would help me find out where it's crashing and fix it. http://ck.kolivas.org/apps/cgminer/debug/
|
|
|
Weird, -8 is an overflow error coming from libusb. Not sure if it's a libusb or operating system limitation. I'm quite sure I've seen others use a lot more than 50 in other threads, but not sure which particular operating system/hardware.
|
|
|
Surely most of you have been around long enough on these forums to know how reluctant the forum mods are to do anything that might be construed as supporting a manufacturer? Either you feel obliged to argue that point yet again that's been done to death, or you try and find them a solution that accepts it.
Yes this is why if I understand it right there would be a non-specific vendor section: "Vendor Customer Discussion". Yes, that's precisely why I suggested it. The titles may be different from my suggested ones, but a solution along those lines seems IMO to be the best compromise.
|
|
|
Surely most of you have been around long enough on these forums to know how reluctant the forum mods are to do anything that might be construed as supporting a manufacturer? Either you feel obliged to argue that point yet again that's been done to death, or you try and find them a solution that accepts it.
|
|
|
|