Download zadig which will allow you to associate your devices with the winusb driver to allow cgminer to mine with them: http://ck.kolivas.org/apps/cgminer/zadig/Make sure to only associate your mining device with WinUSB, not any other usb devices. After I do this they become completely undetected. And upgrade to cgminer 3.2.1 |
|
|
|
Download zadig which will allow you to associate your devices with the winusb driver to allow cgminer to mine with them: http://ck.kolivas.org/apps/cgminer/zadig/Make sure to only associate your mining device with WinUSB, not any other usb devices. |
|
|
|
Anyone had any luck on running lots of units on USB 3.0 vs 2.0? I wonder if a native implementation of USB 3.0 in a miner would reduce latency? We don't really need the bandwidth, IIRC, but lower latencies might help in a system with 100+ 50GH/s USB miners. The mining device latencies themselves are many orders of magnitude larger than the usb latencies so going to usb3 would achieve nothing. It will not be a rate limiting thing even with 1000 devices. |
|
|
|
Zanatos, I did download from the BFL site. I didn't understand how to install it but I checked versions and it is the same version I have installed. Cgminer-2.10.5 is working fine so I don't understand why the new one is not working for me.
Read the readme THAT COMES WITH THE VERSION YOU HAVE. It clearly says when you're starting that it needs a WinUSB driver, but you have the FTDI driver installed. |
|
|
|
Works fine and is more efficient than running separate instances. Here's mine running a GPU+FGPA+ASIC: cgminer version 3.2.1 - Started: [2013-06-11 06:34:25]
--------------------------------------------------------------------------------
(5s):6.701G (avg):6.806Gh/s | A:3437 R:3 HW:0 U:23.5/m WU:95.9/m
ST: 1 SS: 2 NB: 11 LW: 15589 GF: 0 RF: 0
Connected to au.ozco.in diff 4 with stratum as user
Block: 001be5184832ccbd... Diff:15.6M Started: [08:52:15] Best share: 9.34K
--------------------------------------------------------------------------------
[P]ool management [G]PU management [ S]ettings [D]isplay options [Q]uit
GPU 0: 72.0C 3517RPM | 717.5M/717.5Mh/s | A: 401 R:0 HW:0 U: 2.74/m I: 9
BLT 0: | 396.6M/398.8Mh/s | A: 180 R:0 HW:0 U: 1.23/m
BAJ 0: max 42C 3.42V | 5.521G/5.691Gh/s | A:2856 R:3 HW:0 U: 19.51/m
--------------------------------------------------------------------------------
[2013-06-11 08:57:35] Accepted 3d0aba5c Diff 4/4 BAJ 0 pool 0 |
|
|
|
I am solo mining LTC on my rigs, and have them pointing to a wallet on my LAN. When I added a failover pool (Coinotron), it picks up updates from that pool, and all new blocks come across as: "Stratum from Pool 1 Detected New Block" Instead of the expected solo: "New Block Detected"
I also get "Stratum Connection to Pool 1 Interrupted" and "Pool 1 Difficulty Changed to xxx" messages frequently.
It doesn't appear to impact me as I still find my solo blocks, but I'm wondering if I need to change back to just solo with no failover, so it doesn't keep wandering over to my failover pool to see what is going on there. Is this normal behavior? Does it take away any performance by checking both my local wallet and the pool? Thanks in advance for any advice!
This is intentional and advantageous for solo miners. |
|
|
|
Okay, clearly I am missing something. I have my Jalapeno plugged directly into my rpi. Should I not be doing that in order to get cgminer to recognize it? I am running it headless, just my rpi with my jalapeno plugged into it and using putty for anything, not using a keyboard. So, maybe I missed something. I have a USB 2.0 hub I could use if that for some reason solves the problem.
https://bitcointalk.org/index.php?topic=28402.msg2409598#msg2409598Try increasing the timeout and recompiling. Some jalepenos appear to be taking >850 ms to respond to the initial getinfo request in linux. There's a change that directly addresses this already in git master, so compiling from git master should do it. |
|
|
|
As far as I know Reaper is the only mining app that requires a lot of ram.
My 6x 7970s with cgminer use 325MB of system ram. This is on a system that currently has 16GB of ram.
Cgminer itself does not use lots of ram indeed, however you DO need that large amount of ram just to create the buffers to speak to the GPU, even if they don't show up as used ram. |
|
|
|
Lets face it, BTC is going to die sooner or later for GPU miners. As a few have said, anything SHA based is pretty much stuffed.
Then scrypt will face similar problems with the increase of GPU miners switching, difficulty will increase making it harder for small time miners to stay in. Only the heavy hitters will stay afloat.
The surprise for scrypt miners will come when mining scrypt is not profitable either. Who would trade ASIC earned BTC for GPU earned LTC at an effective loss? Yes I do believe the LTC economy is just an accessory to the BTC economy and can't stand up on its own right. |
|
|
|
Yes, to bypass one layer between cgminer and the device, and give us more control over it. It has allowed us to shave a lot of CPU off by doing so. It is unfortunately a lot more work, and keeps revealing to us interesting hardware limitations that the drivers paper over, but that is often the case that the better solution takes more effort.
Has anyone gotten this to work with the Anker USB 3.0 10-port hub? I tried it with cgminer 3.2.1, and it crashed shortly after starting. Does not currently work off USB3 ports on cgminer 3.2+. We are investigating. |
|
|
|
Yeah, I get this error when I try to run in cgminer 3.2 or 3.2.1: cgminer: -S: unrecognized option I built using --enable-icarus Because as the release notes say, and numerous other forum posts, you no longer use -S |
|
|
|
|
Maybe post in the meta section?
|
|
|
|
Okay, clearly I am missing something. I have my Jalapeno plugged directly into my rpi. Should I not be doing that in order to get cgminer to recognize it? I am running it headless, just my rpi with my jalapeno plugged into it and using putty for anything, not using a keyboard. So, maybe I missed something. I have a USB 2.0 hub I could use if that for some reason solves the problem.
I don't have an rpi so can only offer generic advice, but I have seen many many reports saying the rpi usb ports are flaky and putting a reliable powered usb hub between the rpi and the devices fixes them, so it's worth a shot. |
|
|
|
Yeah, give it to Cklovias. Or buy him a gold plated keyboard. For the low resistance to programing.  LOL I gave him the 10BTC since the donation from BFL was to "cgminer" and not "ckolivas" and he's a significant part of the team. |
|
|
|
I'm experiencing a issue with CGminer.
I recently moved my XFX 6870 from my gaming machine which was used to mine when I wasn't gaming to my first rig. I keep getting error's from windows saying it had to stop the program from running.
MoBo: msi x58A-GD45
Proc: I7 920
Memory : 2GB
Video Card: 6870 XFX HD - CCC Version - 13.4 Direct3D Version 9.14.10.0969
Not entirely sure what the problem could be. I've tried running as admin. Any help? Thanks!
I had same problem with incompatible OpenCL driver combination... Changing it might help In event log, I'm getting this error - - System - Provider [ Name] Application Error - EventID 1000 [ Qualifiers] 0 Level 2 Task 100 Keywords 0x80000000000000 - TimeCreated [ SystemTime] 2013-06-07T14:03:10.000000000Z EventRecordID 1752 Channel Application Computer Miner1-PC Security - EventData cgminer.exe 0.0.0.0 518e20db cgminer.exe 0.0.0.0 518e20db c0000005 000265be 12a0 01ce6387bbccda57 C:\Users\Miner1\Desktop\cgminer\cgminer-3.1.1-windows\cgminer.exe C:\Users\Miner1\Desktop\cgminer\cgminer-3.1.1-windows\cgminer.exe fc31de57-cf7a-11e2-8d68-6c626de9cc51 Any help on this. Google is saying that some of these error's happen when the Proc trys to access "No-Mans Land" in the memory. It's pretty much a dump spot. Any advice? Anyone have any direction with this? Still need help. Driver + SDK. Use a clean uninstaller and start again... as it says in the GPU README. |
|
|
|
With cgminer 3.2.1 I get a BSOD when I close & restart cgminer 2 or 3 times during the same Windows session. Never happened with 3.1.0 .The BSOD occured while initializing cgminer (screen stops responding and then the Blue Screen of Death).
My setup is a Core2 Quad Q6600 with 2x5850 in Crossfire, and Win 7 x64 with Catalyst 3.14 and the following config file:
Hope you can fix this possible bug. Thanks!
A BSOD is an operating system bug. You expect us to fix windows? |
|
|
|
3.1.1 and 3.2.1 are running my i5-3350P at 80% CPU. 3 GPUs (7850, 7950, 6970). Eventually locks up the machine, solid. Was OK with 2.11.4. Running 7x64 with 12.8 drivers.
That's driver and sdk related, nothing to do with cgminer - it caches bin files generated the first time you run it and will run the same ever more on that cgminer even if you change drivers, so you almost certainly changed drivers between cgminer versions. |
|
|
|
What level of CPU usage are people getting using CGMiner 3.1.1?
I've got a Win7 x64 setup with a Core i7-3570k and getting about 25% CPU usage, hashing with just one USB Block Erupter.
Hence why we have direct USB in the new code... it uses a lot less CPU because the ftdi driver is very inefficient. |
|
|
|
|
Show Posts
