Quick Question. So from what I gathered, I need to do the following:
1. Load the Z11StockSSHNoSignature.zip onto an sd card, turn off the miner, load the SD card in, and boot the miner up
2. Via the web interface, flash the EFUDD Z11_2.3.tar.gz firmwawre
3. Changes settings to whatever you want
Is this correct?
Topic: Efudd Z-Series Fuddware 2.3 -Z11/Z11e/Z11j/Z9/Mini - page 13. (Read 45527 times)
Folk,
I am pleased to announce that Z11 users of Fuddware(tm) who mine on Luxor (http://mining.luxor.tech) will never have dev-fees! This will be the equivalent of a paid release for no additional cost on your part. Luxor supports ARRR, ZEC, and ZEN for Equihash ASIC miners.
This feature will be coming to Z9 and Z9Mini users soon.
-j
I am pleased to announce that Z11 users of Fuddware(tm) who mine on Luxor (http://mining.luxor.tech) will never have dev-fees! This will be the equivalent of a paid release for no additional cost on your part. Luxor supports ARRR, ZEC, and ZEN for Equihash ASIC miners.
This feature will be coming to Z9 and Z9Mini users soon.
-j
Hahahaha
Think what you wish....I am done arguing with you too because your always right.
“you’re”.
HTH.
-j
Think what you wish....I am done arguing with you too because your always right.
The log you seen was me firing up an old z9 mini to take your crap off and use one of my images so your claim of hacking the pk file is old and been gone thru months ago with you, so I dont know why you still wanna talk shit. I guess thats your nature to keep on and on and on and in the end its gonna bite you in the ass. Seems you like to go out of your way to try to stir shit up and thats ok as long as you want to keep on I am gonna keep on your images ...
Still an idiot who does not understand PKI among many other things. The cert name sent from your IP was not one I ever used (“Z9MINI-PAIDSUPPORTEDUSERS”) and was signed at almost 10,000 days expiration, which is also something I haven’t used. The certificate hash is also one I never used. You are clueless since the technology exposes your lies directly, so no, not talking “shit”, talking fact and far far far from stirring shit up, dumbass. Remember months ago when you sent me a PM a threatening me with legal action if I didn’t stop using your name that YOU posted publicly yourself? See, I honored and respected that and have never said your real name in public since, yet you immediately went on to try to “dox” me yourself. I ignored every bit of that as well which is a far cry from “stirring shit” and is in fact the opposite.
Just the act of you trying gives away a lot of detail about you, your knowledge, and your methods.
I mean, you did forensics stuff, by your own claim. Although I expect it was just writing shit into a logbook or mopping the floors where the logbooks were stored.
You are beyond clueless.
-j
The log you seen was me firing up an old z9 mini to take your crap off and use one of my images so your claim of hacking the pk file is old and been gone thru months ago with you, so I dont know why you still wanna talk shit. I guess thats your nature to keep on and on and on and in the end its gonna bite you in the ass. Seems you like to go out of your way to try to stir shit up and thats ok as long as you want to keep on I am gonna keep on your images ...
Chipless / Efudd.... you kids better start getting along or we're not going to Disneyland 
Can we at least go to the water park??
-j
Chipless / Efudd.... you kids better start getting along or we're not going to Disneyland
fast question...Z11 is at housing so i cant get a look...but did i need mini sd or micro sd for flashing?
micro -- flash the SSH base image first... if there is demand I'll package this up into a direct-SD installable image... but the SD based install is really a one-time thing, so I figure the one image is enough to keep it simple.
-j
fast question...Z11 is at housing so i cant get a look...but did i need mini sd or micro sd for flashing?
Z11 2.3 / Full Frequency/Voltage controls per hash board.
- Tuning guide coming soon.. high level summary below.
- This includes everything from my past releases and adds Z11+Voltage per hashboard.
150k+ should be doable with minimal tuning.
170-180k is doable with multiple power supplies (or a big honkin' one), careful tuning, good cooling, and some luck.
Wattage has not been measured at this point in time due to hardware limitations at my testing site. Feedback welcomed.
https://releases.broked.net/Z11_2.3.tar.gz
MD5SUM: dcaba5458537da6c8ce7e14b5f7795bc Z11_2.3.tar.gz
SHA256: fe7cf284d6811f97f7f826e30bd780b987b697220e1ba9597b087f14b8371252 Z11_2.3.tar.gz
To install this image you need to already be unlocked. You can use my unlocked base image to boot from SD card and then install this. Going forward, all images will be installable via web after the initial baseline SD card installation. SD image: https://releases.broked.net/Z11StockSSHNoSignature.zip
Stock image installation instructions are available in post#672 on my primary thread: https://bitcointalksearch.org/topic/m.50664518
I will write up a more complete tuning guide soon as it is a little complex, but for starters:
Tune your frequencies as usual (instructions on the frequency page) on the stock voltages.
Once you understand how your system is operating, increase the frequency, bump the voltage up, rinse/wash/repeat.
Global settings apply to all hashboards.
Per-hashboard applies to... you guessed it, the individual hash board.
It is possible to overrun a single APW7 by tuning voltages -- symptom there is the unit will just reset.
Drop voltages by 5mV per board until you find your maximum.
As usual, run fans manual, 75% or higher. Try to keep temps 85C or lower.
If you add too much voltage, you'll just add heat.
If you don't have enough voltage for a given frequency, the hash boards will go into limp mode (~10-15kSol/each).
If you push too much voltage/frequency, the hash boards will go into the same limp mode.
Somewhere around 781Mhz/940-960mV should get you a good ~150-155kSol.
Sometimes a lower frequency will work better for a given system.
Maximum frequency is 825Mhz -- my stuff will let you set whatever you want, but I've yet to get anything beyond what I call limp mode above 825Mhz.
This release has no dev-fee for the near future, but will probably end up with a single 20 minute mining session once a day to support additional development/testing/blahblah.
As usual, a license is available if you want to go that route and never have any dev-fees, do the PM thing and we can discuss.
Back porting to Z9/Mini is still under evaluation -- nothing to really speak of there for a variety of reasons.
EDIT:
I am pleased to announce that Z11 users of Fuddware(tm) who mine on Luxor (http://mining.luxor.tech) will never have dev-fees! This will be the equivalent of a paid release for no additional cost on your part. Luxor supports ARRR, ZEC, and ZEN for Equihash ASIC miners.
Thank you,
Jason
- Tuning guide coming soon.. high level summary below.
- This includes everything from my past releases and adds Z11+Voltage per hashboard.
150k+ should be doable with minimal tuning.
170-180k is doable with multiple power supplies (or a big honkin' one), careful tuning, good cooling, and some luck.
Wattage has not been measured at this point in time due to hardware limitations at my testing site. Feedback welcomed.
https://releases.broked.net/Z11_2.3.tar.gz
MD5SUM: dcaba5458537da6c8ce7e14b5f7795bc Z11_2.3.tar.gz
SHA256: fe7cf284d6811f97f7f826e30bd780b987b697220e1ba9597b087f14b8371252 Z11_2.3.tar.gz
To install this image you need to already be unlocked. You can use my unlocked base image to boot from SD card and then install this. Going forward, all images will be installable via web after the initial baseline SD card installation. SD image: https://releases.broked.net/Z11StockSSHNoSignature.zip
Stock image installation instructions are available in post#672 on my primary thread: https://bitcointalksearch.org/topic/m.50664518
I will write up a more complete tuning guide soon as it is a little complex, but for starters:
Tune your frequencies as usual (instructions on the frequency page) on the stock voltages.
Once you understand how your system is operating, increase the frequency, bump the voltage up, rinse/wash/repeat.
Global settings apply to all hashboards.
Per-hashboard applies to... you guessed it, the individual hash board.
It is possible to overrun a single APW7 by tuning voltages -- symptom there is the unit will just reset.
Drop voltages by 5mV per board until you find your maximum.
As usual, run fans manual, 75% or higher. Try to keep temps 85C or lower.
If you add too much voltage, you'll just add heat.
If you don't have enough voltage for a given frequency, the hash boards will go into limp mode (~10-15kSol/each).
If you push too much voltage/frequency, the hash boards will go into the same limp mode.
Somewhere around 781Mhz/940-960mV should get you a good ~150-155kSol.
Sometimes a lower frequency will work better for a given system.
Maximum frequency is 825Mhz -- my stuff will let you set whatever you want, but I've yet to get anything beyond what I call limp mode above 825Mhz.
This release has no dev-fee for the near future, but will probably end up with a single 20 minute mining session once a day to support additional development/testing/blahblah.
As usual, a license is available if you want to go that route and never have any dev-fees, do the PM thing and we can discuss.
Back porting to Z9/Mini is still under evaluation -- nothing to really speak of there for a variety of reasons.
EDIT:
I am pleased to announce that Z11 users of Fuddware(tm) who mine on Luxor (http://mining.luxor.tech) will never have dev-fees! This will be the equivalent of a paid release for no additional cost on your part. Luxor supports ARRR, ZEC, and ZEN for Equihash ASIC miners.
Thank you,
Jason
Since the dev pool stay in place even when not being used, if the primary pools are not reachable or otherwise have some connectivity issue, cgminer will automatically fail over to another pool. There is a chance in that scenario that it could make it to the dev pool.
However, when the primary pool recovers, cgminer should automatically switch back within 5 minutes of identifying the pool as responsive again (it has a 5 minute holdback timer to make sure things stabilize).
This scenario could be what you have seen. There should be clear indication in the logs if this were the case.
Regardless, please do let me know if you isolate things any more. I am definitely interested in ensuring everything acts as expected.
Thank you,
Jason
However, when the primary pool recovers, cgminer should automatically switch back within 5 minutes of identifying the pool as responsive again (it has a 5 minute holdback timer to make sure things stabilize).
This scenario could be what you have seen. There should be clear indication in the logs if this were the case.
Regardless, please do let me know if you isolate things any more. I am definitely interested in ensuring everything acts as expected.
Thank you,
Jason
Hmm. How convenient...was that another mistake to mine for you if they cant reach their own server rather then let it go idle and save the power. WOW....That sounds like a Bitmain trick. Something else you ust forgot to tell your users. Whats that now about 5 or 6 things that were in your releases that you just forgot to mention. Sounds like some of your users need a refund to pay for that extra electric you used from them
Lol. Yeah, default cgminer behavior; it’ll go to an alive pool. Equal probability by default of going to any other configured pool.
EDIT: also, default cgminer behavior when network is down is to ramp fans to 100% and power is not shut off.... so by default it eats power doing nothing. You do not understand the product and tooling you are working with at all.
-j
Since the dev pool stay in place even when not being used, if the primary pools are not reachable or otherwise have some connectivity issue, cgminer will automatically fail over to another pool. There is a chance in that scenario that it could make it to the dev pool.
However, when the primary pool recovers, cgminer should automatically switch back within 5 minutes of identifying the pool as responsive again (it has a 5 minute holdback timer to make sure things stabilize).
This scenario could be what you have seen. There should be clear indication in the logs if this were the case.
Regardless, please do let me know if you isolate things any more. I am definitely interested in ensuring everything acts as expected.
Thank you,
Jason
However, when the primary pool recovers, cgminer should automatically switch back within 5 minutes of identifying the pool as responsive again (it has a 5 minute holdback timer to make sure things stabilize).
This scenario could be what you have seen. There should be clear indication in the logs if this were the case.
Regardless, please do let me know if you isolate things any more. I am definitely interested in ensuring everything acts as expected.
Thank you,
Jason
Hmm. How convenient...was that another mistake to mine for you if they cant reach their own server rather then let it go idle and save the power. WOW....That sounds like a Bitmain trick. Something else you ust forgot to tell your users. Whats that now about 5 or 6 things that were in your releases that you just forgot to mention. Sounds like some of your users need a refund to pay for that extra electric you used from them
Since the dev pool stay in place even when not being used, if the primary pools are not reachable or otherwise have some connectivity issue, cgminer will automatically fail over to another pool. There is a chance in that scenario that it could make it to the dev pool.
However, when the primary pool recovers, cgminer should automatically switch back within 5 minutes of identifying the pool as responsive again (it has a 5 minute holdback timer to make sure things stabilize).
This scenario could be what you have seen. There should be clear indication in the logs if this were the case.
Regardless, please do let me know if you isolate things any more. I am definitely interested in ensuring everything acts as expected.
Thank you,
Jason
However, when the primary pool recovers, cgminer should automatically switch back within 5 minutes of identifying the pool as responsive again (it has a 5 minute holdback timer to make sure things stabilize).
This scenario could be what you have seen. There should be clear indication in the logs if this were the case.
Regardless, please do let me know if you isolate things any more. I am definitely interested in ensuring everything acts as expected.
Thank you,
Jason
...snip...
Just a data point regarding this: I've noticed several occasions where my Mini has continued to mine for a few hours, but is not mining my pool. I know it has happened with Prohashing multiple times, and I think at least once on Flypool. To the best of my knowledge, its been maybe 5-10 times since 2.1d came out, but I've never spent time on it or looked into any further - I've just restarted and it fixes itself (though that is actually adding some dev mining on restart).
Just a data point regarding this: I've noticed several occasions where my Mini has continued to mine for a few hours, but is not mining my pool. I know it has happened with Prohashing multiple times, and I think at least once on Flypool. To the best of my knowledge, its been maybe 5-10 times since 2.1d came out, but I've never spent time on it or looked into any further - I've just restarted and it fixes itself (though that is actually adding some dev mining on restart).
One thought...
There is a new antminer malware that does not infect the miner directly, but instead uses the API to change the mining pools and runs from another infected computer (at least that is what it appears so far). It uses flypool for the mining. I haven't managed to get a copy of the malware yet to figure out exactly what it is doing, however. I confirmed this on another customer's system yesterday and implemented a temporary workaround for that user.
If you happen to be using awesomeminer, you will be able to tell if this is happening to you because all of the pools will disappear except the malware pool.
If you'll catch me on discord, we can troubleshoot it together and see what is going on.
Thank you,
Jason
I have two Z9 Minis running - one with your firmware and one without. This issue only occurs on the one with your firmware. I don't use AwesomeMiner or any other software to monitor, track, etc. It happens when I am mining on prohashing and I could be mistaken, but I thought at least once when I was mining on flypool. I never tried to see where it was actually mining or any other info; I just restarted and moved on. It hasn't been a big enough deal to date for me to worry about - just thought it might be useful info for you if others run into the same issue. Until it happened while I was mining flypool, I assumed it was probably issue on Prohashing's side. And since I'm not 100% sure it did occur mining flypool, I'm still not ruling out that its a Prohashing issue.
I dont need luck ....I do have skills, ida and forensic software from when I processed evidence for law enforcement it can get me into most everything I need to without doing harm to the file systems. Am kind of curious why all the excuses you have for not releasing the Z11 of yours
Well I am past the first signature check for the whole image the one I am working on is the info file signature. We will see how far I can get with it. You never know .....It would pass also except I had to add a new md5 for the files I modded. I have a way to change files in the image without extracting any of it.
Lol. In this case, yes, I do know how far you will get with it. Just when I thought you were actually showing some promise...
There is an md5+signature chain signed by a private key out of a PKI infrastructure. The chain is solid from the image to the installer+metadata. The image is signed, the installer/metadata is signed.
As I said, unless you suddenly have the private key, or have suddenly become a real hacker-type and can find, write and exploit a buffer overflow in the API, you are not getting around anything other than by using the SD card method.
All you have got past is a conditional check in the shell to see if an expected filename exists. That's it.
Sigh. Really.
-j
When are you going to learn to expect the unexpected from me.....I recall when I posted the Z11 firmware you called it "hacked up bullshit" that i didnt overvolt anything and was posting bullshit stats. Then went onto.....
"I’ll tell you what, I’ll give you a special image that disables the autotuning so you can see how wrong you are with your claims." Well I am waiting for the image still....
You were wrong then and may be wrong again I guess the future will tell. But I wouldnt under estimate things, just because I dont do things your way doesnt mean I dont get positive results in the end. Think out of the box man and you might get things done.
edit...
I must be doing something right 2 weeks ago my hashrate was 455 today this is where I sit on flypool. Looks to be about a 25k increase between the 2 machines
Hashrate
478.5 KH/s 481.5 KH/s
Cute. Good luck with that.
-j
Well I am past the first signature check for the whole image the one I am working on is the info file signature. We will see how far I can get with it. You never know .....It would pass also except I had to add a new md5 for the files I modded. I have a way to change files in the image without extracting any of it.
Lol. In this case, yes, I do know how far you will get with it. Just when I thought you were actually showing some promise...
There is an md5+signature chain signed by a private key out of a PKI infrastructure. The chain is solid from the image to the installer+metadata. The image is signed, the installer/metadata is signed.
As I said, unless you suddenly have the private key, or have suddenly become a real hacker-type and can find, write and exploit a buffer overflow in the API, you are not getting around anything other than by using the SD card method.
All you have got past is a conditional check in the shell to see if an expected filename exists. That's it.
Sigh. Really.
-j
When are you going to learn to expect the unexpected from me.....I recall when I posted the Z11 firmware you called it "hacked up bullshit" that i didnt overvolt anything and was posting bullshit stats. Then went onto.....
"I’ll tell you what, I’ll give you a special image that disables the autotuning so you can see how wrong you are with your claims." Well I am waiting for the image still....
You were wrong then and may be wrong again I guess the future will tell. But I wouldnt under estimate things, just because I dont do things your way doesnt mean I dont get positive results in the end. Think out of the box man and you might get things done.
edit...
I must be doing something right 2 weeks ago my hashrate was 455 today this is where I sit on flypool. Looks to be about a 25k increase between the 2 machines
Hashrate
478.5 KH/s 481.5 KH/s
Well I am past the first signature check for the whole image the one I am working on is the info file signature. We will see how far I can get with it. You never know .....It would pass also except I had to add a new md5 for the files I modded. I have a way to change files in the image without extracting any of it.
Lol. In this case, yes, I do know how far you will get with it. Just when I thought you were actually showing some promise...
There is an md5+signature chain signed by a private key out of a PKI infrastructure. The chain is solid from the image to the installer+metadata. The image is signed, the installer/metadata is signed.
As I said, unless you suddenly have the private key, or have suddenly become a real hacker-type and can find, write and exploit a buffer overflow in the API, you are not getting around anything other than by using the SD card method.
All you have got past is a conditional check in the shell to see if an expected filename exists. That's it.
Sigh. Really.
-j
Jump to: