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

Awesome update! Glad to hear that! Send me a PM and we'll work out details on license.

Thank you.

Jason

Just thought I would give you some follow up.  I updated with your firmware on 2 Z11J's, and they seem to operate at between 125K-135k sol/s, at 781mhz/920mv.  So at least for the purposes of the Z11J, it looks like they simply under clocked a regular Z11 somehow.  I actually have an option to get some Z11e at 70K sol/s for a reasonable price (relatively), and may order a couple to see if they did the same thing.  If I could get a Z11e to 125-135k sol/s I would have gotten it at nearly half price!

What is your price for licenses for say 5-10?

Thanks!

Unclear, to be honest. You'd have to give it a shot and try to see what you can get out of it. Stock voltage is 870. For Z11, you have to add voltage to get more hash with an increased frequency. With e/j, that might not be the case. My sample set is too small to speak for sure... regardless, it is firmware limited in that the stock firmware attempts to automatically tune things, and generally does not do that great of a job. It also limits the max voltage as well as the max frequency within the auto-tune range.

-j

I just received my Z11J, and they operate at a bit over 110K sol/s.  I see you added functionality for the Z11J but can you shed more light on how they are throttled?  Is it less chips or is it firmware limited?  If it is firmware limited, is there a way to turn it into a fully functional Z11 at 135k sol/s?

Thanks!

To be honest i've been using the efudd software for many months, love it.  Kudos.

2.3 and 2.3.1nh have been updated to support Z11/Z11e/Z11j.

Thank you,

Jason

HELLO
I am new here and i have one question about my Z9(not mini), i use the firmware from https://releases.broked.net but i get too much rejected shares on nicehash (about 70-80%), can anyone tell me if there is something i can do to fix this.
Thank you

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

Sometimes it happens on luxor pool. Contact support team, they will help quickly

Please try Luxor support.

-j

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

My apologies -- before coffee and I can absolutely have a strong response.

The relevant line in that log is quoted above... the rest is just cgminer reacting to that.

For the sake of testing, can you please try zec-us instead of zec-eu?
I'm not with luxor, but I know the luxor guys have been looking into things with the pool as I've raised this up but have not identified anything specific.

I know that the connections to the pools are monitored for changes -- meaning, if there was suddenly a 20% drop in users, that would kick off an alert and people would look into it. As best I know, that monitoring has not been triggered (and I made up the 20% number, I don't know what their triggers are) so the issue would likely be somewhat localized.

This example is one of network issue, and cgminer failing over to another working pool. I had previously "fixed" the failing over by setting the dev pool to an empty pool (dev.pool.disabled), but that just caused folk to complain that they were seeing messages in their logs that a pool could not be connected to. Can't win balancing that one.

This is definitely a network/pool side issue though. I cannot differentiate which one it is. The basic flow is this:

If the working pool cannot be communicated with
- cgminer switches to another pool
- cgminer continues to check for the primary pool to be functional
- once the pool is working for 5 minutes, cgminer switches back.

That is default functionality... and you can see the "stable for 5 mins" messages as well.

I'll point the luxor guys at the log you posted here and see if they can identify anything.

Again, I apologize for the tone -- I definitely mixed you up with the other couple of folk who were complaining but not even using luxor once we dug into the logs.

Thank you,

Jason

Logs.

Look, this is not hard. Provide data. That is it. Provide data, get a fix. Yay!

Simple. Easy.

EDIT:

Not sure what you are playing at here... but here is what I *CAN CONFIRM*, with *LOGS and TIMESTAMPS*:

On March 13th you purchased a license for 6 Mini and ran them without issue as best I can see.
On June 21st, you requested a free license for Z11 and Mini -- I informed you that the license offer was for Z11, but I'd go ahead and honor your request anyway.

I updated your pre-existing licensed to support 7 Mini and 1 Z11.

You added your pre-existing license to the Mini (31d56722-7bdb-11e9-9dcb-f23c917c34c5) on June 21st 2100GMT.
You added your pre-existing license to the Z11 (e847529c-7bb6-11e9-b4aa-f23c917c34c5) on June 21st 2100GMT.

For *BOTH* of these machines, the *LAST TIME* the server said "dev mode" was on June 20th at 15:11 GMT.

There has *NEVER* been another "DEV MODE" response for those machines since then.

So... *IF* you are having issues, the problem is *YOUR NETWORK*, *YOUR CONFIGURATION*, or something else on *YOUR SIDE*. What pool are they "switching to" to mine on? In your kernel log, please show the "Switching to pool" messages, with timestamps. Let's look at your configuration and environment and figure out what the heck you have going on.

In the end, I _guarantee_ the problem will not be something on my end. In fact... I'll work with you, directly, team viewer, or whatever, and monitor your systems for you, diagnose and diagnose whatever you are seeing. I will provide a detailed analysis of what is observed. In the end, if the problem is not on my side (it won't be), you simply pay me for me time at a very reasonable and heavily discounted $50/hr. If the problem is something on my end (it won't be), I'll pay you $200.

Deal?

-j

More
BREAKING: Cloudflare is currently having network problems, affecting LIHKG, hkgolden, @StandNewsHK among many other websites. Apparently there is an ongoing cyber attack coming from China.

references: https://twitter.com/hkdemonow/status/1146057382201458688 and https://www.cloudflarestatus.com/incidents/tx4pgxs6zxdr

This is as of 10AM Eastern time. This *WILL* impact many pools as cloudflare is used for distributed dns resolution, among other things.

This was impacting bitcointalk, just a few moments ago and is currently impacting discord.

So... if you have problems with your miners and pools, just restart your machine once the internet seems sane again before blaming anyone's firmware today.

Thank you,

Jason

This is getting old.

SupportID from status page... can’t troubleshoot crap without some information man.

Are you on Luxor?

Blah blah...

Thousands using with no problems each day.

So statistically... math says the problem is where?

Time for coffee.

EDIT: oh.. you are Supra? Good grief dude. Get a damned grip.

-j

Wow - First off EFUDD is the man THANK YOU SO MUCH FOR THE FIRMWARE RELEASE - BUT my unit was mining for you untill i reset it... 3 times now? were talking 12 hours straight and another time almost 24 hours? I thought my machine overheated and shutdown or something but now i see it just stayed on your pool indefinitely... IS this just a bug or efudd is there something i need to set? 

Is your pool definition set to stratum+tcp://whatever in the configuration page? If not, that is the problem.

EDIT: to clarify, I suspect your unit is not being detected as “on Luxor” so is going into dev fee mode. Adding the stratum+tcp:// to the beginning of your pool definition Should fix the detection. This is my best guess without a support ID.

Otherwise, pm me a support id from status page.

Thank you,

Jason

Hi,

I have only been running this firmware for 2 days so forgive me. I have 6 Z9's that I purchased used 2 of which accepted the firmware without the need for the SD card so I was testing them out before implementing on other machines. I continuously see both of these miners hash rates drop to 0 poolside (luxor) while in the local bitmain/antminer menu I see that I have my normal expected hash rates.

It doesn't make sense for this to be a pool side problem because my other 4 Z9's are not experiencing this issue and these miners weren't doing this prior to me switching the firmware.

Edit: Sorry I got sucked into trying to think about what it could be and never asked my question, that is, what seems to be the problem?

Nope. Automatic only.