Efudd Z-Series Fuddware 2.3 -Z11/Z11e/Z11j/Z9/Mini

[zeric]

Has anyone experienced problems running 650 mhz and up on the standard bitmain provided awp3 psu? The 1370 watt drawn at 650 mhz seems disturbingly close to the 1600w max on the psu since 1600 x 0,8 = 1280.

Typically, this is not the meaning of PSU power limit.

You can run 1300W PSU like EVGA with on-the wall reading of up to 1430W just fine.
i am not sure why you are multiplying 1600 by 0.8.
First, only the worst PSUs have 80% efficiency (maybe APw3 is one of them, i don't know), which is a Bronze level.
Second, PSU indication of 1300w (EVGA) or 1600 (APW3) usually means power output limit (to miner) and not power input (measured at the wall) AFAIK.

That said, maybe Bitmain got it backwards, who knows.

The 0.8 comes from the so called 80% rule. It states that while electrical wirering in general and psu's in particular are able to perform at a 100% at peak intervals, running it long term is not safe above 80% or perhaps with good quality components at 85%. While a few might have good experiences running at a 100% for a long while, the 80% rule is more or less generally accepted.

EDIT: Just to clarify, the 80% has nothing to do with efficiency.

[Biodom]

Has anyone experienced problems running 650 mhz and up on the standard bitmain provided awp3 psu? The 1370 watt drawn at 650 mhz seems disturbingly close to the 1600w max on the psu since 1600 x 0,8 = 1280.

Typically, this is not the meaning of PSU power limit.

You can run 1300W PSU like EVGA with on-the wall reading of up to 1430W just fine.
i am not sure why you are multiplying 1600 by 0.8.
First, only the worst PSUs have 80% efficiency (maybe APw3 is one of them, i don't know), which is a Bronze level.
Second, PSU indication of 1300w (EVGA) or 1600 (APW3) usually means power output limit (to miner) and not power input (measured at the wall) AFAIK.

That said, maybe Bitmain got it backwards, who knows.

The 0.8 comes from the so called 80% rule. It states that while electrical wirering in general and psu's in particular are able to perform at a 100% at peak intervals, running it long term is not safe above 80% or perhaps with good quality components at 85%. While a few might have good experiences running at a 100% for a long while, the 80% rule is more or less generally accepted.

EDIT: Just to clarify, the 80% has nothing to do with efficiency.

How 80% rule for home wiring relates to PSU?
80% simply means that on 15A circuit you should use no more than 12A continuously (derate 15A by 20%).
Many folks run EVGA 1300 at close to 100% for years (at certainly more than 100% of the nominal 1300 at the wall).
It's totally fine.

[zeric]

Has anyone experienced problems running 650 mhz and up on the standard bitmain provided awp3 psu? The 1370 watt drawn at 650 mhz seems disturbingly close to the 1600w max on the psu since 1600 x 0,8 = 1280.

Typically, this is not the meaning of PSU power limit.

You can run 1300W PSU like EVGA with on-the wall reading of up to 1430W just fine.
i am not sure why you are multiplying 1600 by 0.8.
First, only the worst PSUs have 80% efficiency (maybe APw3 is one of them, i don't know), which is a Bronze level.
Second, PSU indication of 1300w (EVGA) or 1600 (APW3) usually means power output limit (to miner) and not power input (measured at the wall) AFAIK.

That said, maybe Bitmain got it backwards, who knows.

The 0.8 comes from the so called 80% rule. It states that while electrical wirering in general and psu's in particular are able to perform at a 100% at peak intervals, running it long term is not safe above 80% or perhaps with good quality components at 85%. While a few might have good experiences running at a 100% for a long while, the 80% rule is more or less generally accepted.

EDIT: Just to clarify, the 80% has nothing to do with efficiency.

How 80% rule for home wiring relates to PSU?
80% simply means that on 15A circuit you should use no more than 12A continuously (derate 15A by 20%).
Many folks run EVGA 1300 at close to 100% for years (at certainly more than 100% of the nominal 1300 at the wall).
It's totally fine.

Because, to my understanding the 80% rule is not only applicable to home wirering but also to the psu itself. Check the link for more in dept explanation, especially the post by Philipma. According to him its about the psu output, not the draw at the wall though. So since apw psu is plat (right?) it would be 1600/0.92 = 1739. 1739 x 0.8 = 1391 or perhaps 1739 x 0,85 = 1478.
I would love to be wrong though

https://bitcointalk.org/index.php?topic=1971395.0

edit: just re-read. he says 80% rule for atx psu, not server psu. should be fine then

[Biodom]

Well, Phil is very careful (not a bad trait), however, you can run miners on EVGA G2 1300 close to 1300W usage by miners (with probably more than 1430W at the wall). See link in https://bitcointalk.org/index.php?topic=1971395.msg19620640#msg19620640

Absolutely no need of multiplication of 1300 by 0.8.
Whether Bitmains PSU can do the same, who knows.
I have run (in hosting) two S9 on a 2880W PSU with nary a problem, except, maybe when temp were above 35C, which is a temp limit for S9 anyway.

That said, the amperage in your circuit is a whole another story. There, 12A is the limit (instead of 15A).
Therefore, if you are on 110V, you cannot expect to run continuously at 1430W at the wall because it would be 13A.
The most you can do on 110V on a 15A circuit is 110X12=1320W (at the wall).

[efudd]

Folk,

Just a status update -- I have more hardware on the way so I can test and continue development on the per-hashboard overclock feature. I'm hoping to complete in in 24-48 hours after the hardware I have been waiting on arrives (maybe thursay/friday?). *IF* that all pans out, I should be able to add that feature to a firmware for the Z9 mini, also.

Thank you all for the support,

Jason

[efudd]

Orders today (10/08/2018) will be processed after 5:00PM Eastern time (GMT-4).

Thank you,

Jason

[srdjan]

Im using Efudd´s firmware on Z9 for three days now. It runs on 650mhz, and 56Ksol per unit. Temp is around 75c with 80% fans on one unit and 100% on second.No problems at all. The cooler the room is ,where they are, the better they work.
Great job, thank you

[Diman003]

At me after frequency 650 works only on 668 and 675:) on 668 more steadily works 56-60ks\s. Thank you Jason and waiting for new firmware

[APK22]

Interested in the firmware, could you PM me

Will pay you in Zcash. PM me your address.

[efudd]

Interested in the firmware, could you PM me

Will pay you in Zcash. PM me your address.

Responded.

[efudd]

Folk,

I wanted to post a quick update on the per-hashboard-frequency control modification (and associated functionality). The short version: no good progress as of 1:30AM Eastern on 10/13/2018.

The long version (which is a collection of random thoughts and probably won't make sense to many):

* Hardware was loaned to me (a Z9, thank you...) so I could continue some development work. This arrived on Wednesday.
* Since then I've been working on various methods to modify the firmware to extend functionality.
* The methods I normally would use for this are running into issues with bitmain's release. The basic gist is, it looks like they built things with gcc, and there is an issue I don't yet understand that prevents me from using my preferred method to extend functionality. If it were built with clang, this would be different...
* I've been at this more or less non-stop the last 36+ waking hours... and I'm going to take a break now....
* With some luck I'll have another good idea(s) on other ways to attack this... I've been through countless variations so far.
* The problem is not with knowing what to modify inside the firmware, it's with actually modifying things at run-time in system memory.
* The most challenging solution is: trace the hardware (via software and/or external devices), reverse engineer the hardware communications and extend public sources to support this BM1704 and PICF16704... the -DASH variant firmware has an older incarnation of the PIC control code... yet the comms endpoints are not correct.
* ... lots of other thoughts, but gonna pause for now.

What's next?

* Hopefully I get another good idea at attacking a highly esoteric problem...
* ... I have lots of improvement ideas for the firmware; things that would apply to all Z series and even future miners... but I must break through the current roadblock to get to any of those things.

More soon(ish).

Thank you,

Jason

[xPETEx]

Folk,

I wanted to post a quick update ....

Thanks for working so hard on this. We all really appreciate it! Good luck.

[Den4uktlt]

Hello, I want to buy firmware for Z9. Write me in a personal message please

[efudd]

Hello, I want to buy firmware for Z9. Write me in a personal message please

Responded.

[efudd]

Folk,

I wanted to post a quick update on the per-hashboard-frequency control modification (and associated functionality). The short version: no good progress as of 1:30AM Eastern on 10/13/2018.

The long version (which is a collection of random thoughts and probably won't make sense to many):

* Hardware was loaned to me (a Z9, thank you...) so I could continue some development work. This arrived on Wednesday.
* Since then I've been working on various methods to modify the firmware to extend functionality.
* The methods I normally would use for this are running into issues with bitmain's release. The basic gist is, it looks like they built things with gcc, and there is an issue I don't yet understand that prevents me from using my preferred method to extend functionality. If it were built with clang, this would be different...
* I've been at this more or less non-stop the last 36+ waking hours... and I'm going to take a break now....
* With some luck I'll have another good idea(s) on other ways to attack this... I've been through countless variations so far.
* The problem is not with knowing what to modify inside the firmware, it's with actually modifying things at run-time in system memory.
* The most challenging solution is: trace the hardware (via software and/or external devices), reverse engineer the hardware communications and extend public sources to support this BM1704 and PICF16704... the -DASH variant firmware has an older incarnation of the PIC control code... yet the comms endpoints are not correct.
* ... lots of other thoughts, but gonna pause for now.

What's next?

* Hopefully I get another good idea at attacking a highly esoteric problem...
* ... I have lots of improvement ideas for the firmware; things that would apply to all Z series and even future miners... but I must break through the current roadblock to get to any of those things.

More soon(ish).

Thank you,

Jason

Small update -- I got through the "wall" I was banging my head against when I wrote this update. I'm now "climbing the hill", which means slow but steady progress. I have a couple of infrastructure pieces to complete that are the more challenging components, and then I should be able to make some quick progress towards the per-hashboard frequency management.

More soon.

-j

[Den4uktlt]

Hello, I want to buy firmware for Z9. Write me in a personal message please

Responded.

You have exceeded the limit of 1 personal messages per hour. Buying a Copper membership may increase your limit.

[efudd]

Hello, I want to buy firmware for Z9. Write me in a personal message please

Responded.

You have exceeded the limit of 1 personal messages per hour. Buying a Copper membership may increase your limit.

I have responded to your email.

[Crypto305]

Folk,

I wanted to post a quick update on the per-hashboard-frequency control modification (and associated functionality). The short version: no good progress as of 1:30AM Eastern on 10/13/2018.

The long version (which is a collection of random thoughts and probably won't make sense to many):

* Hardware was loaned to me (a Z9, thank you...) so I could continue some development work. This arrived on Wednesday.
* Since then I've been working on various methods to modify the firmware to extend functionality.
* The methods I normally would use for this are running into issues with bitmain's release. The basic gist is, it looks like they built things with gcc, and there is an issue I don't yet understand that prevents me from using my preferred method to extend functionality. If it were built with clang, this would be different...
* I've been at this more or less non-stop the last 36+ waking hours... and I'm going to take a break now....
* With some luck I'll have another good idea(s) on other ways to attack this... I've been through countless variations so far.
* The problem is not with knowing what to modify inside the firmware, it's with actually modifying things at run-time in system memory.
* The most challenging solution is: trace the hardware (via software and/or external devices), reverse engineer the hardware communications and extend public sources to support this BM1704 and PICF16704... the -DASH variant firmware has an older incarnation of the PIC control code... yet the comms endpoints are not correct.
* ... lots of other thoughts, but gonna pause for now.

What's next?

* Hopefully I get another good idea at attacking a highly esoteric problem...
* ... I have lots of improvement ideas for the firmware; things that would apply to all Z series and even future miners... but I must break through the current roadblock to get to any of those things.

More soon(ish).

Thank you,

Jason

Small update -- I got through the "wall" I was banging my head against when I wrote this update. I'm now "climbing the hill", which means slow but steady progress. I have a couple of infrastructure pieces to complete that are the more challenging components, and then I should be able to make some quick progress towards the per-hashboard frequency management.

More soon.

-j

Great work!

[efudd]

Update:

Still working on this... was able to get through a hurdle that has had me blocked for the last couple of days today. Unfortunately a problem on the target board (with how bitmain has compiled their stuff) that I thought I had solved has reared its head. I was hoping to be able to put at least a picture of a system with hashboards at different frequencies tonight but it does not look like that is going to happen.

Will update as I can.

I apologize this next update is taking longer than I had hoped.

Jason

[alexis97]

I have responded to your email.

if you have time, look at my letter, this function will also be useful to you
so that the coolers do not scream when rebooting