Your 404 page has a typo  : "No, this is not the page you are looking, this is Dog." |
|
|
|
Without a serious "weapon" like a Neptune (price ~ $12,000,000 ) you will be always outgunned as miner.
That's a lot of money. Gotta love zeroes. |
|
|
|
Started latest trial version of cgminer, renamed as cgminer-2013-12-08. The AMU LEDs initially all go off, then come back on again and it seems to take ages for all AMU LEDs to go out, then hash rates initially all show 150/ for a while, then 252/ ... afterwards increasing to the normal 335/ - see screenshots in logfile. I haven't seen this behaviour before! Test was left running overnight. When I came back this morning there were 6 zombies and a couple with zero hash rates, please see 2nd screenshot in logfile. Test stopped  Logfile here: https://dl.dropboxusercontent.com/u/44240170/logfile-2013-12-08.txtAlrighty, try the rc I posted next please then. |
|
|
|
My site (ck.kolivas.org) will be down for some scheduled maintenance for a few hours shortly.
Here's a windows release candidate for what I'm likely to release as a new version tomorrow in case people want something to play with before it goes down: http://ck.kolivas.org/apps/cgminer/temp/cgminer-rc.exeContains the TT fixes discussed earlier, and auto usb reset of devices that have failed comms. |
|
|
|
Finally got an error - AMIU 27 LED full on but no zombie reported. The hash rate is sitting at zero. Screenshot in logfile. I enabled debug for a while then tried manual re-plugging. Device appeared as zombie when removed, then when re-plugged it appeared as AMU 34. 2nd screenshot also in file. Test then ended. I'll try w2d10 next. Logfile here: https://dl.dropboxusercontent.com/u/44240170/logfile-w1d10.txtNote: Just started w2d10 and it does the same strange thing as w1d10 at startup - all AMU LEDs go off as normal, then they all come back on again. It takes a second or so for a few to go out, then it works a while with just those few, then the rest go out and mining continues with all devices. Note 2: I have a zombie AMU 10 already after only a a few minutes... Manually re-plugged as AMU 34. Test continuing. Try this one instead then please: http://ck.kolivas.org/apps/cgminer/temp/cgminer.exeMe too or shall I stay with w2d10 which is still clean, 11 hours in? You can stay on w2 thanks. |
|
|
|
Finally got an error - AMIU 27 LED full on but no zombie reported. The hash rate is sitting at zero. Screenshot in logfile. I enabled debug for a while then tried manual re-plugging. Device appeared as zombie when removed, then when re-plugged it appeared as AMU 34. 2nd screenshot also in file. Test then ended. I'll try w2d10 next. Logfile here: https://dl.dropboxusercontent.com/u/44240170/logfile-w1d10.txtNote: Just started w2d10 and it does the same strange thing as w1d10 at startup - all AMU LEDs go off as normal, then they all come back on again. It takes a second or so for a few to go out, then it works a while with just those few, then the rest go out and mining continues with all devices. Note 2: I have a zombie AMU 10 already after only a a few minutes... Manually re-plugged as AMU 34. Test continuing. Try this one instead then please: http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe |
|
|
|
The first one (w1d10) got one zombie during an unattended 12-hour run. It replugged with no problem. I'll try w2d10 now. "w1d10" has been mining for 3 hours now and no actual zombies yet, but it is behaving rather strangely. I am regularly getting "rafts" of LEDs coming on - perhaps 15 or more, then another 1,2,3.... 7,8 or so, making 17-25 all on at once, then they all go out and everything looks normal again. Nothing abnormal in the log file and my hash rate is ok at the pool. I would say this looks very promising - if it were not for the disconcerting appearance of seeing all those LEDs going on and off...!! Edit: Of course it could be my wonderful (not!) broadband playing up - but that typically results in *all* LEDs coming on for 5 seconds or so and then going off en-masse. What I'm seeing here happens perhaps once every 10, 15 or 30 minutes, and no "pool unavailable" messages. Thanks very much for that. I'm pretty sure this is the right track since kano confirms it fixes his 3 AMUs mining on a USB3 hub on his RPi which previously wouldn't work at all unless he daisy chained it via a USB2 one. I don't think the -rw* versions will need to be tested and it will be a matter of whether it's 1d10 or whether I need 2d10 to roll a double 0 ftw. |
|
|
|
Hope that will help new people transferring from bfgminer to cgminer  seeing cgminer no longer supports scrypt mining the transfers are probably in the other direction, as scrypt is very popular again with the rise in alt coin prices. That said I still prefer using cgminer. That's really quite funny and hypocritical given luke-Jr considers all altcoins scams yet he pulled my scrypt code and is now maintaining the only maintained scrypt GPU miner on these forums. |
|
|
|
Much appreciated, thanks! |
|
|
|
It seems that this version tries hard to keep things going, but I seem to be seeing more initial disturbances (LEDs on for a second or more then disappearing, then maybe a zombie which replugs automatically etc.)
I got a cluster of four (almost) simultaneous zombies and was going to make a routine post agreeing with your observation about clusters of LEDs on, when things got weird for me. On a lazy whim, I tried Q and restarting cgminer hoping it might cure all four zombies at once. It didn't, so I unplugged and replugged the hubs and everything seemed back to normal. The cgminer display showed all units hashing normally and the AMU LEDs and BAL fan all seemed normal. I looked at my stats on Slush's pool and was startled to see the "last share at" timer creeping upward. No work from this 'puter was registering at the pool. The cgminer display showed the pool connection normally. I looked at a few other things and waited to see if it would recover but it did not. After 14 minutes I quit and restarted cgminer and the counter at the pool site recovered immediately. I've never seen that happen before, but it looks like a potentially serious effect from something or other I did in a too-casual zombie recovery/restart. I suspect it's actually managing to crash the hub itself and the hub needs resetting. Ugly. |
|
|
|
Hi people, i've got a little problem. I want to mine in some places where putting no password is required... but i can't use CGMINER without a password. I can't execute without the -p parameter, i can't use -p xxx for example (it doesn't connect to pool or doesn't get any share), and also i can't use --username=user:
Somebody know how can i do it??? I tried lot of versions of CGMINER, including the last one compatible with GPU mining (3.7.2)
Connecting via stratum, getwork or GBT ALWAYS takes a password, even if it is ignored, so your pool is broken. |
|
|
|
|
With cgminer, list pools with the quota command in conjunction with --load-balance. See the included README for quota information in the section QUOTAS.
|
|
|
|
I am running 3 10-port Anker hubs and an old 4-port hub, all individually powered and plugged directly into the PC. No daisy-chaining. Interestingly I don't remember ever seeing one of the 4-port devices going zombie...
Try plugging the 3 10 port ankers into the 4 port device just for grins? |
|
|
|
lol
Hey SkyMinerLabs, there's this one missing on your site:
I think the black hole has been inadequately portrayed in the original. NSFW:  |
|
|
|
|
The actual model is well hidden (bastards). I tried modifying my own firstly with the top fans since they're "thin" fans and figured extra pressure full thickness fans would be better if they were open air and blowing down without the side 120mm fans (to be quieter overall). I discovered the originals were surprisingly high flow and higher pressure lower flow fans did not help one bit (they were actually worse). Then I tried high flow higher pressure and they didn't help either. I've been running them cover off with the top fans blowing up and only the one 120mm fan blowing into it (no pull fan) and that had the greatest effect on improving cooling but wasn't as dramatic as I would have hoped. Even blowing a gale over it, feeling the heatsink it's only ever warm, even when the device sensors are reading 80+ degrees on a stinking hot day here. My final conclusion is the heatpipes aren't dissipating the heat to the heatsink fast enough and blowing harder on the heatsinks was pointless. To get similar flow rate (but higher pressure) on the top fans, I ended up using adda fans that were .45A if that gives you a ballpark for how much current they're drawing, so I expect the 120mm fans are drawing a lot more than .1A.
|
|
|
|
|
500 reports with 99% accuracy.
|
|
|
|
Latest version of cgminer works fine with RPi and erupters without using ancient tty port settings. It should just autodetect them. Note that RPis can't drive USB3 hubs since they have no usb3 drivers so if yours is USB3, you're out of luck unless you put yet another usb2 hub between that hub and the Pi.
I just downloaded 3.8.1 from your github. I'm going to attempt it with that. I believe the USB hub is 2.0 as well. Why did you stop at 3.8.1? |
|
|
|
|
Latest version of cgminer works fine with RPi and erupters without using ancient tty port settings. It should just autodetect them. Note that RPis can't drive USB3 hubs since they have no usb3 drivers so if yours is USB3, you're out of luck unless you put yet another usb2 hub between that hub and the Pi.
|
|
|
|
|
Congratulations on being the 500th altcoin thread reported for being in the wrong place.
|
|
|
|
|
Show Posts
