BumP for Christmas
210 euro for 300GH? you can get over 500GH of more efficient bitmain or spondoolies gear for that value (450GH S3+ is $200, 1.7TH SP20 is $700) My thoughts exactly .... though for 300Gh/s @ 220W it is less wattage per Gh compard to the others, but is the premium on the outlay recoupable in the short run to justify the purchase .... I don't think so. |
|
|
|
the fields are not blank. I removed one pool, leaving 2. I added back in a third to humor you. Nothing different.
You must be in a tight spot ... adding back your 3rd pool sure is not funny if you are not earning! |
|
|
|
Thx. Tried that already. no luck tho.
Sorry, what does "bricked your control board" mean?
Since it's Bitmain's fault, i should be able to do an RMA- right?
Bricked as in your control board is (probably) like a brick now .... can't work ... dead .... un-repairable ... things like that. Not sure whether it is bitmain's fault ..... but you;ll have to hear from thm for that. |
|
|
|
Yes it is dhcp, yes it is getting the address from dhcp.
I can even ping , nslookup and tracert from the diagnostics page.
Uptime: 0h 4m 28s
MAC-Address: 20:59:A0:CA:3B:B0
RX: 200.01 KB (1438 Pkts.)
TX: 239.70 KB (691 Pkts.)
IPv4: 192.168.1.99/24
other things to try?
Now try starting cgminer manually via the System -> Start Up tab (click on start in the cgminer row thn browse back to the status page and see) |
|
|
|
I flashed the firmware on all my S3s yesterday to the Nov 24th release (antMiner_S320141126.bin). It created problems like someone else mentioned above.
So i decided to flash them to the October release (antMiner_S320141024.bin). All except one completed the process. It just kept saying flashing for about 30 minutes....like it had stalled.
I tried to re-connect to it using the static address I've been using for 2 months. I got this message: " This webpage is not available".
So i used the reset button and connected it directly to my PC. When I tried to connect to the original IP address (192.168.1.99), I got: "This webpage is not available".
long story short, it seems my computer and router can not see the miner anymore. Also, The green light for the internet connection only comes on for a second after turning on the miner. I also noticed that only the red light blinks. None of the other LED lights come on.
Did the november firmware release (antMiner_S320141126.bin) kill my miner?
Pls help!
EDIT: I also tried using an IP scanner to try to find that miner in case its IP address had changed. The IP scanner showed all my other devices but also reported that there was a dead device.
Anyone got any ideas how to connect to miner that can't be reset? 1. Switch off the troublesome unit. 2. Ensure you do not have any other rig / computer connected to your network with the default IP 3. Switch on the troublesome unit and load the default IP If that fails, then you have most probably bricked your control board during the reflash. |
|
|
|
How will resetting he network help? I can connect fine. Everything was working fine.
Yes it is brand new AND I believe was from batch 10. I received it from a vendor who shipped mid November. Was that 10? Regardless it was new and using whatever firmware it shipped with.
ALL I did was remove a pool and save/apply. Nothing more.
Please help.
There is certainly something else that you did, otherwise, it'd be showing the pool details in the screenshot you posted even though the pool was dead. But you'll get a blank status screen if it can not connect to the internet. And that, ma dear friend, is why we advised you to look at the network settings! EDIT: And before you ask, YES it has been known that the S3 set to static IP can fail to connect, there's a simple explanation for that, but that is for another day, simply ensure it is on DHCP! |
|
|
|
My brand new S3+ (batch 10 I believe) was running great until an hour ago when I changed one of the pool settings. Since that re-start neither of my boards show up. Its on its own power supply (EVGA 650).
HELP! Is it dead? How? What can I do? I lowered the frequency, took off the cover and checked all the connections. nothing.
was DHCP checked or unchecked? Use advanced IP scanner (PC) to see its IP address. He does not need to scan for the IP as he can clearly log into the webUI. Simply check your network settings and ensure you have it set to DHCP (as Biodom suggests), if not set it as such and then Save & Apply. |
|
|
|
Hi, in the meantime one slowdown occured, hashcheck script run, no reboot. As I'm not overclocking my device mingh is 405 in my case. I also adjusted the voltage to the suggested 0.725 V (a bit below standard, right?). I'm not very good in Unix / Linux bash commands, thus I played a bit around in a putty terminal session (using half a dozen of example and help URLs) and reworked the var=$ ... line till the output matched exactly the average GH/s — basically just taking the end of the line containing [GHSavg]. #! /usr/bin/ash
mingh=405
var=$(`cgminer-api lcd | grep '\[GHSavg\]' | cut -c 16-`)
if [ $var -lt mingh ]
then
/sbin/reboot
fi
When I try to run the script in the putty box it gives me: -ash: hashcheck: Permission deniedIn the system log no error is mentioned, thus I assume it's just my missing knowledge of how get elevated rights in a terminal session. Edit: No reboot after next slowdown.Looks like I should revert to the August firmware, too — see next post. How are you starting this from the scheduled tasks? If you saved the script as /sbin/checkHash (made it executable by chmod +x), and want it to run every 15 minutes past the hour, you'd have added to your scheduked tasks as line as follows: */15 * * * * root cd /sbin && ./checkHash >/dev/null 2>&1 That "should" take care of the permissions (though I have not tried it either!) |
|
|
|
Bought 17 units S3+ (all with November firmware). Almost all units very often slowing down to around 30-50Ghash, so average hashrate is much lower than 453GHash.
Also it seems that units are not new unlike previous deliveries, dust inside, sometimes scratches on the top...
I am not satisfied.
What is interesting - that PCB inside are much different (green, other capacitors) than PCB in units purchased in September (blue).
Whoa! Did you buy those directly from Bitmain? If so, looks like they are offloading some of the units they had up in their hosting facility. PS. Just downgrade the firmware to the October one and you should be good to go. The fixes flying around (with your 17 units) will just give you more head-aches. |
|
|
|
If anyone still running the new firmware, would you please post here the line used to start cgminer? It "should" be in the System Log (under Status) immediately after starting up (I think that is where I saw it before, but may be wrong!) or even better, if you SSH into the rig open the file /etc/init.d/cgminer with vi editor and scroll down to the line that starts PARAMS= (not #PARAMS=). I think the issue of dropping hash-rate may be due to the setting of auto-voltage / frequency (and the startup line may reveal that!).
You can extract the filesystem from the new firmware like this
dd if=antMiner_S320141126.bin of=kernel bs=1 ibs=1 count=1015116
dd if=antMiner_S320141126.bin of=filesystem.squashfs bs=1 ibs=1 count=2448854 skip=1015116
unsquashfs filesystem.squashfs
ls -1 squashfs-root
Do you happen to know the Windows commandline equivalent too? I ask as I do not have a linux installation at hand .... unless of course that'd work in MinGW as well. |
|
|
|
Yeah, I wish i had some kind of auto-reboot triggered on a timer.
How do you retstart cgminer quickly without rebooting and changing the freq ?
You can do it via a script that you run via scheduled tasks. I had one before I stumbled accross the voltage settings but removed it when my affected rigs stabilised after the changes. You can put a shout out in the S3 support thread or the cgminer thread and someone will respond with a solution. I dug this up after being asked on the S3 Discussion thread .... again, I have not tried this but it simply reboots rather than restarts cgminer (I now recall I had an issue with restarting cgminer via api, but you can still restart it via init.d script). mingh=505
var=$(`cgminer-api lcd|grep -o '\[GHSavg\] => .*$'|cut -d' ' -f3|cut -d'.' -f1`)
if [ $var -lt mingh ]
then
/sbin/reboot
fi |
|
|
|
Is there another way to check the miner's current condition and trigger the reboot if needed?
I have not tried this, but it uses the api to get the average hash rate, if it falls below mingh (505) then it reboots. #! /usr/bin/ash
mingh=505
var=$(`cgminer-api lcd|grep -o '\[GHSavg\] => .*$'|cut -d' ' -f3|cut -d'.' -f1`)
if [ $var -lt mingh ]
then
/sbin/reboot
fi |
|
|
|
However, nothing lasted more than an hour at ambient temperatures of 17 degrees C.
1 hour is nowhere near enought to come to such a conclusion, unless ofcourse the rate is way off, in which case, evn 10 mins would do. I let them run for over 10 hours, One of mine went down to 400 GH/s and the other to 420GH. So on the long run, mines are not performing well. My good machine was still doing fine but loosing speed to0 ... about 515gh in almost 24 hours. The degradation in hashrate was undeniable within 1 hour, but I ran them another 12 hours to be sure about what I was seeing. Essentially, I was not able to get any useful increase in hashrate by adjusting the voltage. I saw some great first hour numbers, but dropping back to just adjusting frequency on the stock 10/24 firmware was the better alternative. If others are seeing better results, I guess it is because they have different chips or better cooling. I'll have to put it down to all units in the S3 clan being built different ... yet the same! 1. On all units the that I have changed voltage settings, those that showed a good / increase in hash-rate in the 1st hour have always been able to out-perform their previous default setting hash-rate sustainably, albeit, some have an increased HW rate (which I tend to turn down a notch). 2. The voltage setting should, without any qualms, improve efficiency in lower HW rates but more so if you overclock the unit. If you are running at stock freqs, the story may be different .... In effect prior to the voltage setting, we've been overclocking / running rigs at voltages that are not optimal for the higher frequencies. That is why you have to get a better HW rate if you set the correct voltage when you overclock, the speed comes with how far you overclock! |
|
|
|
Another long block .... I honestly thought we'd turned a corner of sorts after that 1day+ block ....anyone with a peta to point it our way?
Phew! Get in there! |
|
|
|
|
Another long block .... I honestly thought we'd turned a corner of sorts after that 1day+ block ....anyone with a peta to point it our way?
|
|
|
|
Yeah, I wish i had some kind of auto-reboot triggered on a timer.
How do you retstart cgminer quickly without rebooting and changing the freq ?
You can do it via a script that you run via scheduled tasks. I had one before I stumbled accross the voltage settings but removed it when my affected rigs stabilised after the changes. You can put a shout out in the S3 support thread or the cgminer thread and someone will respond with a solution. |
|
|
|
I am trying to get 2 S1 blades to work; so far, I can only get 1 blade to hash. If I plug in both USB UART sticks (2102), only 1 works, never 2. My cgminer running config is:
cgminer.exe --bmsc-options 115200:25 --hotplug 0 -o mypool:3333 -u myworker - p xxx
Both S1 blades are pencil modded for undervolting.
I'd like to get both blades to hash. BTW, the 2102 USB sticks go in Pluggable USB Hub bought on Amazon. I am running the pre-compiled cgminer (cgminer-bmsc) found on the thread here. Zadig winusb driver installed for both 2102 sticks, running Windows 7 64-bit.
Any ideas?
I had a similar issue and here's how I temporarily solved it (before moving my blades to rPi). Start cgminer with just one board connected, and after it starts hashing, plug in the second board. You may need to remove the hotplug switch from your startup line though. The difference from your scenario is that whenever I started cgminer with two blades connected, it would crash almost as soon as it recognised the boards. |
|
|
|
However, nothing lasted more than an hour at ambient temperatures of 17 degrees C.
1 hour is nowhere near enought to come to such a conclusion, unless ofcourse the rate is way off, in which case, evn 10 mins would do. I let them run for over 10 hours, One of mine went down to 400 GH/s and the other to 420GH. So on the long run, mines are not performing well. My good machine was still doing fine but loosing speed to0 ... about 515gh in almost 24 hours. 10 hrs is a good enough indicator I'd think. On the positive side, if these are the same units that could not go over 450 in the first place, but can now hash for a while over 500, then you probably have to revert to restarting them often like you were previously, at least now they'll be running faster. On that note, you may find that simply restarting cgminer will "clear things up". |
|
|
|
I have been running B11 units at 262.5 / 0750 voltage for the past three days, and they have hashing at ~530 GH/s with very low (.0001-.0002%) hardware errors. B11 units appear to be very stable at this speed and voltage, and use ~415 Watts at the wall (.78W/GH). Has anyone tried pushing the S3+ a bit further? I'm tempted to up the speed to 268 or 275 and see what happens...  Up it, no worries so long as you have it adequately powered. You may need to play a bit with the voltage setting for freq 268, i.e 0750, 0755 or 0800 since it is in-between the datasheet settings guided by the HW errors you may get. If you look at the OP, I had a rig at freq 281 though the HW is a lot higher than I got running it at freq 268.75 so I reverted to that. Saying that, like most of my S3's (and +'s) , I run it off a 550W PSU ..... so thre may be something in that. |
|
|
|
The bottom line is Quite happy that i'm saving power. If you have a unit that you can OC to 250 with the default setting, you can make a huge power saving and even pushing it harder and getting awesome result.
If anyone has found a trick with the units that is somehow under performing with the stock setting, share it with us so we can make them more profitable.
It is false to say that you are making a power saving, rather, that you can achieve the same rate with a PSU that can efficiently supply the wattage at the datasheet voltage (plus a bit more for the fans and lost power). Thus if you are running with a voltage setting of 0750 and freq of 250, you can run the rig using a PSU with a rated wattage of ~400 watts and achieve at least 504 Gh/s, or a voltage setting of 0720 with a freq of 225, a PSU rated at ~350watts to achieve 453Gh/s. Of course, for running them that tight, they'll also have to be at least bronze rated too. If, however, you are running a PSU rated at 650watts, you'll not see the drop at the wall as you expect. |
|
|
|
|
Show Posts
