My Bitmaintech s-7 underpreforms at freq 600 + freq 550 , not freq 500 (Fixed!)

[philipma1957]

@ mods this could go into support as it seems to be a fixable problem for my machine.
maybe others can try the same fix.

May have found the problem.  Hard power off power on such as a blackout. Seems to cause high error rate and low hash.  If this occurs try a system reboot.

This may be one problem causing low hash high errors. It seems to have been my problem.  If you are tossing high errors like 0.1100 and low hash try a system reboot. I will continue tests and screen shots.




I want to start a thread on this.  below was one of my "bad" s-7's.

Seems like hard power off power on causes it. Blackouts or moving the gear would be an example of hard power off
Seems like system reboot  via software fixes it.

 



please summit screen shots at least 2 hours run time.

At freq 600 ---------for me really not so good.
At freq 550 -------- for me not so good
at freq 500 --------for me good

please list your psu.

Any fuck you bitmaintech your gear sucks is an auto delete
any the gear will never roi is an auto delete.

I will use ckpool for my stats.

Topic is locked for now.

here is an early look at my s-7 freq 500  really good numbers

[1714686937]

1714686937

[philipma1957]

I use an Evga 1600 p2 psu with 240 volts it reads 4.1 amps which x 240 volts is 984 watts

Here is my freq 500 after 1 hour and 13 min.

and as you can see freq 500 is good  almost no errors hashrate is  4055 ghwhich is more then  5/6 x 4800 = 4000
so if the s-7 was sold as a freq 500 machine with 4000gh using  1000 watts it would be true specs:

[philipma1957]

Next will be a freq 550 demo.  this will be up in 1 hour -2hours. I may have found part of the issue.  When you power down with a switch or a full power down then you power up like what can happen with a black out the unit runs like poorly tossing  .1100 error rate and 5 or 10% hash rate drop.

I went to system reboot and did a software reboot here are results.

these are good numbers for freq 550  you should get 4400gh and 1100 watts  I am better then both after the software reboot.

4476gh at 1104 watts and 0.0007 error rate

Still locking this until all test are done I will be back.

[philipma1957]

So once I did a software system reboot all things seem well.

freq 550 is better then 4400gh with 1000 watts




freq 600 is better then 4800gh with 1200 watts used.

Seems like try to do a software reboot. as a key tester.

[philipma1957]

Thread is open for posting. So if you were getting high hw's and low hash try the system reboot and post results here.

[UfoRia]

Thank you for taking the time to troubleshoot the problem. Hopefully the soft reset solves the sagging issue and we know that hard resets causes it shit itself.

Where I live we have power sags and lightning storms where power drops for a second two. This is going to be a problem where I live, farck. Anyone know of a way outside of a bridged battery/generator solution that could handle 216 amps / 11k watts for one to two seconds during a power sag that won't cost $15k? I just looked up the rackmount UPS's that would require three and they cost almost as much as the miners, heh. I have a GFI at the service delivery for my main panel, so spikes are no worry. Lightning mitigation is as good as one can get here, so any ideas?

Anyone have any ideas, outside of using sneaker net from neighborhood kids to push the soft reset when the miners go down for a few seconds and come up in a funky state?


Ufo

[alh]

Does the S7 mining GUI have a "shutdown" mechanism? I ask since it might be useful when there is a planned removal of power (e.g. to relocate the miner, re-configure, etc). This won't help if the power fails but it might make things better for folks during their early testing and experimentation.

I always worry about a power shutdown of anything that's got a flash based file system getting corrupted (e.g. a Raspberry PI, maybe the BBB).

[RichBC]

Phil a very useful discovery and you seem to have some very good numbers after the Software reset.

I wonder if this is in any way related to Bitmains instructions to power up the Hash Boards first & then the Controller? Could be that the S7 does not like them being powered up simultaneously and so doing the Software reset becomes the equivalent of powering up the Controller after the Hash boards are powered?

I am sure someone, not me, could write a script that could run on power up and then do a soft reset?

Rich

[philipma1957]

Phil a very useful discovery and you seem to have some very good numbers after the Software reset.

I wonder if this is in any way related to Bitmains instructions to power up the Hash Boards first & then the Controller? Could be that the S7 does not like them being powered up simultaneously and so doing the Software reset becomes the equivalent of powering up the Controller after the Hash boards are powered?

I am sure someone, not me, could write a script that could run on power up and then do a soft reset?

Rich

numbers are still good.  over 4800 and 1200 watts errors are 0.0111  vs 0.1110   and temps are in the 50's.

over nite  numbers  show over 4800gh my pdu show 5 amps which is 1200 watts.  errors are 0.0132 a little higher then last nite but far better then 0.1100 when the problem occurs and temp's are in the 50's

[Biodom]

Good that it worked, but it is not exactly a new behavior for antminers.
In fact, S1 and S3 on many machines also had errors  with PSU hard reset and had to be rebooted into a "better state" by a software reboot and sometimes multiple of those (especially on S3).

I am interested in some other parameter-what is the optimal board operating temperature that miner is reporting in gui.
Somehow it looks like it throttles back by itself as soon as it reaches 56C or so, at least on my machine.
i don't see much difference in hashing at 51C vs 55C with ambient around 28C. I wonder what others had observed.

