Pages:
Author

Topic: [ANN] Rigel 1.13.0 - Radiant, Nexa and IronFish GPU miner (Nvidia only) - page 4. (Read 6424 times)

newbie
Activity: 15
Merit: 0
jr. member
Activity: 52
Merit: 4
Rigel 1.9.2


* Add PowBlocks mining support (`-a powblocks`)
* Remove `flora` algorithm

Bug fixes:
* (Windows 7) TUI is broken


Works like a charm. Thanks for the update!
jr. member
Activity: 45
Merit: 3
Rigel 1.9.2


* Add PowBlocks mining support (`-a powblocks`)
* Remove `flora` algorithm

Bug fixes:
* (Windows 7) TUI is broken
jr. member
Activity: 53
Merit: 2
It was possible that issue was from the pool, now rejected are less.
Keep up the good work!
Cheers!
jr. member
Activity: 45
Merit: 3
Hi, since 1.9.0 version, including 1.9.1 too, it started to appear more rejected shares on ZIL coin in dual or single mining, more than 10-15% are rejected shares regarding older versions, where rejected shares of ZIL, was lighter 2-3%.

Can you check?

Thank you!

I did not reply sooner on purpose - was trying to see if anyone else was having the same issue. Your report is the only one I've received, so I'm guessing it must be something on your end, or probably a temporary pool issue. Likely not a Rigel bug.
newbie
Activity: 1
Merit: 0
Can you help me increase the DNX algorithm as soon as possible? Thanks
jr. member
Activity: 53
Merit: 2
Rigel 1.9.0

* (CFX) Add `octopus` algorithm (2% dev fee, see `cfx` bat/sh script), including
  * CFX+RXD and CFX+RXD+ZIL (see `dual-cfx-rxd` bat/sh script)
  * CFX+ALPH and CFX+ALPH+ZIL (see `dual-cfx-alph` bat/sh script)
* Add OCTA+RXD and OCTA+RXD+ZIL mining support


Hi, since 1.9.0 version, including 1.9.1 too, it started to appear more rejected shares on ZIL coin in dual or single mining, more than 10-15% are rejected shares regarding older versions, where rejected shares of ZIL, was lighter 2-3%.

Can you check?

Thank you!
jr. member
Activity: 131
Merit: 2
Rigel 1.9.0

* (CFX) Add `octopus` algorithm (2% dev fee, see `cfx` bat/sh script), including
  * CFX+RXD and CFX+RXD+ZIL (see `dual-cfx-rxd` bat/sh script)
  * CFX+ALPH and CFX+ALPH+ZIL (see `dual-cfx-alph` bat/sh script)
* Add OCTA+RXD and OCTA+RXD+ZIL mining support


Pls add Dynex algo too.
jr. member
Activity: 53
Merit: 2
I can go more as it is but im satisfied for GDDR6X freq.On that printscreen, I mine Conflux +ZIL, both needed as higher as I can on memory freq.
If I go at +2200MHz, ZIL goes +110MH and CFX more than 106MH, but a little unstable after couple hours.
I prefear stability and nice hashrate.
Thank's again to the developer for this version wich supports CFX!
member
Activity: 1558
Merit: 69
Thank you!

I wait, I like this miner, even if a little lower hashrate compairing to GMiner, Rigel is lower fees too, and very stable!

Keep in mind Gminer inflates reported hashrate by 1%

1%? for Octopus it was 8% inflated hashrate on gminer as i reported in your discord Cheesy

Thanks for adding octopus with dual mining option. My 3060m rigs went up from 33mh pool hashrate to 41.5mh pool hashrate with dual mining RXD at 325mh.
As always nice work and I am happy to be one of the first supporter of your miner.

I saw that in calculations per 24 hours mining, regarding other miners using same settings for videocard, wich is watercooled.

https://postimg.cc/Mnzh0J7c

In my opinion, is absolute greedy to take 5% fees from CFX when mining CFX+RXD+ZIL.



With 762mv on GPU you can go much higher with your core clock. The range is 1650 - 1790mh @ 762mv. You can set an GPU offset from 200 or 250 instead of 100mhz, or go lower with the voltage. maybe around 700mv.
jr. member
Activity: 53
Merit: 2
Great job, works like a charm!

Thank you!
jr. member
Activity: 45
Merit: 3
Rigel 1.9.0

* (CFX) Add `octopus` algorithm (2% dev fee, see `cfx` bat/sh script), including
  * CFX+RXD and CFX+RXD+ZIL (see `dual-cfx-rxd` bat/sh script)
  * CFX+ALPH and CFX+ALPH+ZIL (see `dual-cfx-alph` bat/sh script)
