Topic: [Minera v0.9.0] Your next mining dashboard - S9/L3+/D3/CPUminer/CGminer/BFGminer - page 90. (Read 850502 times)

Hello friends!
if you wanna read (or read again) the original Bitcoin paper from Satoshi Nakamoto annotated and commented, a friend of mine just published this ebook: http://www.amazon.com/Bitcoin-Manifesto-ONE-CPU-VOTE-ebook/dp/B00QUKQ22O/
It's worth reading it, hope you like it.

Ok thank you for your time.

I'm really sorry but unless i have one i really can't help other then provide links I would need it in my hands to play with . Sense i have no plans to buy one and  i went back to scrypt mining which i should have stayed with all a long i don't think i ever will buy one .All my know how is all ways hands on .

Toptek please help me whit my block erupter prisma how can i set the FRECV up?
tried on cgminer 4.8.0 but it dosen`t work

or some thing like this sense your using Linux in the PI
 

--scrypt --zeus-chips 64 --zeus-clock 330 --scan-serial zeus:auto --zeus-chips 6 --zeus-clock 328 --scan-serial zeus:auto
--scrypt --zeus-chips 64 --zeus-clock 330 --zeus-chips 6 --zeus-clock 328 --scan-serial zeus:auto

both  ways should work i had the above lines working with Dmax when i was looking for which miner worked best for me + the way mich said .

Yes you can, change the COMX with /dev/ttyUSBX like so: --scan-serial /dev/ttyUSB0, refer to the related README https://github.com/dmaxl/cgminer/

Did you try this : https://litecointalk.org/index.php?topic=19437.75

Hi, im using Minera v0.3.8 with 1 hurricane x3 connected to a Pi with cgminer dmaxl, i would like to know if it is possible to add one different device like a blizzard and run them together on the same instance of Minera?
i know its working under windows using this kind of command line :


it is possible to do same under Minera?

Thanks for your help

mine does but i had to use this https://litecointalk.org/index.php?topic=20477.0 in place of the BFG in minera now I to am waiting, i love this UI nothing is better imo that Ive  found i had to go back to minera and load in BFG 4.3.1 for it work right two days ago while i wait from this https://github.com/NVReaver/ZoomHash-Pi-Software I saw some rally strange stuff  loading into it when i used that . like other machines hashing at 00000 and id reboot etc there back so i don't use that .but do minera atm with this in it https://litecointalk.org/index.php?topic=20477.0 sense i cant get it  to work right in any version of minera. or just about any thing else with out a lot of work and wasted time.


BTW might want to try this

-S all --set-device zus:clock=240 --set-device zus:chips=128 --set-device zus:read=200 --set zeus:ignore_golden_nonce=1 --queue 9999

try the --scrypt  setting in minera to see if that helps any and you can use the -s all  setting but i don't i feel more in control not using it .

 i sty at like
5.01% / 0.91%

Error/Rejected rates


  in minera  but i also use the above BFG 4.3.1.

. 5.0 works in command line mode ok  but i hate that way . and seems after using it in a UI after 10  hours the power drain cap or drop what ever you want to call it starts up .


For Dmax try one of these if you didn't

# Using libusb
./cgminer --scrypt --zeus-chips  your chip set  --zeus-clock 328

# Direct serial I/O, auto-detect ports (Linux only)
./cgminer --scrypt --zeus-chips your chip set  --zeus-clock 328 --scan-serial zeus:auto

# Direct serial I/O, manual port specification
./cgminer --scrypt --zeus-chips  your chip set  --zeus-clock 328 --scan-serial /dev/ttyUSB0 \
    --scan-serial /dev/ttyUSB1 --scan-serial /dev/ttyUSB2


Have you tried taking it a part and cleaning it up and re pasting the hash boards with something like MX -4 http://www.ebay.com/itm/170865953254?_trksid=p2059210.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT but be very care full thing on the boards tend to come off super easy . . check your wires make sure there not getting to hot if they are  use a fan or the  other way which is a pain but i did it and rewire it, no more hot wires for me . oyea turn  one of three fan in so it is pushing into the case and have the  other two pull out the air .

i read some place on zeus site not sure how true it is max hw error means  the boards need to have the paste re applied some slipped by Q and A applied wrong .

I had the same problem and your options seem correct, I have the same ones. IDK if 3.5 is any better, I am using my computer with cgminer and waiting for the next update tbh.  He is working on it. Hope that helps.

Hi michellem

My ZEUS thunder X6 did not work with v 3.0.8

Under DMax and --scrypt --scan-serial zeus:auto --zeus-chips 128 --zeus-clock 240   it works but with 100% HW with any clock I set

Under BFGminer and -S zus:all --set zus:chips=128 --set zus:ignore_golden_nonce=1 --set zus:clock=240 --scrypt it is working but any pool does not recognize it


Where the problem lies?

Has this happen as well over the past week. It feels like I'm living at my DC this week. Seems that it's only happening on the "auto-install" of Minera.  All of my other SD cards that I had installed raspbian onto aren't affected. Looking forward to the Patched version. Thanks for your continuous hard work michelem!

This might help not sure if this would be poss or make it easy why not make up some kind of template that would let him/her apply  his/her custom setting then let the miner in question use  his/her miners   auto tune settings  not sure if that makes sense .  . i know I'm Polly off base just a thought.

That's great to hear.  Yeah I only thought about it in relation to minerd, so I'm not sure if it could be implemented with other miners.

Attacker couldn't gain access to the system or system files, s/he can "only" do Minera actions like save settings, stop/start miner, ecc...  so I don't think that was related.

PS
I read your thoughts about the autotuning, it's really interesting but I'm afraid it should be hard to manage for multiple miner softwares, let me think about it, probably I'll open a user-request on Github to keep this in mind.

Now I'm wondering if the "update" my Minera did several days ago was not legitimate.  I got an update notification in the top right corner of Minera and let it install the new version.  After the update the version still says v0.3.8.  I also checked the Github page and I see that the main branch hasn't been updated since 20 October.  That being said, I can't see that anything at all changed, good or bad.  My workers all still have the same addresses and all other settings seem to be the same as they were before the update.  It just seems strange to me.

Hope nobody lost big on this and cant wait til you fix it. My miners have been acting funny these last couple of days, my HW kept going to 80-96%, I wonder if this had anything to do with it? Everything was running fine and I thought it might of been a problem with nicehash.

Good luck on the fix

PS
Thanks for notifying us

   --- !!WARNING!! ---

--- Security hole found ---

Hello guys, I just found a big security hole in Minera PHP code allowing an attacker to do almost everything using the web API.

The fix is currently in developing branch within the new changes for next release. (https://github.com/michelem09/minera/commit/0de8c8a203909ec488dd8f48a8af98cbd090a58f)

I recommend you to keep your controller in LAN only until I release the fix in the master branch.

Issue here: https://github.com/michelem09/minera/issues/116

My apologies.

I'm wondering if it's possible for Minera to do a sort of broad "autotune" on the Gridseed Blade based devices?

I know that the minerd --gc3355-autotune option does not work on these devices due to the fact that minerd can't address all of the chip ids individually, and from what I know, that's a limitation of minerd so Minera can't really fix that.  I'm wondering if there's another way Minera could approach the autotune idea for the Blade based devices... keep reading.

So we know that Minera gets it's stats from the minerd API, so this means Minera can see the frequency, hashrate, accepted and rejected shares, hardware errors, etc for each device.  We also know that the minerd API supports setting the chip and device frequency on the fly.  But due to the addressing problem above, we would need to tune the frequency on a per-device rather than a per-chip basis though.

So here's what I'm thinking... Start the miner at the default frequency and watch for hardware errors by device.  After a certain time, if the hardware errors for that device are below a certain threshold, increase the frequency for that particular device and continue watching for hardware errors.  Minera could then (using the minerd API) continue raising the frequency until the error threshold is exceeded in order to determine an upper limit for the frequency, and then lower the frequency to the last known acceptable level.  This could be repeated for all of the devices, each time comparing to the device's current hashrate in order to determine the best frequency for that device.

So, each device could operate at it's own optimal frequency.  It's not as optimal as tuning each chip individually, but at least this would give Blade based devices some way to kinda autotune.

Take this all with a hefty grain of salt.  It's just an idea that came to me today, and I may have no idea at all what I'm talking about.  I'm sure someone who knows more than me can point out anything wrong that I have said.

Can you explain me what you expect in Minera? I mean this is a miner issue not a Minera one, but probably you are talking about a simple way to set up this in a "guided" way instead putting the command line?
Please tell me more, don't know if this release can have your idea but I could note it for the future.
Thanks