[clgrissom3]

Thanks Phil!  The S5s acted the same way for me also...soft reboots usually brought the hashrates back to normal after crappy looks on power offs.  I would have never guessed this behavior would carry forward to different machines.

[philipma1957]

Good that it worked, but it is not exactly a new behavior for antminers.
In fact, S1 and S3 on many machines also had errors  with PSU hard reset and had to be rebooted into a "better state" by a software reboot and sometimes multiple of those (especially on S3).

I am interested in some other parameter-what is the optimal board operating temperature that miner is reporting in gui.
Somehow it looks like it throttles back by itself as soon as it reaches 56C or so, at least on my machine.
i don't see much difference in hashing at 51C vs 55C with ambient around 28C. I wonder what others had observed.

well I can test it right now.  I will lower fan speed which will raise temps.

you want to see 58c do well:

So here is fan 55% freq 600 temps at  53 all good after system reboot.

I will drop fan to 45% which should get the gear over 58C

https://i.imgur.com/KEJAcFv.png
https://i.imgur.com/tXRhqB9.png

So I just did a new setup with fan at 45% temps should be higher then my 52 52 53.

and after 1 minute I am running at temps of  53 54 54  and my errors are 0.0401
after 3 minutes I am running at temps of 55 56 56 and my errors are 0.0286  and hash rate is 4553

I will let it run for 15 minutes I may need to slow the fans more since I seem to be at temps of 55 56 56

It has settled in at  4712 gh
temps of 54 ,55, 56
errors of  0.0240%
fan speed is 45%

so I will drop the fan speed to 40%.


https://i.imgur.com/eN3QQ3g.png

with fan speed at 40%    freq at 600   temps are now 58 58 59

 I am hanging in  with 4717  errors are 0.0201

 so far testing seems to show keep your temps at 52-54c or lower.  I will run this at fan 40% to see If it gets better or worse then below.

Fan 55% gave me cool numbers and good hash rate.

[tl121]

I find these results interesting.   I would like to understand what is going on.  I thought I understood the performance of my S7 until yesterday when I had to reboot it several times to get back my full hash rate.    I thought that the hash rate was proportional to the number of working chips times the clock rate times (1 minus the hardware error rate).  Apparently, not so.  I found that the effective hash rate dropped significantly yesterday with no X's, the same clock rate, and same hardware error rate.  It did not seem to relate to chip temperatures, either.

Perhaps I will need to get out the volt meter and measure the power on the PCI-E connectors to see if this is a variable.  I have also been playing with fan speeds and it is also possible that my power line voltage varies.

Does anyone understand what is going on?  Is there hidden state inside the chips that cause them, for example, to disable some of the cores as a defense against hardware errors?  If so, perhaps this algorithm is too clever by half...

[philipma1957]

there is something going on  that is not quite right.


sometimes it just tosses errors at the 0.1100 rate  and hash drops off say 4500 vs 4800.

in my case I can do it with hard power down and then power up.  needing a soft boot to fix it.

my psu is solid 1600 evga p2  using 240 volts on a socket 2 feet away from the main box.

I do 11.94 volts after the power draw  12.07 before the power draw.

try to see if your cables drop to 11.80 or less.

[bradli]

550 frei
http://prntscr.com/8mm1w1

[HerbPean]

I'm using a combo Corsair RM1000 for one unit and one RM1000 / CS 750 for the other.

HW 0.01% and 0.02% (the one with the CX)

Stable 20 hours 4.8TH for both.

[bradli]

I have same problem. I cant get more 4550-4600 at 600 frei with 0.11-0.15 error
I tried reset and reboot and nothing.

581 frei

http://prntscr.com/8mmmv2

[edonkey]

Phil, you know how Bitmain warns that you need to turn on the hashing boards first and the controller last? None of us really want to deal with that, so I think this warning goes largely ignored.

Seems like a soft reboot would effectively be the same as turning the controller on last. All the hashing boards will be well powered on, then the reboot insures that the controller initializes much later.

Perhaps some rigs are more prone to the problem than others. Maybe some hash boards come up too slow or some controllers start up too fast and that results in an inter-component communication problem.

[philipma1957]

Phil, you know how Bitmain warns that you need to turn on the hashing boards first and the controller last? None of us really want to deal with that, so I think this warning goes largely ignored.

Seems like a soft reboot would effectively be the same as turning the controller on last. All the hashing boards will be well powered on, then the reboot insures that the controller initializes much later.

Perhaps some rigs are more prone to the problem than others. Maybe some hash boards come up too slow or some controllers start up too fast and that results in an inter-component communication problem.

yeah  I think this could be the issue.

I know I can create it with hard power off and then back on.  I know that if this gets done the errors jump to .1100   the gh drops 5-10%

and it does not correct itself even if given 10 -16 hours.

I know the soft boot fixes it.  But that is my gear.  Others have slightly different problems.

[marvykkio]

I think they are the chips that are inherently poor quality, a new miner just came out, already it has many problems of hardware errors.