 Show Posts
|
|
Pages: [1] 2 3 4 »
|
Brave miner! Renting it out when stability hasn't settled certainly takes confidence. I saw that as soon as it was rented it crashed immediately.
Appreciate you sharing this as it's the first visual evidence I've seen of extended stability. With the dropping price and increasing stability this machine is becoming interesting for purchase.
Actually renting has worked out quite nice for testing. In the latest rental the renter kept switching his pool setup. This gave me a chance to see what would happen when the miner is "stressed". Turns out during this 3 hrs the miners with the new firmware did fine. The miners running 1.0.0(T) all 3 had missing hash board after the renter's abuse. In the last hour the renter seemed to just have given up and deleted all pool settings. All the miners reverted to my backup pool, however the miners in 1.0.0(T) needed manual stop - 30 second delay - manual restart to get all the boards hashing again. I'm going to run it another 12-24 hrs like it is now and then switch the rest of the miners to the new firmware. Then I think I will try stressing it myself by running on nicehash or some multipool to see if it can handle it. I will keep updating this thread, but at this point I think the new firmware is working well. X |
|
|
|
nice to see 1.0.3 but when i try to start the miner i get Error getting device list: ERR: socket connect(0) failed but status is running?? v 1.0.2 and v 1.0.0 works?
You will see this error on a power cycle restart until the controller starts communicating with the boards. On a power cycle it takes my controllers a minute or two to link to the hash boards. Just give it a few minutes and it should go away. With batch 2 units the lights on the back will flash until the controller connects to them then the lights go solid. While the miner is running if/when it decides to do a cgminer restart you will see this message for about 30 seconds until it starts hashing again. X |
|
|
|
This is still disturbing that we are seeing so many restarts with the latest release. I am glad you are not seeing dropped cards. How many units do you have running this newest release?
I have 6 units total - 12 hashing units. Currently only half of them are running on the new firmware. 2 controllers running 6 hashing units. I'm not too worried about the cgminer stop/restart as long as it is not happening too often. When I briefly ran 1.0.2 i was seeing restarts every 22-23 minutes. This was too often and caused a loss of overall hash power. X |
|
|
|
I just received new firmware from Dominique @ Innosillicon. V1.0.3 https://www.dropbox.com/s/fuyz1r7cy4pkeir/G5-20-V1.0.3.rar?dl=0I am testing now. To be honest I have had no troubles with version 1.0.0(T) as long as the machines run in a cold environment. If anyone is interested I have had them on MRR for the past couple days so you can see my hash rate here: http://rig.rent/rigs/34677X Update: 2hrs hashing with new firmware on half my units. No dropped cards or cgminer restarts Update #2: After 4hrs the cgminer in the newest firmware stops/restarts automatically. All hash boards were running after restart. Hash rate seems to be a little better with this version. Will run and see how it does over the next 24 hrs. Is this update for batch 1 or batch 2.. Thanks.. My units are batch 2. Not sure if the latest firmware will work on batch 1 or not. Now a little over 12 hrs later with V1.0.3 on 2 of my controllers and no dropped cards. One of them currently has a run time of 5h26m so I know they are still stopping/starting but my original thought of once every 4 hrs seems to be wrong. Hash rate with the new firmware is about the same. I will continue to test for another 12 hrs before changing my other controllers/units to the newest firmware. X |
|
|
|
I just received new firmware from Dominique @ Innosillicon. V1.0.3 https://www.dropbox.com/s/fuyz1r7cy4pkeir/G5-20-V1.0.3.rar?dl=0I am testing now. To be honest I have had no troubles with version 1.0.0(T) as long as the machines run in a cold environment. If anyone is interested I have had them on MRR for the past couple days so you can see my hash rate here: http://rig.rent/rigs/34677X Update: 2hrs hashing with new firmware on half my units. No dropped cards or cgminer restarts Update #2: After 4hrs the cgminer in the newest firmware stops/restarts automatically. All hash boards were running after restart. Hash rate seems to be a little better with this version. Will run and see how it does over the next 24 hrs. |
|
|
|
I just received new firmware from Dominique @ Innosillicon. V1.0.3 https://www.dropbox.com/s/fuyz1r7cy4pkeir/G5-20-V1.0.3.rar?dl=0I am testing now. To be honest I have had no troubles with version 1.0.0(T) as long as the machines run in a cold environment. If anyone is interested I have had them on MRR for the past couple days so you can see my hash rate here: http://rig.rent/rigs/34677X Update: 2hrs hashing with new firmware on half my units. No dropped cards or cgminer restarts |
|
|
|
I'm back in the lead, wooo hoooo! 16.574.689
Not anymore...17.543.231. See how long I can hold it for. X |
|
|
|
Can you configure cgminer in S9 to allow API listen? Something like this https://github.com/michelem09/minera/wiki/Network-mining-devices#configuring-a-network-minerOr perhaps S9 has this option pre-configured? Because with that you will be able to use my Minera project to have detailed statistics, scheduled pool switching, full charts and much more, if the main problem is that. First beta of new Minera is set to be released soon (some weeks I thinks) love to have you to test it. Actually I've found 2 conf files in the S9 with the API listen argument. One is located in /etc/bmminer.conf.factory - This one I assume is used for restoring factory defaults. Contains: "api-allow" : "A:0/0,W:*" - Pretty sure this leaves S9's open to intrusion The other one is in /config/bmminer.conf This fie also contains : "api-allow" : "A:0/0,W:*" I'd be happy to test minera on my S9 once the beta is ready. X |
|
|
|
I just tested a S9 I have running on solo right now with a backup pool of Kano. In console I switched to kano and timed the difficulty adjust. Diff stayed at 1024 for exactly 60 seconds and then switched to 8.38 K. Before I had done this test it was running at 10.8K on solo and had been for days. When I switched back to solo diff quickly dropped down from 10.8K to 4K after only a few minutes of no hashrate. I understand about the smaller miners but as you said they will probably never make money mining, so why cater to these in-efficient miners?
Not sure how you're conducting your tests for you see... solo and kano run the same pool software which I wrote so what you say is nigh on impossible. The only difference is solo's start is exactly 1k whereas it's 1042 on kano which is virtually the same (+ Douglas Adams' 42) I understand you wrote the software that is why I am making the suggestion. It is not hard to ssh into a S7 or S9 and switch pools manually and watch the share submission and time difficulty adjustment. I can take a video of it if you want I guess... X |
|
|
|
|
I just tested a S9 I have running on solo right now with a backup pool of Kano. In console I switched to kano and timed the difficulty adjust. Diff stayed at 1042 for exactly 60 seconds and then switched to 8.38 K. Before I had done this test it was running at 10.8K on solo and had been for days. When I switched back to solo diff quickly dropped down from 10.8K to 4K after only a few minutes of no hashrate. I understand about the smaller miners but as you said they will probably never make money mining, so why cater to these in-efficient miners?
I have seen entire 300 TH workers disconnect on NH ramp up due to the difficulty not adjusting quick enough. Large hashrate rentals on MRR are the same way.
X
|
|
|
|
|
A higher starting diff would definitely help with rentals starting speed.
Isn't it best to increase the starting diff now anyways. Most miners are 4TH or higher now.
X
|
|
|
|
With avalon back things should green up nicely...  Share a little luck with cksolo X |
|
|
|
Block !!! About time.. |
|
|
|
Oh sorry Citro...the fatness of a block generally refers to the number of Tx included and also the amount of fees collected. By my definition at least. X |
|
|
|
|
oooh...nice fat block by citronick.
Hash rate boost incoming.
X
|
|
|
|
|
Block...nice green one !!!
|
|
|
|
Block !!! Under 100% |
|
|
|
|
I added a second R1 to the mix. Not sure what to do with the worker name.
Actually I figured it out...please add my second worker 1NU1rjYyxnVc1LxHMjEPTrm1GWKSBpW1mg_Xunknown2
X
|
|
|
|
|
