|
Hope this pool pays out to everyone before closing totally, if it is closing anyway. Still have a few change stuck there from the days I used to mine on the pool.
|
|
|
|
Minera with MobileMiner is working very nicely. This last version of Minera is also very stable. Thanks for the constant updates  |
|
|
|
Explorer's dev said he is working on fixing it |
|
|
|
Hello guys, so with the latest commit (not version, commit), Minera should work fine with lot of large data too (I mean with many G-Blades connected). This isn't definitely confirmed yet (I had only one confirmation) but if you had problems with many G-Blades, you should give a try to the latest commit: cd /var/www/minera
sudo git fetch --all
sudo git reset --hard origin/master
sudo ./upgrade_minera.sh I would like to thank Sandor so much, he did the PHP patch to get this working, so the beer goes to him this round! ( https://github.com/siklon/cpuminer-gc3355) PS @unamis76 you should definitely look at the cpuminer.log to understand what's happening on your env (a good try it's also run the command directly into the terminal without the screen options) What should I look for in the log? It seems a perfectly normal log, no errors, nothing, it just ends abruptly when it hangs while setting frequencies or it just says it's hashing, but doesn't show anything accepted. |
|
|
|
Not to mention the fact the development cycle is crazy fast and responsive. Michelem and Sandor make quite the team This is quite the fact. My bet is that Minera will be perfect very soon for everyone. |
|
|
|
Minera is indeed very good, but it's still very unstable, and has been like so in the last versions. Things I've been noticing:
1. If I save new settings and restart, minerd hangs randomly, while setting chip frequencies
2. Also, when I save new settings and restart, it sometimes starts hashing but does not accept any shares
(to solve all of the above I have to restart several times till it works)
3. when I add 3 or more pools, it gives errors similar to 1 and 2, and the only workaround is to remove those pools from the config
4. Pool switcher rarely works
Anyone experiencing the same? Any workarounds?
the miner hanging when you set saved frequencies is a known problem the other stuff seems to be a feature of cpuminer that or duff usb hubs (mine seem fine since I ditched the cheapo ones) a reboot is the best bet. Oh and I have had little success with my 40 chip blades which seem to hang with minera if it's blades you are using use hashra or a as I have low power netbook and bgminer I never used the save frequency setting on Minera, I already knew what frequencies to use when I installed Minera. But yes, I do put specific frequencies on my settings, that's a problem? This is just a test system, it's as simple as it gets. It only has one raspberry and one Gridseed 5 chip, unmodded, so no stress with usb hubs. Rebooting doesn't solve. And yes, this is a fresh install. I've seen what's up with blades and Minera, so not using those with it, thanks for the heads up. I guess I'll switch back to SSH control for now. |
|
|
|
|
Minera is indeed very good, but it's still very unstable, and has been like so in the last versions. Things I've been noticing:
1. If I save new settings and restart, minerd hangs randomly, while setting chip frequencies
2. Also, when I save new settings and restart, it sometimes starts hashing but does not accept any shares
(to solve all of the above I have to restart several times till it works)
3. when I add 3 or more pools, it gives errors similar to 1 and 2, and the only workaround is to remove those pools from the config
4. Pool switcher rarely works
Anyone experiencing the same? Any workarounds?
|
|
|
|
Anyone trying to mine at BetaRigs with this distro? Keep getting this error: stratum_recv_line failed when trying either of these two pools: stratum+tcp://r3026.g63.rigs.eu.betarigs.com:6192 http://eu.betarigs.com:3333No shares attempted at all... These work just fine in my cgminer instances, but this is the first time I've used cpuminer. EDIT: I enabled debug mode, but it didn't give me much more info... https://i.imgur.com/qOENVdR.pngIs your rig rented out when this happens? Mine will do that as well when the rig is not rented. Once someone rents it, the pool becomes alive and cpuminer switches over to it after a few minutes. Yes, it is. EDIT: Would you mind posting your config file? Maybe there's some small difference... Sure, here it is, very basic {
"gc3355-detect": true,
"freq": "1200",
"log": "\/var\/log\/minera\/cpuminer.log",
"debug": true,
"pools": [
{
"url": "stratum+tcp:\/\/r3753.g90.rigs.eu.betarigs.com:6801",
"user": "toxic0n",
"pass": "x"
},
{
"url": "stratum+tcp:\/\/stratum.nicehash.com:3333",
"user": "1ToxicssQH8c8v2XZKboryudYrvPy775z",
"pass": "p=3.3"
},
{
"url": "stratum+tcp:\/\/uswest.wafflepool.com:3333",
"user": "1ToxicssQH8c8v2XZKboryudYrvPy775z",
"pass": "x"
},
{
"url": "stratum+tcp:\/\/sf.clevermining.com:3333",
"user": "1ToxicssQH8c8v2XZKboryudYrvPy775z",
"pass": "x"
}
]
}Having a similar problem, but with Hashcows. No errors on my config, also a very simple file. Any workaround? |
|
|
|
Once again formatted my test SD to use with my testing rig, this time with Minera+cpuminer. I've been having the following problem: [2014-05-20 17:48:24.4423] 0: GC3355 chip mining thread started, in SINGLE mode
[2014-05-20 17:48:24.4438] Starting Stratum on stratum+tcp://stratum01.hashco.ws:8888
[2014-05-20 17:48:24.4448] 0: Open device /dev/ttyACM0
[2014-05-20 17:48:24.4903] 0: Resetting GC3355 chips
[2014-05-20 17:48:24.7365] Failed to get Stratum session id
[2014-05-20 17:48:24.7386] Stratum difficulty set to 64
[2014-05-20 17:48:24.7998] Stratum detected new block
[2014-05-20 17:48:24.8012] New Job_id: 6567 Diff: 64 Work_id: 956839ab
[2014-05-20 17:48:25.6872] 0: Firmware version: 0x13011401
[2014-05-20 17:48:25.6886] 0: GC3355 5-chip USB-Mini Miner detected
[2014-05-20 17:48:25.7003] 0@0: Set GC3355 core frequency to 850Mhz
[2014-05-20 17:48:25.7122] 0@1: Set GC3355 core frequency to 875Mhz
[2014-05-20 17:48:25.7239] 0@2: Set GC3355 core frequency to 850Mhz
[2014-05-20 17:48:25.7355] 0@3: Set GC3355 core frequency to 825Mhz
[2014-05-20 17:48:25.7478] 0@4: Set GC3355 core frequency to 850Mhz
[2014-05-20 17:48:25.7495] 0: Resetting GC3355 chips
[2014-05-20 17:48:25.8520] 0: Dispatching new work to GC3355 cores (0x956839ab)
[2014-05-20 17:48:27.1248] API: Client 127.0.0.1 connected
[2014-05-20 17:48:28.5406] API: Client 127.0.0.1 connected
[2014-05-20 17:48:28.6433] API: Client 127.0.0.1 connected
[2014-05-20 17:48:28.6459] API: GET: stats
[2014-05-20 17:48:34.5482] Stratum detected new block
[2014-05-20 17:48:34.5544] New Job_id: 279f Diff: 64 Work_id: 95726803
[2014-05-20 17:48:34.6468] 0: Resetting GC3355 chips
[2014-05-20 17:48:34.7502] 0: Dispatching new work to GC3355 cores (0x95726803)
[2014-05-20 17:48:44.8467] 0@1 875MHz: Got nonce 333e9bed, Hash <= Htarget! (0x95726803) 74.1 KH/s
[2014-05-20 17:48:44.9113] Accepted 333e9bed GSD 0@1
[2014-05-20 17:49:00.0282] 0@3 825MHz: Got nonce 99b48f05, Hash <= Htarget! (0x95726803) 69.9 KH/s
[2014-05-20 17:49:00.0914] Accepted 99b48f05 GSD 0@3
[2014-05-20 17:49:01.7613] 0@1 875MHz: Got nonce 3351c299, Hash <= Htarget! (0x95726803) 74.2 KH/s
[2014-05-20 17:49:01.8270] Accepted 3351c299 GSD 0@1
[2014-05-20 17:49:05.6778] 0@0 850MHz: Got nonce 0021ff21, Hash <= Htarget! (0x95726803) 72.0 KH/s
[2014-05-20 17:49:05.7431] Accepted 0021ff21 GSD 0@0
[2014-05-20 17:49:09.4791] 0@2 850MHz: Got nonce 668c9295, Hash <= Htarget! (0x95726803) 72.0 KH/s
[2014-05-20 17:49:09.5431] Accepted 668c9295 GSD 0@2
[2014-05-20 17:49:19.5573] Stratum detected new block
[2014-05-20 17:49:19.5601] New Job_id: 349b Diff: 64 Work_id: 959f8bd2
[2014-05-20 17:49:19.5768] 0: Resetting GC3355 chips
[2014-05-20 17:49:19.6803] 0: Dispatching new work to GC3355 cores (0x959f8bd2)
[2014-05-20 17:49:29.4630] API: Client 127.0.0.1 connected
[2014-05-20 17:49:29.5662] API: Client 127.0.0.1 connected
[2014-05-20 17:49:29.5697] API: GET: stats
[2014-05-20 17:49:39.2200] 0@2 850MHz: Got nonce 667bde30, Hash <= Htarget! (0x959f8bd2) 72.0 KH/s
[2014-05-20 17:49:39.2833] Accepted 667bde30 GSD 0@2
[2014-05-20 17:49:54.9976] Stratum detected new block
[2014-05-20 17:49:54.9994] New Job_id: 41a4 Diff: 64 Work_id: 95c23fa8
[2014-05-20 17:49:55.0168] 0: Resetting GC3355 chips
[2014-05-20 17:49:55.1193] 0: Dispatching new work to GC3355 cores (0x95c23fa8)
[2014-05-20 17:50:01.8325] API: Client 127.0.0.1 connected
[2014-05-20 17:50:01.9347] API: Client 127.0.0.1 connected
[2014-05-20 17:50:02.0369] API: Client 127.0.0.1 connected
[2014-05-20 17:50:02.0453] API: GET: stats
[2014-05-20 17:50:15.2105] 0@2 850MHz: Got nonce 667c7965, Hash <= Htarget! (0x95c23fa8) 72.0 KH/s
[2014-05-20 17:50:15.2749] Accepted 667c7965 GSD 0@2
[2014-05-20 17:50:17.2068] 0@4 850MHz: Got nonce cce5107c, Hash <= Htarget! (0x95c23fa8) 72.0 KH/s
[2014-05-20 17:50:17.3393] Accepted cce5107c GSD 0@4
[2014-05-20 17:50:25.8266] 0@0 850MHz: Got nonce 0021c104, Hash <= Htarget! (0x95c23fa8) 72.0 KH/s
[2014-05-20 17:50:25.8916] Accepted 0021c104 GSD 0@0
[2014-05-20 17:50:29.8940] API: Client 127.0.0.1 connected
[2014-05-20 17:50:29.9962] API: Client 127.0.0.1 connected
[2014-05-20 17:50:29.9986] API: GET: stats
[2014-05-20 17:50:34.7655] 0@0 850MHz: Got nonce 002b95ce, Hash <= Htarget! (0x95c23fa8) 72.1 KH/s
[2014-05-20 17:50:34.8294] Accepted 002b95ce GSD 0@0
[2014-05-20 17:50:37.9488] Stratum detected new block
[2014-05-20 17:50:38.2721] New Job_id: 4ec7 Diff: 64 Work_id: 95ee26a3
[2014-05-20 17:50:37.2739] 0: Resetting GC3355 chips
[2014-05-20 17:50:38.2767] New Job_id: 5bc1 Diff: 64 Work_id: 95ee26a3
[2014-05-20 17:50:38.3774] 0: Dispatching new work to GC3355 cores (0x95ee26a3)
[2014-05-20 17:50:43.2940] Stratum detected new block
[2014-05-20 17:50:43.3014] New Job_id: 68be Diff: 64 Work_id: 95f39903
[2014-05-20 17:50:43.3768] 0: Resetting GC3355 chips
[2014-05-20 17:50:43.4793] 0: Dispatching new work to GC3355 cores (0x95f39903)
[2014-05-20 17:50:49.3511] Stratum detected new block
[2014-05-20 17:50:49.3529] New Job_id: 75bd Diff: 64 Work_id: 95f9626d
[2014-05-20 17:50:49.3768] 0: Resetting GC3355 chips
[2014-05-20 17:50:49.4792] 0: Dispatching new work to GC3355 cores (0x95f9626d)
[2014-05-20 17:51:03.2658] Stratum detected new block
[2014-05-20 17:51:03.2677] New Job_id: 82c7 Diff: 64 Work_id: 96071580
[2014-05-20 17:51:03.2769] 0: Resetting GC3355 chips
[2014-05-20 17:51:03.3793] 0: Dispatching new work to GC3355 cores (0x96071580)
[2014-05-20 17:51:30.0950] API: Client 127.0.0.1 connected
[2014-05-20 17:51:30.1974] API: Client 127.0.0.1 connected
[2014-05-20 17:51:30.1998] API: GET: stats
[2014-05-20 17:51:53.4456] stratum_recv_line failed
[2014-05-20 17:51:53.4480] Stratum connection interrupted
[2014-05-20 17:51:53.4497] Starting Stratum on stratum+tcp://stratum01.hashco.ws:8888
Stratum just disconnects randomly. I don't know if it's a cpuminer problem, but i presume it is since Minera is working perfectly. Any workaround for this? I have to keep resetting this rig. |
|
|
|
Very good news, specially X11 |
|
|
|
|
Guess I finally managed to get this working. Software is nice but a bit temperamental: failover pools have to have stratum before their link, and the protocol-dump option doesn't really work, even if put on the extra options. And I only managed to get it working after a fresh SD format, couldn't get it going installing on top of my raspbian install
|
|
|
|
I've also noticed very high HW error counts after a 24 hour run after autotune has supposedly set all the pods to their optimal clock speeds.
Autotune does not set optimal clock speeds in all cores of all Gridseeds. You've got to take the values given from autotune and lower/raise them a bit. Not all cores from my devices were set to their optimal speeds. Autotune is VERY, very good, but not perfect. As for the rest I don't know. Don't have as many Gridseeds as you, and no problems here. |
|
|
|
Once again tried making minera work on my current setup, no success. Updated, rebooted, tried again stock minera, and still the same issue, cpuminer just locks up, or hashes but does not give back any results to the pool.
Deleted cpuminer supplied with minera, and replaced it with the one that's already working on my system. It wouldn't even respond to the start miner command.
Is there any workaround to make this work? Wouldn't like to take my rig offline to flash this directly to the SD card and risk myself having this non-functional again.
If you have Raspberry PI (B) I think that the image file pushed in the SD Card should work fine without issue. Otherwise I need at least some logs to tell you what is happening on your controller. PM with logs sent. Thanks in advance! |
|
|
|
|
Once again tried making minera work on my current setup, no success. Updated, rebooted, tried again stock minera, and still the same issue, cpuminer just locks up, or hashes but does not give back any results to the pool.
Deleted cpuminer supplied with minera, and replaced it with the one that's already working on my system. It wouldn't even respond to the start miner command.
Is there any workaround to make this work? Wouldn't like to take my rig offline to flash this directly to the SD card and risk myself having this non-functional again.
|
|
|
|
|
Is this compatible with an already running install of minerd? Just installed it, and it seems to be reading stats correctly (hashrate, reject rate, etc...) but no log is being read, and in the settings page the default pools are still there (although minerd kept mining like normally, on my pool)
EDIT: stopped using my minerd, using the one on Minera. It either says it's hasing, but poolside it registers 0 khash, or gets stuck fixing the thrid core's frequency. Rebooting Minera didn't work, rebooting raspberry didn't work, any ideas?
|
|
|
|
Whats wrong with the multipool? Just curious? Its still in beta I think.
It seems to work for folks, should be a bigger factor though in the next few weeks as rewards drop.
It does work indeed, and pretty nicely |
|
|
|
|
I had a similar problem as reported in the last two posts, if I'm not mistaken it was using the 0.9f version. The debug log said that work wasn't being done because the pool had a small difficulty (or something similar) and actually showed the difficulty number (something like 0.00000000538743274).
Problem solved after rebooting, never happened again and I don't have this log anymore, hope this small info is useful.
|
|
|
|
See this!
15.4 btc buy orders vs. 5.9 btc sell orders. 1:3 buy pressure.
The price is going to skyrock, don't sell!
Buy all you can!
Graphs like these have been seen from time to time in the last few weeks... |
|
|
|
Alright, I have talked to a few people about buying a few BTC worth of FlutterCoin, they will be buying 18BTC worth in all within the next day or two.
So get ready, whole market is about to takeoff...
Here's to hoping for 2000+ by end of this week
Good thing that you are talking to people about Fluttercoin, but if you want 2000+, 18 BTC won't be enough. Don't worry about the values, worry about sharing this great coin. As the dev said, people worry themselves too much with the price. If you we keep things rolling in a good way, price will follow. |
|
|
|
|
Show Posts
