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

It's weird, because i was trying to use P2Pool and Bitparking... P2Pool was working some time ago with any kind of password, but now some pools of p2pool doesn't work if i put some kind of password.

Connecting via stratum, getwork or GBT ALWAYS takes a password, even if it is ignored, so your pool is broken.

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)

Thanks!

Try plugging the 3 10 port ankers into the 4 port device just for grins?

I had to plug my 9+1 Anker's into my 5/7 port Rosewill hubs to get them to work reliably.

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...

So... On an initial test of "sw" without logging, I noticed some LEDs come on for several seconds then go out, and mining continued OK.  Another time a zombie was reported but it re-plugged automatically. Then several zombies came up which did not re-plug automatically and I noticed "icarus detect - incorrect device" warnings.  I don't know if these are new with this build or not, but when they came up I did examine the whole table in Zadig to check if AMUs had been re-assigned to slots with incorrect driver software - but they all looked OK.

Powered the hubs off/on to reset everything as usual.
 
On this run (with logging), a zombie (AMU 22) appeared after about a minute, which did not re-plug automatically.  Manual re-plugging worked OK, but I stopped the test because I was going out and wanted to be sure
the miner would keep running.  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 don't see any of that with 3.5.1, and as I'm normally sitting right next to the Erupters working away at the PC, any unusual flashing immediately catches the eye.

Logfile here, for what it's worth:
  https://dl.dropboxusercontent.com/u/44240170/logfile-sw.txt

My most recent normal 3.8.4 test ran about 12 hours without incident - no zombies at all. I've just run the "sw" test and it has one zombie after about an hour, AMU5.

Edit: another zombie with the "sw" test, about 5 hours into the run. Curiously, this one was also reported as AMU5 although it wasn't the same physical device as above. Unplugging it did not change its status to AMU0, unlike many of the earlier versions. On replug it was reallocated to AMU14 and the numbering overall suggests it had actually been AMU7 that went zombie this time. Present numbering is AMU0-4, 6, 8-14 so I think the first zombie, AMU5, was reallocated to AMU13 on replug. The "sw" run continues.

I found an Amazon (Canada) listing for the hubs I'm using, fwiw: http://www.amazon.ca/gp/product/B009Z9M3DY

I just noticed this phrase in the blurb for them "Smart chip power management allows devices to communicate idle states and latency tolerance for progressively lower power states and subsequently increased performance and power efficiency". Don't know if it's relevant.

Found how this might happen. Try latest git please.

Compiled and ran 3.8.4 on Fedora 19.  It ran for 68 hours, before running out of file descriptors.  At that point, it can no longer replug zombies.  It could probably run indefinitely if those file descriptors could get closed somehow.   Next time, I'll remember to run lsof to see what all those file descriptors are referencing...

 [2013-12-06 22:25:29] SEM: Icarus USB open failed '/tmp/cgminer-usb-1-64' err (24) Too many open files

Another thing I thought of ... is there were multiple issues.  I think you fixed the ones affecting me, now I just have the USB 3.0 problem.

M

Ok, new experiment for the windows+amu fail:
http://ck.kolivas.org/apps/cgminer/temp/cgminer-sw.exe

Interesting. Perhaps the USB3 hubs that don't work have virtually no USB1.1 TTs, and yours going through a USB2 socket is basically sharing the one TT on the USB2 socket. Also some people with USB3 slots on windows can't even see their devices. I think linux has some kind of software TT to compensate within the kernel so perhaps the operating system is actually working around them.

I'm using two powered Anker USB 3.0 hubs daisy-chained and going to a mobo USB 2.0 socket. I think we all found out early on that USB 3.0 (blue) sockets don't work with the Eruptors but the hubs allegedly downgrade from 3.0 to 2.0 without hassle and I think a lot of people use them that way for mining. My other machine that tends always to have similar cgminer issues (but never the "dead" label) also uses an Anker USB 3.0 powered hub connected to a USB 2.0 socket.

The PC's own hubs also include transaction translators by the way.

It's a neat idea ... except I got zombies with the same hardware (same erupters, same hubs) that worked fine on another rig.  I'm down to 1 USB erupter, and it's happily chugging along at 335mh/s on main PC.

M

That means the command went out to the device and it got stuck somewhere in the operating system driver code (i.e. outside cgminer) and never returned.

Interestingly - and related - I've been doing some reading about usb hubs that don't have separate transaction translators for usb1.1 devices and wonder if all the flakiness isn't just dodgy hubs with a shared TT and all these usb devices being usb1.1. It's rather annoying that usb2 is a decade old and people are still making 1.1 devices because they can use the cheapest nastiest communication chip money can buy in their devices. What USB hub do you have? I don't even know if hubs are still made with single transaction translators any more or not, but it would be interesting to find out.

See this interesting and ancient comparison of a single TT hub to a multi TT hub:
http://www.tomshardware.com/reviews/usb-technology,677-3.html

I just encountered something a bit different in a 3.8.4 test (Win7 64). This run was uneventful except for an occasional zombie and I was mindlessly replugging them as they occurred and they always restarted. Eventually one did not restart and I found it was flagged in the display as "dead" rather than "zombie". I pressed Q and the LEDs came on for all the others as expected and the BAL fan shut down, suggesting that cgminer accepted the command, but cgminer itself did not shut down and appeared to have frozen. I killed it with a Windows "close window" command. On restart, everything looks normal and the formerly "dead" AMU device is now hashing as usual. I should read up on necromancy to prepare for the next one.

GPU support is not available for cgminer, and the authors only support the newest version of cgminer.

M

Is there any way to disable the 5min pool stability check that was introduced in 3.5.1? It's playing havoc with multi pools that auto switch to the most profitable coin periodically, as the switch interrupts the stratum for 15-20sec which invokes the 5min stability check.

cgminer will only recognize  one of my GPUs. Going on a suggestion from someone, I used the --no-adl argument. Now, it seems adl is permanently disabled. How can I re-enable it?