vhater been doing that long time hehe
Yeah, the auto-renew failed...I had to intervene sorry guys
:)
hellcatz always there
cat never rest
hehehe
@dudezmobi
wondering if it's worth it to grunt it out... math says no
now.. if I somehow manage to get another 28 Z11's for free, I'll be back with hybrid again :-P
I will be giving a Hush reward out soon to make up for them.
The issue has also been resolved. Thanks for bringing this to my attention.
One thing I've noticed: For a couple weeks, my poolside reported hashrate was consistently higher than what my ASIC was reporting (on ZEN) and now it's the opposite... ASIC is reporting the same hashrate as ever, but now poolside is the same difference only to the negative (about 10 KSols less than ASIC reportage) ... I get that there is variance between the two measures depending on how many actual shares provided, but with GPUs I only noticed poolside being less, not more. Was I just lucky when I started and now I'm just regressing to the mean?
First, your miner knows how many "hashes" it has solved in a certain time window. So your miner will have a more consistent view of actual hashes solved.
The miner checks the "solved hash" if it meets the "share requirement" for difficulty and submits to pool if it does.
The pool has to "guestimate" what your hashrate is based on the difficulty and amount of shares submitted in a certain time window.
Since the miner will not "consitently" find shares perfectly timed apart, this is where you see the fluctuation on pool side.
For example, if your miner finds 20 shares in 10 minutes. Then in the next 10 minutes only finds 10 shares. You may see your hashrate drop almost 50%. on the pool.
Now, in the next 10 minutes, you may submit 30 shares... making the pool report a much higher hashrate.
This would result in the hashrate going higher than what your miner reports...
I hope that makes sense :smile:
It does... but the data to which I am referring is the 24hr line and it's pretty smooth until recently when it started angling downwards. Another thing that I have found is that, after a broadband outage, my Z11 needs rebooting as the hashrate is significantly less upon reconnection. I'm guessing that's because the outage throws off the autotuning algorithm it uses for frequencies and a reboot starts all assumptions from scratch
If you are overclocking the Z11, one of the hashing boards could be getting too hot, causing it to fault over time. I think you can check the status of the hashing boards on the Z11's admin config web page.
A little background info on the Z9M's and overclocking ...
I did buy some of the very first batch of the Z9M asics. They are great for overclocking. The later 2nd and 3rd batches were not nearly as good at overclocking (experienced more faults).
I did buy some of the very first batch of the Z9M asics. They are great for overclocking. The later 2nd and 3rd batches were not nearly as good at overclocking (experienced more faults).
I have not yet experimented with overclocking but board three is definitely and consistently autotuned to a lower freq (currently 731, 729 and 702 respectively) but weirdly does not correspond to comparative KSol/S(RT) rates (currently 43.9, 48.16, and 46.20 respectively currently but that changes of course).