Topic: Efudd Z-Series Fuddware 2.3 -Z11/Z11e/Z11j/Z9/Mini - page 36. (Read 45536 times)

Some boards can not hold overclock. It is rare, but it happens. Your pictures are also small and blurred so I cannot make out a lot of detail. At least in your second picture the pool side average is 54 to 55. That's even with whatever dips you are seeing.

It seems that your miner side average is 55 and your pool side average is 54 -- this looks good. Your pool side dips could be any number of reasons, including random network or pool issues.

The real time is not important -- it is your average (and ultimately the pool side average and share submission rate) that is important. If you are staying in the ~55kSol range and your boards are not dropping, then you are in a good place.

I have 1 board that I constantly have to reset as it goes to 0 -- it's on one system and does not happen on the others. One day it will be fine at 650, the next day it only wants 643. I cannot explain these things.

Jason

Where are you trying to download from? What IP address?

https://releases.broked.net/

There is not anything wrong with the server.

Thank you,

Jason

Hi There,

I've downloaded the non-paid dev-fee version of the firmware 2.0d.
My chain1 of 16 asics seems to work fine at 643frequency(drops at 650) while the other 2 cores work well at 650frequency. I was wondering if the system is stable with these settings as i get some serious dumps in hashrate at the zhash pro pool for ZenCash. After a while i catched the system going to 30k/sols and all the cores falling to 10k/sols each in the miner status and then after two minutes they regain their 19k/sols average values.

https://b.radikal.ru/b01/1811/a8/bd51cfc5454b.png

This is my average hashrate when everything is fine.

https://d.radikal.ru/d00/1811/a2/5c5e29edaec6.png

These are the dumps i noticed on the zhash pool. As soon as i catch the cores fall again to 10k/sols in the miner status on your firmware ill try and get a screenshot and post it here.

Is there anything to resolve these issues? I was trying the cores at higher frequency but they were falling to 0k/sols and this is their "stable" clock. The only "bad" thing is that i assume they fall to 20-30k every now and then during a 24hours routine which is not working for me, previously i was using your 575 freq trial, i didn't have any problems with that firmware,

Cheers,
Igor

EDIT* My machine is from batch1.
It has been running smoothly with 575 freq with 91C on the chip with your trial version. Ive made adjustments to make the temp cooler for the new firmware update 2.0d and the chip temps are now 73C/68C/71C for all the chains respectively.

EDIT1: So i was expecting all of the asics to fall at 10k/sols each to a total of 30k/sols what i ran into after tracking the asic average speed for several hours is this:
https://d.radikal.ru/d21/1811/9d/be99a3bcd37e.jpg

OP first post has a link but i am unable to download....
" Time out Error"

Is there another link or possible method to download?

Me too

Me too.

https://releases.broked.net/ - the server was down on accident for http but was running for https. I apologize.

Jason

Jason!

I, as a z9 mini user, are also ready to pay for the firmware.

>"soon". and not one moment before.
>Sorry folk, it is what it is -- I'm focused on getting the paid users update first.

>-j

"soon". and not one moment before.
Sorry folk, it is what it is -- I'm focused on getting the paid users update first.

-j

Jason!

When do we wait “ cooming soon “  with z9 mini?

Hello, version 2.0d is linked at the beginning of this thread.

Thank you.

Jason

Now I am connected to the nicehash pool without #xnsub. With such a connection, rejected are much smaller than with #xnsub. And even with so many deflected ball, the profit is greater than when connected to the flypool. By the way, when you connect to the Japanese server, reject much smaller..

Yeah, I've been through that, and the patches. The extranonce stuff actually appears to be working just fine unless there is something wrong in the calculations of the returned results. I have two traces that are exactly the same (as best I can tell) except for the work requested to be performed. nonce's the same, etc... one works, the other doesn't on NH.

When I connect to some of their stratum, they provide extranonce information back, on some they don't.... I may do a set of tests tomorrow without #xnsub and see what happens.

Here is an example -- one of NH's servers did provide me an extranonce setting:

{"id":null,"method":"mining.set_extranonce","params":["0000908e00"]}

Yet that format does not match their specification. It should have a second parameter option of '5' per their own documentation... I just don't know at this point in time.


Thank you for providing the link!

Jason

Maybe this information will be useful: https://www.nicehash.com/help/patches-for-extranoncesubscription?lang=en

Ok, thank's. I hope that will solve the issue.

I've started collecting data on what is going on with nicehash. I'm going to have to contact them because I do not see obvious explanations for the failures. extranonce is supported by this firmware, it just does not function properly sometimes. I have just submitted the traces to nicehash to try to get some assistance in  understanding why this works sometimes, and fails sometimes.

Thank you,

Jason

Jason.
Can you see my request? https://bitcointalksearch.org/topic/m.47606596
Thank's.

The ban, I think, was due to API calls -- it has since been lifted and flypool is communicating with me on the concern now.

Jason

Sorry folk, I've been trying to track down a bug and have been distracted the last couple of days.

Unfortunately the bug is with flypool -- rather, I hope it is a bug. There are conditions where flypool will acknowledge receipt of a valid share and never associate it with your wallet. I have no idea what wallet it goes to, but it isn't the one configured and accepted.

That is bad, very very bad.

I posted this on a zcash/flypool thread:
--snip--
Why does flypool not follow the stratum protocol when it comes to mining.authorize? Per the protocol, a single connection should allow multiple mining.authorize calls. Flypool does not follow this, and worse, with some finagling, it will provide a valid authorization for more than one wallet, but never pay out, all the while returning “true” to the submitted shares. Which leads to my next question…

Why does flypool accept shares for wallets and then never associate the shares with the wallet? The simplest case is one where you mining.authorize walletA but perform all of the mining.submits with walletB.

In that scenario, flypool acknowledges the share acceptance for walletB, but never pays walletB. Where do those shares go? Who is keeping them? Why does flypool respond with an acceptance of the shares?

I’ve been using flypool a while and recommending it strongly, but until I can understand this behavior, I can no longer make that recommendation.

This is how flypool responds to a mining.submit with an address it did not accept as authorized:
{“id”:2001,“result”:true,“error”:null}

This is how a proper pool should respond to a mining.submit with an address not authorized:
{“id”:6,“version”:“2.0”,“result”:false,“error”:[24,“Unauthorized User”,null],“Notification”:{“method”:"",“params”:null}}

The difference is in the first case, flypool seems to take the share. Are there other conditions where flypool silently takes shares?

While trying to investigate this, I was banned from the flypool API.
--snip--

I've tried to reach out to them, but for the time being I am personally going to remove work from flypool until I can get an explanation.

Thank you,

Jason