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

Ace - thanks toddxx!

Team Red Miner v0.3.8 released

https://github.com/todxx/teamredminer/releases

Changes in v0.3.8

• Added support for fan speed and temperatures.
• Added watchdog function for gpu init stuck, dead gpu, over-temp gpu, and non-responding pool.
• Added new optional 'L' config prefix for low-end cards like lexa/baffin for a 10+% speed-up on some cards
• Added an option for writing out a log file.
• Added cycling through multi-entry dns records when connecting to pools.
• Added a pool-connect timeout.
• Added measurement and displaying of pool response times.
• Added support for 80-byte headers for Phi2 algo (for non-LUX coins).
• Slightly tuned the '+' mode for polaris, some GPUs will show slight performance increase.
• Fixed bug with API interface occasionally getting stuck.

Anyone running 550s and 560s should try out the new 'L' prefix for configs, this improves hashrates significantly on 8CU and 10CU cards.  Please see the tuning guide for more details on configs to try.

Within 5 mins. Not kidding.

Keep up the good work mister kerney666, when new release?!

You are paying more in electricity than the coins you're mining are worth.

If you can't mine profitably, don't mine. It's stupid. Turn your rigs off and wait for profitability to go back up. Doesn't matter whether you've invested in hardware or not. If you use it, you lose twice!

Absolutely, pool failover is the last big thing we’re missing (after the next release). We skipped it in the upcoming 0.3.8 version to not delay the release further, it will be in the next version after that.

First: Big Thanks for TRM

Second: Can you implement settings for an alternative pool, if the main pool die? It is really need in some situations.

It is not free, surely I wish it was. But since the equipment is already there, I let it mine, maybe the future is not so dark Also, I spent way to much effort to make everything run, just to shut it down now. Even if I am at heavy loss, I will keep mining until I feel better

The same way as on Windows.

Open the .Bat files included in the .ZIP and you can see examples.

Where algo is cnv8 OR phi2, and the the pool is Stratum type.

At the weekend there was little time for experimentation. I installed Linux and downloaded the timredminer and realized that I have no idea how to start it. Therefore, I need advice.

Can you add a simple exit option on watchdog trigger?  This allows a really basic 'wrap miner w/ a goto' routine in the startup bat itself.  I can see the need for an call-out to another script, as the failure mode on this is still pretty gnarly, but i would always want to start w/ the simplest option if possible.

Even w/ rates of $0.12/kwh, well tuned 64s are still pulling in about $0.25/day profit w/ this miner.

I am curious how you can continue mining in bear climate like this.....unless your energy is free!!

What is minimum driver required under Linux for Polaris and Baffin cards ?
I'm running HiveOS and have 0H/s without error in log file.
Running great with my Vegas

We are getting close to the 0.3.8 release, watchdog is ready, it catches init errors and stuck gpus and runs a user-defined bat/.sh file. Log file support is simple, todxx is adding it today I think. The watchdog will log the GPU and pci bus id before attempting to run the user script. For now there is only one script, maybe we want to run different scripts for different events. A hung gpu might want a full reboot, the init error with zero hashes might only want a simple restart.

We've also added debug logging, temp/fans/clocks/etc for windows incl watchdog check for temp, I'm about to add temp/fans for sysfs under linux today as well. Also a number of small fixes.

Last, there is a few small tweaks that could/should lead to increased performance for some cards. More on that in the release notes.

Txs Kerney! I think when we got watchdog in 0.38, most of miner's problem will be solved :-) It is OK to restart miner or reboot system once a day.
And for PSU, at least in my case that can't be problem because using just 60% of power consumption (HX 1200 / 720W consumption)

thanks to TRM miner I am running a mix of 50 vegas at pool average of 102KH/s with consumption of 9000W. It took me some time to reach the  stability and reliability, it was big effort, but it will be paid back through big increase of hash per watt compared to other miners.

surely, there are some things I would like to see. One is a simple watchdog that restarts the miner (or run a bat file of our choice) if the hashrate is below certain number. (a small number of my miner starts happen all cards to hash 0, exit and atart miner again and all good). Another is a logfile that will instantly write a message to log if card or thread crashesz this is to have record of event before entire rig crashes or freezes. i guess this mods are "if this then that" easy to implement and hipe to see them in new version, together with even faster speed

I understand, and I also know exactly why it happens and not for your other 20 miners. Reading my previous post it sounds kind of snarky which wasn't my intention, it was more an effect of typing on my phone and really being in a hurry. We only have one user with this issue though, which is you. It might be that we rewrite the init process at some point, which would solve your problem, but it's not the top priority right now.

My suggestion earlier isn't really about changing your system, it would just be you starting the miner with "start /realtime teamredminer.exe ..." rather than just "teamredminer.exe ...". If you don't have admin rights the process will get a "High" priority.

The reason this is interesting is that if it works, it would be a good patch: we would just bump the process priority temporarily during the init process, and then lower it after the init is done, and voila, your problem is solved! Therefore, it'd be awesome if you could test the above, first with "start /high teamredminer.exe ..." as a regular user (or admin), and if that doesn't work, as administrator with "start /realtime teamredminer.exe", all this while cpu mining in parallel as you'd normally do. I'm really interested in if it makes a difference. All this is also assuming your cpu miner threads don't have a high or realtime priority to begin with.

considering that this only happens with your miner, and not with any of the other 20 miners that i use, this isn't a good case for changing my system when all other software works.  my systems are set up for multi-algo, multi-software mining.

I know you have this startup problem, which is unrelated to the 0 h/s gpu hang after mining successfully for a while. It has nothing to do with the redesign of the kernels. Your issue is about cpu starvation when our miner starts up. Comparisons to srb and cast are irrelevant since we use a different initialization process. Have you tried starting the miner with a real-time process priority? Theoretically windows should preempt your cpu miner threads much more aggressively in favor of the gpu miner. When the gpu miner is running the effect on the cpu mining hashrate should be tiny.