* Add OCTA+RXD and OCTA+RXD+ZIL mining support
jr. member
Activity: 53
Merit: 2
I saw that in calculations per 24 hours mining, regarding other miners using same settings for videocard, wich is watercooled.

https://postimg.cc/Mnzh0J7c

In my opinion, is absolute greedy to take 5% fees from CFX when mining CFX+RXD+ZIL.

jr. member
Activity: 45
Merit: 3
Thank you!

I wait, I like this miner, even if a little lower hashrate compairing to GMiner, Rigel is lower fees too, and very stable!

Keep in mind Gminer inflates reported hashrate by 1%
jr. member
Activity: 53
Merit: 2
Thank you!

I wait, I like this miner, even if a little lower hashrate compairing to GMiner, Rigel is lower fees too, and very stable!
member
Activity: 1558
Merit: 69
Be AWARE, oficial thread starter is mr. rigelminer (OP)

This post above could be made from an compromissed account!

ONtopic.

Is any option for dual mining  OCTOPUS algo (Conflux)+ZIL?

No Octopus support at the moment. Maybe in the future. Information from Rigel from his Discord.
jr. member
Activity: 53
Merit: 2
Be AWARE, oficial thread starter is mr. rigelminer (OP)

This post above could be made from an compromissed account!

ONtopic.

Is any option for dual mining  OCTOPUS algo (Conflux)+ZIL?
jr. member
Activity: 222
Merit: 2
srbminer-multi 2.3.6 updated!
- Changelog -
Added support for algorithm 'dynex' on NVIDIA GPUs
Performance improvement on algorithm 'dynex' on AMD GPUs
Removed Dynex optimised dual kernels
Lowered devfee for algorithm 'ETHASHB3'  to standard 0.85%

teamblackminer 2.01 updated!
- Changelog -
Faster miner startup.
Reduced stales in the vertcoin,etchash,ethash,ethashb3,zil and kawpow algo.
Fixed rejected shares bug in the vertcoin algo.
EthashB3   devfee Rethereum   Nvidia   0.5%
full member
Activity: 1424
Merit: 225
I had to resort to using coin names for `-a` as different kawpow coins use DAGs of different sizes and it creates a problem where the miner would need to rebuild the DAG every few minutes to mine dev fee. When you specify the coin name the miner knows exactly what you're mining and will be mining the same coin as dev fee thus avoiding DAG rebuilds.

LooooooooL. What a joke. Miner must set correct algo through stratum protocol. Kawpow now use at least 20+ coins, Ethash use 30+ coins - will you name every coin as different parameters?

No joke, it´s normal. Reminds me to claymore in the past, where the miner in every devfee period recreates the DAG if you mined an other coin as ETH, and Rigel will avoid this, so it is good and bad.
But i understand the point, an native support for KAWPOW would nice, so that the user can decide if they want a DAG creation in every devfee period.

I'm not a fan of devfees but a seperate coin option, --coin or -C would have been better to avoid confusion, most miners won't accept a coin name for the algo.
-a kawpow for generic kawpow,
--coin ravencoin or --coin rvn for Ravencoin only.

Edit: this also simplifies when a coin changes algo, no need to change the command line for the new algo.
member
Activity: 1558
Merit: 69
Rigel 1.8.0

* Add mining support for the following coins (dev fee 1%):
  * Ravencoin (`-a ravencoin`, see `rvn` bat/sh script)
  * Neurai (`-a neurai`, see `xna` bat/sh script)
  * Clore (`-a clore`, see `clore` bat/sh script)
* (IronFish) Minor performance improvements for `+ironfish` dual modes

Raven coin, Neural, Clore, Neoxa.. and Paprikacoin, Zatox, Gamepass, Meow coin, Hivecoin, Procyon Coin etc. come true mining with KAWPOW algo.
Why split it up on "-a ravencoin", "-a neurai" etc?

I had to resort to using coin names for `-a` as different kawpow coins use DAGs of different sizes and it creates a problem where the miner would need to rebuild the DAG every few minutes to mine dev fee. When you specify the coin name the miner knows exactly what you're mining and will be mining the same coin as dev fee thus avoiding DAG rebuilds.

LooooooooL. What a joke. Miner must set correct algo through stratum protocol. Kawpow now use at least 20+ coins, Ethash use 30+ coins - will you name every coin as different parameters?

No joke, it´s normal. Reminds me to claymore in the past, where the miner in every devfee period recreates the DAG if you mined an other coin as ETH, and Rigel will avoid this, so it is good and bad.
But i understand the point, an native support for KAWPOW would nice, so that the user can decide if they want a DAG creation in every devfee period.
Pages:
Jump to: