When I start cgminer, my rejected shares is at 2048 before I connect to pool.
Benign event, okay to ignore if it's not continuous. Rejected shares will occur from time to time. Usually during startup and new block events. |
|
|
|
I saw that error and more all weekend... needs more power. I found that even running on the lowest mhz and voltage settings my miner would still die if I plugged more sticks in than can be powered. Getting work on fresh blocks would give me this error even on the lowest settings, because they were all firing up at the same time. These guys are thirsty.
But even when you are only running a single stick or two!? It seems that even if you were running them at 1.5V and 200Mhz most of the more powerful USB hubs should, in theory, be able to handle two sticks easily (~1.8A each). As I was running them yesterday, they should have only been drawing something like 0.75 Amps each, which should have been no problem. I mean, my phone draws more power than that. I've got one more hub to try. This one says it will support 2.5A per port, or a max of 14A. If this doesn't work then I don't know what to do. Three other variables worth looking at along the way that I haven't seen you mention: Try different pool. ( not likely with the symptom, but why not ) Remove usb fan (if connected) Switch PC |
|
|
|
Ok I just captured the tail end of it failing. So I'm going to go do a git pull now. It appears to get into some kind of write error for a while and kills the devices while in that error. screen shot below. This was after an hour of hashing.
...
*edit*
so i just got the zombie version of my cgminer failing. This was at 25mhz lol
...
The write err:(-7) LIBUSB_ERROR_TIMEOUT error is hinting at something down stream of the software. cable, hub, or miner. There is one similar reference I located here showing a similar symptom in a delayed fashion due to cabling. I don't know how well it applies here. Based on what BittyDave posted earlier today, issues with power over extension cable seems a potential place to look. |
|
|
|
So I got my 10 2pacs Friday and have been struggling to get them working with any consistency  I have tried at every speed from 25mhz - 250mhz and get the same result. It will hash for 1-3 hours and then either cgminer just quits or a random number of boards between 3-6 turn off or go zombie. It's never the same ones, cause I have been marking the ports and boards that stop working. It is completely random. Everything seems to be working fine for that first hour or so with the exception of an error that pops up occasionally on a random board that says No valid hashes recently, attempting to reset attempted reset got err:(0) LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED any ideas? screenshot below  also I have one stick that won't allow me to adjust the voltage. it just show .8v per asic and 1.6v total. Adjusting the pot has no affect. So I may pull that one to see if it's causing trouble. Also let's double check that you are on the latest build by doing a git pull. |
|
|
|
sudo ./cgminer -o stratum+tcp://us-east.stratum.slushpool.com:3333 -u ME --gekko-2pac-freq 250 [2017-03-05 00:44:43.189] Started cgminer 4.10.0 [2017-03-05 00:44:43.418] Probing for an alive pool [2017-03-05 00:44:43.559] Pool 0 difficulty changed to 2048 [2017-03-05 00:44:44.418] Network diff set to 461G [2017-03-05 00:44:45.430] found 2 chip(s) on GSD 0 [2017-03-05 00:44:45.430] GSD 0: set frequency: 250.00 [09 82] I have no hub in the mix. however I had a one meter USB extension cable. When I plug the stick directly into the port without the extension cable, it works.  Next to find out why it doesn't like the cable. David Glad to see the usb stick is responding now. Probably voltage loss (current x resistance), @ freq 250, you'll be pulling over 2 amps across the extension cable. I don't now where the thresholds would be, but sounds likely to be the culprit.  |
|
|
|
Hello everyone, newbie here.
I was wondering if anyone else was having issues with cgminer looping the "GSD X failure, disabling!" indefinitely when you try to run more than one 2Pac. I have been able to get up to 2 running simultaneously by plugging them in sequentially while cgminer is running, but any more than that and it ZOMBIEs the last one I plugged in and gives me the "failure" message over and over as it tries to find successive sticks.
Anyone seen this and/or figured out a cure? I would like to get more than one stick running at time!
Just for reference:
- I followed the instructions in this post to compile my own build (Windows) so it's current (and works just fine with the single stick)
- My USB hub is externally powered and I have tried multiple hubs and configurations - I don't think it's a power issue
- I've tried running each stick individually, so it's not a bad stick
Any help would be appreciated!
What is the hub you are using? I've tried on an Anker 10-port 60W 3.0 hub ( https://www.amazon.com/gp/product/B00VDVCQ84/ref=oh_aui_detailpage_o01_s00?ie=UTF8&psc=1) and on an Anker 7-port 2.0 hub ( https://www.amazon.com/gp/product/B00R5ZA20G/ref=oh_aui_detailpage_o05_s00?ie=UTF8&psc=1). But I've also tried just plugging two into my computer directly and I have the same issue. Check out this note by NotFuzzyWarm on the hub thread: https://bitcointalk.org/index.php?topic=1779423.msg17921042#msg17921042Perhaps the hub internal layout are similar? |
|
|
|
Thank you, I tried without the arguments, no difference. I only have one "stick" when it doesn't get a response on 0 it tries 1 then 2 ...
Cool. Once you are down to one stick with the default setting, unplug it wait 2 seconds and plug it back in. See if you can spot the line below: "found 2 chip(s) on GSD 0" "GSD 0: set frequency: 100.00 [07 83]" I get the same results with or without the arguments. I've even rebooted the box. sudo ./cgminer -o stratum+tcp://us-east.stratum.slushpool.com:3333 -u MY_USERNAME [2017-03-04 23:57:54.410] Started cgminer 4.10.0 [2017-03-04 23:57:54.641] Probing for an alive pool [2017-03-04 23:57:54.766] Pool 0 difficulty changed to 2048 [2017-03-04 23:57:55.643] Network diff set to 461G [2017-03-04 23:57:56.650] found 0 chip(s) on GSD 0 [2017-03-04 23:57:56.650] GSD 0: set frequency: 100.00 [07 83] The initial priority is to try to get that 0 chip(s) to show as 2 chip(s). Need to unplug and replug, a reboot won't drop the port voltage need to reset the buck tripped from the 250 frequency attempt. Assuming you did the full unplug sequence, one last thing I can think of for you to try: "sudo ./cgminer -o stratum+tcp://us-east.stratum.slushpool.com:3333 -u MY_USERNAME --gekko-2pac-freq 25" *note the missing zero (25 not 250) is intentional. Unplug the usb stick, wait 2 second, and replug. (also try this directly to the machine at the frequency of 25, if a hub is in the mix) And paste the same log you just captured. |
|
|
|
Thank you, I tried without the arguments, no difference. I only have one "stick" when it doesn't get a response on 0 it tries 1 then 2 ...
Cool. Once you are down to one stick with the default setting, unplug it wait 2 seconds and plug it back in. See if you can spot the line below: "found 2 chip(s) on GSD 0" "GSD 0: set frequency: 100.00 [07 83]" |
|
|
|
Hello everyone, newbie here.
I was wondering if anyone else was having issues with cgminer looping the "GSD X failure, disabling!" indefinitely when you try to run more than one 2Pac. I have been able to get up to 2 running simultaneously by plugging them in sequentially while cgminer is running, but any more than that and it ZOMBIEs the last one I plugged in and gives me the "failure" message over and over as it tries to find successive sticks.
Anyone seen this and/or figured out a cure? I would like to get more than one stick running at time!
Just for reference:
- I followed the instructions in this post to compile my own build (Windows) so it's current (and works just fine with the single stick)
- My USB hub is externally powered and I have tried multiple hubs and configurations - I don't think it's a power issue
- I've tried running each stick individually, so it's not a bad stick
Any help would be appreciated!
What is the hub you are using? |
|
|
|
I did the install as per the instructions for an Ubuntu 16.04.1 LTS new install. When I enter "sudo ./cgminer -o stratum+tcp://us-east.stratum.slushpool.com:3333 -u MY_USERNAME --gekko-2pac-freq 250" on the command line I get [2017-03-04 19:13:40.810] GSD 0 (5s):0.000 (avg):0.000h/s | A:0 R:0 HW:0 WU:0.0/m
[2017-03-04 19:13:40.810] GSD 1 (5s):0.000 (avg):0.000h/s | A:0 R:0 HW:0 WU:0.0/m
[2017-03-04 19:13:40.810] GSD 2 (5s):0.000 (avg):0.000h/s | A:0 R:0 HW:0 WU:0.0/m The interesting thing is that it does not say it does not recognize the argument entered. It's almost as if it doesn't see the USB erupter. Any ideas? Thanks. BTCFreq 250 with 3 sticks seems a bit ambitious power wise, as a start point, but I can't tell how you ended up there from the info posted. Start with one stick without "--gekko-2pac-freq 250" and work in more sticks. Post a little more detail, ideally starting from log line "Started cgminer 4.10.0". |
|
|
|
Howdy- wanted to say awesome work! I love the Compac, just got my 4 2Pacs- Any tips for running them in Minera? I have a RPi 3 with the newest ISO on it, runs the old Compac great, can't seem to get it to work with the new 2pac- I am that guy that sucks at Linux but can get it done with a little help  Cheers From first glance at the minera notes, looks like you can temporarily get away with updating the git path and add --enable-gekko in: /var/www/minera/build_miner.sh Try the raspbian image with the raspbian build instruction on the first post as a simpler exercise to understand what needs doing. |
|
|
|
I'm having a problem with the Windows binary of CGMiner in regards to Hotplugging. I have set the Hotplug interval from 5-30 second time intervals, but if/when a compac fails, CGMiner is not even attempting to restart the stick - it just leaves it off & displays it as "Off". Anyone else having this problem or is it just me?
A bit more info if this is something VH can fix: I am running 3 compacs (using 2 male-1 female USB "Y" splitters for extra power) at 350MHz with a powerful hub & excessive cooling. Occasionally, 1 of the compacs will randomly turn off/shutdown. If that happened using my previous CGMiner, the Hotplug setting would have turned the stick back on (or at least try until it did). Using your latest Windows binary (4.10.0-windows-gekko-214f9e6), if a stick shuts down, CGMiner leaves it off without attempting to hotplug/restart it. If I manually go into [U.]SB Settings & then use the [U.]nplug to allow hotplug restart command, the stick turns right back on. It will then stay running for days & then I might find a different compac has shutdown & remained off. I generally set hotplug to 10 seconds, but have tried 5-30 second times to see if that would fix it, but it has not.
In summary, it seems as if something is wrong with the [H]otplug command/setting in CGMiner, but I'm not sure where the root of problem resides. Other than that, VH's latest CGMiner release has my compacs running better than ever & I could NOT be happier. Thanks VH!
same issue as yours. i just lowered the freq powered off the cgminer started cgminer and the issue stopped. My guess is the off setting is the program telling you you are too hot or your hub does not provide enough power. +1 I found one scenario where pulling high amp across tiny 26AWG cables causes a drop in input voltage and triggers the chips to go "no thanks". Symptom: In the logs it will show "found 0 chip(s)". Here a reduction in frequency and physical unplug (wait a few sec) and re-insert will bring it back to normal. |
|
|
|
I'm having a problem with the Windows binary of CGMiner in regards to Hotplugging. I have set the Hotplug interval from 5-30 second time intervals, but if/when a compac fails, CGMiner is not even attempting to restart the stick - it just leaves it off & displays it as "Off". Anyone else having this problem or is it just me?
A bit more info if this is something VH can fix: I am running 3 compacs (using 2 male-1 female USB "Y" splitters for extra power) at 350MHz with a powerful hub & excessive cooling. Occasionally, 1 of the compacs will randomly turn off/shutdown. If that happened using my previous CGMiner, the Hotplug setting would have turned the stick back on (or at least try until it did). Using your latest Windows binary (4.10.0-windows-gekko-214f9e6), if a stick shuts down, CGMiner leaves it off without attempting to hotplug/restart it. If I manually go into [U.]SB Settings & then use the [U.]nplug to allow hotplug restart command, the stick turns right back on. It will then stay running for days & then I might find a different compac has shutdown & remained off. I generally set hotplug to 10 seconds, but have tried 5-30 second times to see if that would fix it, but it has not.
In summary, it seems as if something is wrong with the [H]otplug command/setting in CGMiner, but I'm not sure where the root of problem resides. Other than that, VH's latest CGMiner release has my compacs running better than ever & I could NOT be happier. Thanks VH!
Here you go. http://23.108.83.14/images/cgminer-4.10.0-windows-gekko-42b083f.7zThis should now produce the behavior you're looking for. |
|
|
|
I'm having a problem with the Windows binary of CGMiner in regards to Hotplugging. I have set the Hotplug interval from 5-30 second time intervals, but if/when a compac fails, CGMiner is not even attempting to restart the stick - it just leaves it off & displays it as "Off". Anyone else having this problem or is it just me?
A bit more info if this is something VH can fix: I am running 3 compacs (using 2 male-1 female USB "Y" splitters for extra power) at 350MHz with a powerful hub & excessive cooling. Occasionally, 1 of the compacs will randomly turn off/shutdown. If that happened using my previous CGMiner, the Hotplug setting would have turned the stick back on (or at least try until it did). Using your latest Windows binary (4.10.0-windows-gekko-214f9e6), if a stick shuts down, CGMiner leaves it off without attempting to hotplug/restart it. If I manually go into [U.]SB Settings & then use the [U.]nplug to allow hotplug restart command, the stick turns right back on. It will then stay running for days & then I might find a different compac has shutdown & remained off. I generally set hotplug to 10 seconds, but have tried 5-30 second times to see if that would fix it, but it has not.
In summary, it seems as if something is wrong with the [H]otplug command/setting in CGMiner, but I'm not sure where the root of problem resides. Other than that, VH's latest CGMiner release has my compacs running better than ever & I could NOT be happier. Thanks VH!
I probably missed a step to simulate an unplug on error detection. Shouldn't be a problem to recreate that effect. Whether it will come back to life after that software based sequence is a different issue. |
|
|
|
Time for a git pull and build. Cleaned up some lower frequency handling. http://23.108.83.14/images/cgminer-4.10.0-windows-gekko-214f9e6.7zTry to keep with the latest build, if possible, at this early stage to keep the sticks happier. Also, here is a quick reference chart for power planning.  The stick has worked in its default settings on every system I've plugged it into so far, but you can lower the frequency if you suspect a current issue. |
|
|
|
... The only time I've ever seen "share above target" was on VH's cgminer fork when mining at ckpool.
Back in december (coincidental timing), -ck changed the starting diff of solo.ckpool.org to 4000. Somewhere between cgminer startup and settling at the suggested-diff, some low diff shares make it through where submitted nonce is > suggested-diff, < 4000, and you get a few of these messages. |
|
|
|
I just purchased and installed this miner and I've gotten it to run in cgminer, however trying to mine only ever creates rejected shares with the description "Share above target". I'm completely new to cgminer (and to Bitcoin mining in general, I've been dabbling in GUI mining with Nicehash) and am totally baffled as to why this is happening or what to do about it. I've tested multiple mining pools and they all produce the same result.
"share above target" - reject the message is the pool saying I don't want what you submitted. the pool and the mining software negotiates and settle at a minimum difficulty level at start-up. for now, ignore the first hand full of these messages. no accepted shares - if your WU value is above 0, then you just need to wait until it finds a nonce with diff above what the pool is asking for. i would assume WU is above 0 as your software tried to submit low diff shares. most pools will eventually start asking less of you while you are connected (can take a while) some pools will let you set a value for your miner in there interface. on cgminer, you can tag a suggested diff to try to use during startup negotiating. --suggest-diff 32 |
|
|
|
|
Show Posts
