Topic: [ANN] TeamRedMiner v0.10.10 - Ironfish/Kaspa/ZIL/Kawpow/Etchash and More - page 119. (Read 211877 times)

Hm, it is interesting though. I mean, I believe we _always_ submit stale shares rather than discard them, even though we know we just received a new job. This means you'll see them as rejected in TRM but not see them at all in e.g. stak. At the end of the day, the only interesting number is the accepted poolside hashrate, all other numbers can be dependent on different miner implementations and strategies.

For the "true" rejects, they should only be dependent on (1) pool policy for stale shares, (2) miner thread job runtime, (3) any additional overhead/latency in the network/miner.

(1) above has nothing to do with the miner, (2) should be very aligned between TRM and stak. (3) is a little interesting though. We refuse to steal any open source code, so we wrote our CN CPU verification from scratch in plain C code. It is def a lot slower than the AES-NI code in xmr-stak and others and could maybe be bumping the reject rate a little, but it shouldn't really be much.

So SCRYPTR, just curious if you see any difference if you disable the cpu verification with "--no_cpu_check"? I don't know if some pools have a window after sending out a new job where old shares are still accepted, but after 100ms they are rejected. If that's the case our slower cpu verification could very much be a factor.

On which pool are you mining? I've noticed Nanopool is way too strict with shares for new jobs that still are for same blockheight as the previous job. I really really wonder what they do with submitted shares for the previous job that matches the network difficulty...

You need to consider the lower power usage with TeamRedMiner. Atleast it's quite big difference between for example SRBMiner/XMR-Stak and TeamRedMiner. With TeamRedMiner I'll get around 1100 W with my rig, and with the other miners I gets around 1250 W, big difference! I have a mix of RX 560/570/580 and Vegas in that rig. I also are running a rig with some RX 550/560 and that rig saves only about 10 W.

EDIT: But I can agree with you about rejected shares. When looking right now at my bigger rig, it says 9691 accepted and 253 rejected. Seems very high.

TOO MANY REJECTS--

Your explanation makes sense and is mostly true, but I think the code needs to be refined to reduce rejects.  I stopped using TeamRedMiner for anything but my Vega cards.  There is solid improvement on my Vegas, maybe 30%, over XMR-Stak, but the rejects are still there.  My lesser RX series cards do not show real improvement on pool-side statistics.  The rig-side hash rate is higher, but after fees and rejects, pool-side is slightly less.

Smooth out the code please.  I am hoping to build more Vega rigs.  Your miner is good, but it needs some work.

Thanks for the good code, make it better!       --scryptr

Hi! Haha, hard to please everyone I guess . Well, if you really want to push more energy/heat, maybe you can find some better algo/miner for the purpose. Or, you can always try to push your Vega 56s a little higher with a higher core clk, maybe get a few extra hashes.

For the readings:

• CNv8: the total miner hashrate, including the dev fee.
• Avg: just the avg miner hashrate over time, smoothens it out a bit.
• Pool: this is your hashrate based on _accepted_ shares. Given enough runtime, it will converge to miner hashrate (CNv8) - 2.5% dev fee - rejected shares - any other downtime.

So, in a perfect world with zero rejected shares/pool issues/network issues, your pool hashrate should be 97.5% of the miner hashrate. However, shit will always happen. Depending on how your pool handle stale shares, it's realistic to assume 1-1.5% rejected shares. Some pools accept them anyway even though they are useless, and it'll show in your earnings anyway.

Just started using this miner over the weekend and its great. It's not very difficult to set up and is pretty stable for the most part. I was using castXMR before this and my result on CNV8 for 3 vega 56 was at around 4800-4900 sol/s with around 600 watts of power. Using TRM I am getting 5600 sol/s with and the same amount of power. This is all without using any soft power tables or any other mods. Testing using soft mods on one system and its gotten me 5700 sol/s with slightly reduce power draw of around 560-570 watts at the wall.

The only downside is that this thing does not run all that hot which normally be seen as great but seeing as i am using these miners to heat the house it does make it a little less convenient in that sense. Running cooler will make them really nice for the summer. Maybe I should just run a warmer algorithm instead and mine different coins for now?

My question for now are concerning the 3 readings you get; CNV8, AVG, Pool. They are almost the same with slight differences but the pool is a bit lower or sometimes higher. Can someone explain whats going on with those reading?

Thank you very much for the detailed response.

I’ve seen this quite a few times as well, on Windows.  Seems to just be another failure mode of insufficient voltage for chosen clocks.  And like other failures, it may often only present itself after hours, or even days of stable mining, due to the significant power transients (I assume.)

Can I ask if you're on Windows or Linux? What's happening is that one of the two threads for that gpu has gone nuts and is not executing the kernels as it should. I can't say why it has happened here though. If Windows, do you have enough swap space? On Linux, we've seen this happening as a pure driver issue, every third time you restart the miner one command queue just fails silently with this behavior.

This is Nicehash having switched to a new job and rejecting your share (which belongs to the old job). It will happen more often on Nicehash than when mining coins directly. Not much we can do here, we could potentially implement an abort pattern but you will lose hashrate anyway.

One of my vegas displays 3.267kh/s ?

Hey people! Tell me occasionally pops up such an error OS Windows 10,ati drv 18.3.4 Thank!

Oh, thanks for the clarification.

what are best possible cnv8 settings for power consumption/performance(hasharete) on rx570 and rx580 samsung K4G80325FB?
777000000000000022CC1C00CEE55C46C0590E1532CD66090060070014051420FA8900A00300000 012123442C3353C19
1300mhz gpu?

The "pool" hashrate displayed is an average just like the "avg" hashrate displayed is.
Both are averaged over the time the miner has been running, so they should track each other, as they seems to be doing.

Another mistake. Mining time and hashrate of maps is no longer displayed. Only sent jobs and balls are displayed.

So, my internet died for some reason for 8 hours.

After it came back, and few hours of mining, i see this:

http://i67.tinypic.com/25zs5tj.png

The Miner reported seems OK, the AVG seems OK, considering 8H of 0H/s.

But the pool reported does not seem ok. Why is that?

reboot.sh -

Sorry for the confusion, the support is read-only for now. We don't support setting fans or clocks, only reading them for display and watchdog purposes.

release notes say

Added support for fan speed and temperatures.

but i could only find way to hit up on min and max temp commando, how do i lets say hit fans of Vega at 80%