 Show Posts
|
|
Pages: [1] 2 3 4 5 6 »
|
And honestly, if you are both British, why such terrible English?
Sorry man, but your English is not top notch either  |
|
|
|
|
I've released a new version of CONTROLA.
version 1.4.7.x
Pool priority arrangement is now submitted directly to cgminer, so no need to restart the miner anymore.
Deleting and adding pools are also submitted to cgminer.
So pool switching should be less painfull now.
Cgminer doesn't have an API for editing an existing pool, so this still requires a restart.
Things to consider
It takes a couple of seconds before the changes are reflected from cgminer.
Please don't delete an active pool. If you do, it will only be deleted in your poolsettings config file, but not in the running cgminer, so you will need to restart cgminer for the changes to take effect.
No other changes have been made apart from the new pool settings feature, so complaints about hashrate being worse or things being unstable, are not related to this release.
|
|
|
|
The controla software does seem to misquote the actual hashrate a lot. Mine tells me I'm running steady at 3.5Mhs but poolside at 13.5
A little annoying but as long as the rewards come to my wallet I'm okay with it.
Restarting is a real problem with these miners. Sometimes giving the wrong hashrate, or not starting up properly, or at all. Making coinswitching a pain. I might have found a way to switch pools without restarting cgminer by firing a socket command. Restarting will still be a problem, but at least you don't have to do it often or at all. I will keep you posted when there is a new release out. should be in a couple of days |
|
|
|
I did upgrade one of my two units last night and it's been running fine but I did have to reboot it after upgrading
ok, cool. was there any performance or stability boost do you think? my only observation(and this has not been proven with multiple tests) is that the unit did not need to be restarted multiple times after changing pools, like I've experienced with the stock firmware. oh and even though it reboots itself after the update - I neede to reboot it a second time because after it's own reboot all I say was this in the syslog file: Jun 12 14:18:54 hashracontroller cgminer: Started cgminer 3.1.1
Jun 12 14:18:59 hashracontroller single_ltc_monitor[2201]: Started LTC PRocess waiting 10 seconds to boot cgminer
Jun 12 14:18:59 hashracontroller single_ltc_monitor[2201]: socket connect(127.0.0.1,4001) failed returning null
Jun 12 14:18:59 hashracontroller cgminer: Icarus Detect: Test failed at /dev/ttyUSB0: get 00000000, should: 00038d26
Jun 12 14:18:59 hashracontroller cgminer: All devices disabled, cannot mine!
Jun 12 14:19:04 hashracontroller single_ltc_monitor[2201]: socket connect(127.0.0.1,4001) failed returning null
Jun 12 14:19:09 hashracontroller single_ltc_monitor[2201]: socket connect(127.0.0.1,4001) failed returning null
Jun 12 14:19:14 hashracontroller single_ltc_monitor[2201]: socket connect(127.0.0.1,4001) failed returning null
Jun 12 14:19:19 hashracontroller single_ltc_monitor[2201]: socket connect(127.0.0.1,4001) failed returning null
Jun 12 14:19:24 hashracontroller single_ltc_monitor[2201]: socket connect(127.0.0.1,4001) failed returning null
Jun 12 14:19:29 hashracontroller single_ltc_monitor[2201]: socket connect(127.0.0.1,4001) failed returning null
Jun 12 14:19:34 hashracontroller single_ltc_monitor[2201]: socket connect(127.0.0.1,4001) failed returning null
Jun 12 14:19:39 hashracontroller single_ltc_monitor[2201]: socket connect(127.0.0.1,4001) failed returning null
Jun 12 14:19:44 hashracontroller single_ltc_monitor[2201]: socket connect(127.0.0.1,4001) failed returning null
Jun 12 14:19:49 hashracontroller single_ltc_monitor[2201]: socket connect(127.0.0.1,4001) failed returning null
Jeff The trick for rebooting is, first reboot the miner, and then reboot the pi. The miner has to be reset completely and alive, before connecting the pi to it. thanks for the insight but how do you do that when your miners are remote - is there a command at the firmware level to reboot the miner? Yea that would be difficult. There is no power cycle command from the PI to the miner. Can you have a remote power switch installed ? like this one? this one has a web interface http://www.amazon.com/Managed-Designed-Manufactured-Synaccess-Networks/dp/B0039OZKPE |
|
|
|
I did upgrade one of my two units last night and it's been running fine but I did have to reboot it after upgrading
ok, cool. was there any performance or stability boost do you think? my only observation(and this has not been proven with multiple tests) is that the unit did not need to be restarted multiple times after changing pools, like I've experienced with the stock firmware. oh and even though it reboots itself after the update - I neede to reboot it a second time because after it's own reboot all I say was this in the syslog file: Jun 12 14:18:54 hashracontroller cgminer: Started cgminer 3.1.1
Jun 12 14:18:59 hashracontroller single_ltc_monitor[2201]: Started LTC PRocess waiting 10 seconds to boot cgminer
Jun 12 14:18:59 hashracontroller single_ltc_monitor[2201]: socket connect(127.0.0.1,4001) failed returning null
Jun 12 14:18:59 hashracontroller cgminer: Icarus Detect: Test failed at /dev/ttyUSB0: get 00000000, should: 00038d26
Jun 12 14:18:59 hashracontroller cgminer: All devices disabled, cannot mine!
Jun 12 14:19:04 hashracontroller single_ltc_monitor[2201]: socket connect(127.0.0.1,4001) failed returning null
Jun 12 14:19:09 hashracontroller single_ltc_monitor[2201]: socket connect(127.0.0.1,4001) failed returning null
Jun 12 14:19:14 hashracontroller single_ltc_monitor[2201]: socket connect(127.0.0.1,4001) failed returning null
Jun 12 14:19:19 hashracontroller single_ltc_monitor[2201]: socket connect(127.0.0.1,4001) failed returning null
Jun 12 14:19:24 hashracontroller single_ltc_monitor[2201]: socket connect(127.0.0.1,4001) failed returning null
Jun 12 14:19:29 hashracontroller single_ltc_monitor[2201]: socket connect(127.0.0.1,4001) failed returning null
Jun 12 14:19:34 hashracontroller single_ltc_monitor[2201]: socket connect(127.0.0.1,4001) failed returning null
Jun 12 14:19:39 hashracontroller single_ltc_monitor[2201]: socket connect(127.0.0.1,4001) failed returning null
Jun 12 14:19:44 hashracontroller single_ltc_monitor[2201]: socket connect(127.0.0.1,4001) failed returning null
Jun 12 14:19:49 hashracontroller single_ltc_monitor[2201]: socket connect(127.0.0.1,4001) failed returning null
Jeff The trick for rebooting is, first reboot the miner, and then reboot the pi. The miner has to be reset completely and alive, before connecting the pi to it. |
|
|
|
Finally got my unit today.
501 watts on an EVGA gold PSU.
It is indeed hashing over 14mh/s, but I can't achieve that poolside.
What diff setting are you guys using?
Will lowering the clock speed reduce HW errors? Mine is about 6% HW errors after a half an hour.
I get about 2-3% rejects and 8-10%HW errors. Sometimes the rejects will go up to 10% as well but resetting the miner seems to fix it ok. I find the controla reported hash wildly in accurate btw. I've had it reporting 3.5Mhs before for about 5 hours while my pool said it was averaging 13 or so. Has anyone else had trouble with coinotron btw? I can't hash higher than 5Mhs there, wondering if it's to do with the difficulty setting of the shares they allocate etc. The HW errors are normal for these chips btw. ASICS are inherently less stable then GPU's when scrypt mining. |
|
|
|
BTW these new machines, doesn't reboot nicely. Sometimes (not every time) when rebooted, the miner is still busy with the previous session, occupying the usb drivers. When the PI is rebooted, It can't find the usb devices, so this is why it wasn't hashing after the firmware update (which is followed by an automatic reboot).
But once it's running, it will keep running. Just remember to do a power cycle after reboot (and firmware update)
thanks unless there is some compelling reason to update, I'll stick with the original firmware for the time being until I switch over to my linux box - thanks the cgminer code can be cloned from this URL https://github.com/HASHRA/cgminer-hashra |
|
|
|
|
BTW these new machines, doesn't reboot nicely. Sometimes (not every time) when rebooted, the miner is still busy with the previous session, occupying the usb connection. When the PI is rebooted, It can't find the usb devices, so this is why it wasn't hashing after the firmware update (which is followed by an automatic reboot).
But once it's running, it will keep running. Just remember to do a power cycle after reboot (and firmware update)
|
|
|
|
Soon, details about SCRYPT-N ASIC !Stay tuned  Can I ask you a simple question? Why and for what reason you would even wish to make asic for n-scrypt?? 0.o Did you ever read what is about n-scrypt and coins being asic resistant? Or you planning to lose money on investing in development into this or you have way to do this additionally without effort and costs... Either way let me clear small thing: Most coins, lets take Vertcoin as example (first and biggest n-scrypt based coin) from always was clear and all miners are and will go with this: IF there even be made ASIC for n-scrypt... THEN this coin will HARD FORK if needed into new Better/more ASIC resistant way... N-Scrypt is just SMALL part of ... n-factor etc etc stuff.... the idea of being asic resistant is that if required - solution is made... So .... is it worth? Will it be worth? Just curious... as cant understand why to put money into something that simply will anyway fail? Well just my few cents here hi. scrypt and scrypt-n has no big difference. we can support -N. why not to add support it? Upto which N are you going to support? at least 20000+. No. I mean what n-factor are you going to support. Look at chart for reference. http://ultracoin.net/nfactor.htmlits changeable, not fixed. orz... Read the question: Upto which N are you going to support? upping the N value will at some point make your GPU Rigs useless as well.. It's not just ASICS. So don't get too excited. |
|
|
|
finally wise eyes.... thanks for the research mate... i think that pretty much sums up most of us here and potential buyers are now waiting for prices to drop... i know innosilicon has the best chip in terms of power consumption but considering how 55nm (Zeus, hashra) is going to flood the market soon i think it won't be long before they will succumb to pressure and have no choice but to lower their prices.. it will turn out to be just the way we experienced with greedyseed where early buyers were fleeced to the bones and still haven't recovered half their initial investment until now and some now have to sell at a loss... the lowest i recently saw was USD 65 per miner..  Ok after inspecting and asking around I have found out la90 is just called 90 to get attention in reality the unit does 78-80 mhs max rate at mining. I really dont see any ROI on a 80mhs unit for 11000$.
Yep. LA90 .. is the normal A2 Terminator with 6 modules of which each has 8 chips total of 48 chips ... normal mode is at 75mh ... they run around 79-82mh ... Has anyone received the LA90? or any A2 machine? Is it any good? I haven't read any reviews anywhere. I thought stocks were in hand and delivery was in 3 - 5 days? |
|
|
|
SSH
What version of CONTROLA do you have? if it's lower than 1.4.0 then you're using an older img with a different password. You can download the latest img from the HASHRA support page. That img has the aforementioned password |
|
|
|
Good news Ladies & Gentleman… We have now decided to release the SSH login details for the Gridseed Based products using the CONTROLA Firmware: USER: pi PASSWORD: 3K4Hb8FMeZjQZJEX6scYzZa ENJOY!  Unfortunately I can't login, I'm getting an access denied. More people with that? I've updated to the latest version (if that matters) SSH login or CONTROLA login? the CONTROLA login through the browser is hashra/hashra |
|
|
|
I have 22 seeds connected. It seems to run fine for a few days and then will not allow me to login, although it continues mining just fine.
yea, that might be the problem. I don't know why but the pi becomes unstable when there are more than 20 miners connected to it. It's not logging in because it can't process the request properly. 20 should be ok though. I connected 25 on 1 pi once, I can log in, but the pi becomes horribly slow |
|
|
|
what command do you use to reboot this thing? Im unable to login to the web interface an tried to reboot it via ssh. I tried sudo shutdown -r now and it says its shutting down but never does...
I think your pi is flooded. How many miners are connected to it? before rebooting, can you also run this command? This is like the windows taskmanager, what is hogging up all the resources? |
|
|
|
New version firmware doesn't restart when you set a time under settings!
Anyone noticed that?
I noticed that... still trying to figure out why that is. Apparently there is a workaround for this a if you read a few posts back. Changing the number, save it, and then change it again or something. |
|
|
|
I downloaded "hashra-firmwareimg-v6" today as I couldnt get any other IMG files running with these GS
Straight in, away we go and theyre sitting stable at 362Mhs scrypt only mode.
I -did- do an update as soon as I logged into it by calling the IP from my laptop, and its stable, 4 hours later...
** just trying to find out how to add backup pools **
I don't think that version has failover yet. You can download the latest img from the hashra support page. the MINI and ATLANTIS are versions for your gridseeds I think. ATLANTIS is scrypt only |
|
|
|
Hi, this is the url of the fork https://github.com/HASHRA/bfgminerI made changes in the /feature/gridseed-support (v 3.10) branch I tried modifying the gridseed-support-new branch, but for some reason it was not performing as well as 3.10... on the pi at least. There is official support in BFGMiner for GridSeed devices. Why fork it instead of contributing? I'll have another closer look at 3.99, The clock setting is already dynamic there. I added the chip amount setting in the fork, I don't know if that is something that you are interested in having? |
|
|
|
Is there a D/L link for 1.4.5 anywheres?
There is no img for 1.4.5 If you don't have version 1.4, you can download the img first and then click on the update controla link |
|
|
|
Below the new frequency table for our forked bfgminer (not done with the latest firmware yet though, need some time to make it pretty ) Hi there - what fork of BFGMiner is this? Do you have a URL? Hi, this is the url of the fork https://github.com/HASHRA/bfgminerI made changes in the /feature/gridseed-support (v 3.10) branch I tried modifying the gridseed-support-new branch, but for some reason it was not performing as well as 3.10... on the pi at least. |
|
|
|
Niceman from Coinmine.pw changed up somethings on his pool to optimize it for BFGMiner. I ran my gridseed minis and blade last night and had close to 0 rejects. Pool ran super smooth. Give that pool a try with Hashra Controla and let me know what you guys think.
Thanks
Unless the changes were made recently, when I tried it couple of weeks back, there was allot of rejects. I tried the Canadian server thinking it will be closer and better for me being in Canada, it was worst than the US server. I hope the change is recent. Will give it a try. Maxzilla, When mining on a pool, I mentioned a while back that it turns red but still saying running. I tried this on several pools. Including wafflepool which Hashra does it's testing on, and I still get that. It doesn't stay green. Any ideas? The other question I have is, will I be able now with the new firmware to up the hash rate from 850? As you mentioned earlier to me that the higher rates are for modified gridseeds. I have never seen it myself, Where are you located? in canada? (maybe it's the internet connection) The red colour means the server is dead temporarily. I don't think it will show the server as running, if it does, then it's a bug. can you make a screenshot when this happens (with the syslog visible)? I'll have a go at nicehash and test it myself |
|
|
|
|
