|
Sigh.
A broken clock is correct twice a day.
I give up.
-j
|
|
|
|
|
Your ignorance tests the heck out of my patience.
change the line from:
if [ ant_freq_user > "776" ]; then {
to
if [ ${ant_freq_user} -gt 776 ]; then {
The first is comparing a non-evaluated variable name to a string called "776".
The contents of ${ant_freq_user} are *NOT* being substituted in on that if. They should be.
The one I gave you actually compares the _value_ you've assigned to ant_freq_user as a numeric comparison to the number 776... which is what you really want.
I don't know how you function.
-j
|
|
|
|
Stop being hard headed.
The test for: if [ blah > “776”.. is a fail always comparison on that line.
You need to treat that as a variable and access the value itself. That is $blah.. or ${blah} as many will use
-j
> 776 runs 1 command and if its over 776 runs something else. Not too hard to understand. Right now because of the typo it may set a blank line if you bypass otherwise you just type in what you want and save and all is ok. If you try to bypass then you get what you get. The 3 typos are fixed already took 2 minutes. Also the typos didnt stop you from mining it only set the wrong value in a config file which the web gui uses not cgminer. In the end all that matters is the ability to control the freq and voltage, I dont think users care how I coded it. Maybe I kept it a cluster fuck to confuse people and something more is going on, never know. I can always add some encryption but why I honestly don't know why I try to help you. YOUR TEST WILL ALWAYS GO TO THE SECOND CONDITION, *_NEVER_* THE FIRST CONDITION unless you make it a variable by simply prepending the test with a $. that's it, That's all I'm trying to say. I'm trying to explain a _bug_ in your implementation. .... and "maybe i kept it a clusterF to confuse people" is laughable. Go have whomever wrote your javascript fix your shell scripts; they will have better luck. ... also, it is impossible to fix the race condition in monitorcg, so no, you have not fixed it. -j |
|
|
|
|
Stop being hard headed.
The test for: if [ blah > “776”.. is a fail always comparison on that line.
You need to treat that as a variable and access the value itself. That is $blah.. or ${blah} as many will use
... and stop with the bullshit of “more speed less power” as you are delusional or consciously lying.
-j
|
|
|
|
|
@chipless -- what a complete clusterF your 2.2 release is. Here are the things you need to fix before you take money from folk..
rm /init (useless 0 byte file)
/etc/init.d/cgminer.sh - your "antminer" virus fix is broken. I told you about this a month or more ago. it is ".antminers", not ".antminer"
/etc/init.d/bitmainer_setup.sh - same thing.
/www/pages/cgi-bin/set_miner_conf.cgi: line 127 - your comparison (which is the difference between your private/public) for "ant_freq_user" > 776 is broken. In the current state, it will _always_ fail.
/www/pages/cgi-bin/set_miner_conf.cgi: lines 154, 155 -- you can't even spell your own variables correctly which makes all of your frequency selections *BROKEN*. You are welcome.
/www/pages/cgi-bin/set_miner_conf.cgi: lines 127-179 are a complete cluster. Instead of re-using the same lines over and over again, just write /config/cgboot once, and then call it.
/www/pages/cgi-bin/set_miner_conf.cgi: lines 127-179 -- your implementation here creates a race condition which will cause multiple cgminers to run in certain conditions. This will wreak havoc on things. I'll leave it up to you to figure out what the race is, and how to fix it, but it *IS* there.
There's probably more, I didn't check the math on any of your attempts at hex conversion and I didn't check to see which of this is in use and which is crap you haven't cleaned up from previous attempts.
None of this is bullshit or trolling you, it is simply broken.
.... and if this is what your Z11 firmware looks like, what does the rest of your "modded" firmware look like?
Bonus points for the readers -- assuming he fixes all of this, no need to pay him for his "Nitrous" version or whatever as the only viable difference in his public/private version is the check on line 127 in set_miner_conf which simply checks to see if you, the user, have specified a frequency > 776, and if so, it simply sats the variables to a hard coded set.
-j
|
|
|
|
|
Yup... that is the format. What you are missing is it is only an intermediate step in frequency selection and not the end state. That is elsewhere.
Aka, it won’t work for providing a custom frequency.
The ONLY way is to bypass all of the stock functionality and replace it with custom code, linked in at runtime.... or hack in one frequency by editing the binary as you have been doing.
Really.
-j
|
|
|
|
That is what I figured on the boot.bin file. That is why I had left it out.
I get an open chips-freq.config open file failed message in the log. I have been playing with it for fun. I use part of the auto-tune and if the numbers arent in the right order for checking then you get 33k-100k at any freq. I just redid the file and am testing it.
I’ve told you the format of that file a few times now.... and all it does is save the previously tested autotune state. Aka, auto tune is still the controlling factor and decides what to set the frequency to, not the user. -j |
|
|
|
chipless - microcontroller saves previous voltage/frequency state in certain situations, which might begin to explain some of what you are seeing. It can serve to fool one into thinking that they've got control of freq/voltage, and then "not work" the next time around.
For Z11, the bitmain-voltage setting in the config file is *not* connected to voltage setting in their cgminer, nor is bitmain-freq connected to the frequency setting in their cgminer.
-j
Understand, the files and setting are still being used by my mods in a different way. I am wondering though if the boot.bin file needs to be updated on some miners. The 6/05 had a new boot.bin with it. My miners have been updated with it but i left it out of the package until I compare them. I havent compared them yet but will have to look in a minute. Most miners it is ok except a couple of them. I also may have to redo a few things to trigger the pic write that helped on older versions. I have one where I did relinked the chip_freq.config but cant seem to get the format correct in it. It reads and tries to select the freq but ends up back at 681 due to the file format Highly likely that it ends up back at 681 because of an autotune thread, not the format. BOOT.bin is not what you think it is if you think that helps with setting freq/voltage. It has absolutely nothing to do with the ASIC/PIC and is literally just about booting the FPGA/linux. Anyway, enough of me being helpful for today, back to my corner. -j |
|
|
|
any one know what happens on LUXOR Pool??, amount of ZEC is over to 0.1 ZEC and its wont go out to my wallet, right now amount is 0.18ZEC and still no transactions going out
Sometimes it happens on luxor pool. Contact support team, they will help quickly Luxor ZEC pool hit a known bug: http://github.com/zcash/zcash/issues/1823 -- that caused the delay in payouts and has been/is being resolved. -j |
|
|
|
|
chipless - microcontroller saves previous voltage/frequency state in certain situations, which might begin to explain some of what you are seeing. It can serve to fool one into thinking that they've got control of freq/voltage, and then "not work" the next time around.
For Z11, the bitmain-voltage setting in the config file is *not* connected to voltage setting in their cgminer, nor is bitmain-freq connected to the frequency setting in their cgminer.
-j
|
|
|
|
any one know what happens on LUXOR Pool??, amount of ZEC is over to 0.1 ZEC and its wont go out to my wallet, right now amount is 0.18ZEC and still no transactions going out
Please try Luxor support. -j |
|
|
|
|
ah cute. two bot's replying to each other (bobbafeet2k19 and dizzydancer1995). Go through their post history -- some of them are the exact same texts.
-j
|
|
|
|
For what it is worth, I get escalations due to minerstat overwriting configs. It seems folk don't realize that minerstat snapshots their configuration and re-applies it... I guess that is part of your workflow (control via web)? It is especially concerning when minerstat is installed before the customer has configured their machine completely and snapshots an older config.
-j
efudd, I had a feeling that you have understood how it works quite well when I've explained it to you on the Discord ~2 months ago. You are correct, minerstat is meant for remote management and so it does save the config on the first sync and then overwrites the config based on user's actions. Everything is managed remotely, this is why it's called remote management after all. Need to get used to it. Also, it doesn't really matter if minerstat is installed before customer has configured their machine or not, this shouldn't be a concern at all, because they can always change the config on the dashboard, that's not just normal and expected, but it's also the whole point of minerstat - the remote management. If users decide they will no longer use the software, they can easily uninstall it. So now you know how it works, please be kind enough and explain it to your users when they will ask you about it next time or feel free to forward them to us. They will get our full attention. Umm... yeah. Not sure what is up with the “get used to it” comment and tone. I couldn’t find the name of the person I spoke to for 60 seconds or so, a few months back, on discord about that. The conditions im aware of likely fall into the category of the user not understanding and just seeking stats. If I offended you, I apologize. -j |
|
|
|
I have contacted them directly and they do not provide them anymore.
Ah darn. What a company they are... I wonder if that isn't something included in the packing labels for units exported previously? In other words, maybe folk have what you are looking for but don't realize it. I don't have a Z9 box w/ labeling any more to look at, unfortunately. -j |
|
|
|
Does anyone have the above mentioned certificates for the Bitmain Z9's?
I am looking to buy some of these machines used, but the EU requires these certificates for import into the EU.
Thanks.
Try bitmain? |
|
|
|
Frequency settings in config are ignored and it autotunes. Please do not spread misinformation.
-j
If anyone is having issues with the frequency being locked, they can install any firmware as minerstat supports most of them. Including efudd firmware. However, we did tests, changed config was always accepted by the machine, but yes may it can be ignored because of autotuning. Good that you have pointed it out now. Thanks. Now I changed the default password ... and worked for 10 minutes ... now it's freezing.
You need to provide your changed password on the UI unless the machine is not available or controllable by our software. Default Web login is root/root. If you changed make sure you update on the website too. For what it is worth, I get escalations due to minerstat overwriting configs. It seems folk don't realize that minerstat snapshots their configuration and re-applies it... I guess that is part of your workflow (control via web)? It is especially concerning when minerstat is installed before the customer has configured their machine completely and snapshots an older config. -j |
|
|
|
... I'm not able to see anything on the GUI.
Use correct login info. Not SSH login, but Web login that you use for accessing your Antminer's interface. Default is root root (if you didn't change it). Z11 frequency cannot be controlled in factory firmware.
With minerstat you can control the frequency on official firmware. No, you can’t. Frequency settings in config are ignored and it autotunes. Please do not spread misinformation. -j |
|
|
|
I modified the frequency: "bitmain-freq" : "731"
I also tried 718 and 725 but unfortunately I'm not able to see anything on the GUI.
On Minerstat, the status of the mine is "undetected hardware".
On the dashboard I can see the consumption , but the hashrate is 0 h/s
On the workers I have uptime 0s and no hashing power
Z11 frequency cannot be controlled in factory firmware. -j |
|
|
|
what about this :
bm1740_verify_nonce_integrality CRC error. cal-crc=82ac, chip-crc=3f50
i got this on logs Z9 mini, do i need o worry about this?
Yes. Can ignore that too. |
|
|
|
|
Yeah, at this point I'm going to have to direct you towards luxor for support. They are very responsive. @NickH on the equihash discord is from Luxor.
I understand that eu is geographically closer. I'm suggesting trying -us to see if the routing there, and/or the server there, is more stable for you, independent of geography. Basic troubleshooting techniques where you change a variable, even if it might not make sense, and observe the result, and *then* make an informed decision.
-j
|
|
|
|
|
Show Posts
