Topic: SRBMiner-MULTI GPU & CPU Miner 0.9.4 - page 3. (Read 42257 times)
V2.4.6 aurum algo, miner gives low hashrate on N100-N300 intel CPUs (avx2+sha+vaes), about twice lower then official miner.
V2.4.6
+ Added algorithm 'aurum' (BitNet) for CPU mining, fee 2.00%
+ Minor performance improvement on algorithm 'blake3_alephium'
+ Added support for algorithm 'cryptonight_turtle' on AMD gfx1100
+ Added Vega56/64 rocm binary for algorithm 'cryptonight_turtle'
+ Minor bug fixes
+ Added algorithm 'aurum' (BitNet) for CPU mining, fee 2.00%
+ Minor performance improvement on algorithm 'blake3_alephium'
+ Added support for algorithm 'cryptonight_turtle' on AMD gfx1100
+ Added Vega56/64 rocm binary for algorithm 'cryptonight_turtle'
+ Minor bug fixes
V2.4.5
+ Minor performance improvement on algorithm 'karlsenhash' for AMD RDNA2 GPU's
+ Minor performance improvement on algorithm 'sha3d'
+ OC parameters (NVIDIA) should now work as expected on both WINDOWS and LINUX
+ Fixed issue with lower poolside hashrate on algorithm 'blake3_alephium' introduced in previous version
+ Fixed an issue that caused higher difficulty to be used than what the pool sent - on some algorithms, introduced in previous version
+ Removed algorithms : blake2b, blake2s, yespowerlitb, yespoweriots, yespoweritc, yespowerres, yespowerarwn, cryptonight_talleo, cryptonight_ccx, randomhash2, scryptn2, k12, keccak, dynamo, minotaur, kaspa
+ Minor performance improvement on algorithm 'karlsenhash' for AMD RDNA2 GPU's
+ Minor performance improvement on algorithm 'sha3d'
+ OC parameters (NVIDIA) should now work as expected on both WINDOWS and LINUX
+ Fixed issue with lower poolside hashrate on algorithm 'blake3_alephium' introduced in previous version
+ Fixed an issue that caused higher difficulty to be used than what the pool sent - on some algorithms, introduced in previous version
+ Removed algorithms : blake2b, blake2s, yespowerlitb, yespoweriots, yespoweritc, yespowerres, yespowerarwn, cryptonight_talleo, cryptonight_ccx, randomhash2, scryptn2, k12, keccak, dynamo, minotaur, kaspa
Does this version support 2 CPUs? I have a 2 x Xeon 2699v4, each CPU 22 cores/44 threads, and even using the --cpu-affinity only the first CPU is being used. Maybe I'm doing something wrong, but I set the --cpu-threads 44 --cpu-affinity 0x555555555555555555555
Iam sorry, but i have a question.
On my linux, i can see hash rate like
3776.12 H/s etc on minotaurx when iam mining some coin, but on pool side, i see my rate like 2 h/s or 4..
How it is possible?
On my linux, i can see hash rate like
3776.12 H/s etc on minotaurx when iam mining some coin, but on pool side, i see my rate like 2 h/s or 4..
How it is possible?
Can you guys add octopus ?
V2.4.5
+ Minor performance improvement on algorithm 'karlsenhash' for AMD RDNA2 GPU's
+ Minor performance improvement on algorithm 'sha3d'
+ OC parameters (NVIDIA) should now work as expected on both WINDOWS and LINUX
+ Fixed issue with lower poolside hashrate on algorithm 'blake3_alephium' introduced in previous version
+ Fixed an issue that caused higher difficulty to be used than what the pool sent - on some algorithms, introduced in previous version
+ Removed algorithms : blake2b, blake2s, yespowerlitb, yespoweriots, yespoweritc, yespowerres, yespowerarwn, cryptonight_talleo, cryptonight_ccx, randomhash2, scryptn2, k12, keccak, dynamo, minotaur, kaspa
+ Minor performance improvement on algorithm 'karlsenhash' for AMD RDNA2 GPU's
+ Minor performance improvement on algorithm 'sha3d'
+ OC parameters (NVIDIA) should now work as expected on both WINDOWS and LINUX
+ Fixed issue with lower poolside hashrate on algorithm 'blake3_alephium' introduced in previous version
+ Fixed an issue that caused higher difficulty to be used than what the pool sent - on some algorithms, introduced in previous version
+ Removed algorithms : blake2b, blake2s, yespowerlitb, yespoweriots, yespoweritc, yespowerres, yespowerarwn, cryptonight_talleo, cryptonight_ccx, randomhash2, scryptn2, k12, keccak, dynamo, minotaur, kaspa
Doctor, you need to overhaul the CPU miners. The algorithm that gets 100 hashes with SRB on the same hardware gives 250-300 hashes with another miner. There is only one CPU in the Ghostrider algorithm. Why don't you add a GPU? We love SRB.
Couldn't connect to a devfee pool for a long time, mining will be paused until connection to the devfee pool can be established
I have checked the logs of dozens of machines and found that due to the issue with devfee, the machines have been working for almost two hours and have been stuck for more than half an hour.
Then I checked the backend links of each computer's network, with IP 193.70.81.165, port 5170, and IP 49.13.120.2, port 20033, totaling 9 links. Why does the kernel still say it can't connect to devfee? I would rather you pump 5% of the water than let the machine run empty most of the time, hoping that the developer can modify the logic of devfee. Additionally, I am digging RTH+ALPH in a dual mine
I have checked the logs of dozens of machines and found that due to the issue with devfee, the machines have been working for almost two hours and have been stuck for more than half an hour.
Then I checked the backend links of each computer's network, with IP 193.70.81.165, port 5170, and IP 49.13.120.2, port 20033, totaling 9 links. Why does the kernel still say it can't connect to devfee? I would rather you pump 5% of the water than let the machine run empty most of the time, hoping that the developer can modify the logic of devfee. Additionally, I am digging RTH+ALPH in a dual mine
there are 12 devfee pools total for those 2 algorithms, meaning none of them could get connected from where you are. If only one of them connects (any of the two algos) that message wont be shown, and mining wont be paused.
Fix what's blocking the connections and you wont have any issue.
SRBMiner-MULTI.exe 安全 TCP 192.168.31.97 49731 ******* 55070 连接 中国 中国香港 中国香港 * *
SRBMiner-MULTI.exe 安全 TCP 192.168.31.97 49732 ******* 51199 连接 中国 中国香港 中国香港 * *
SRBMiner-MULTI.exe 安全 TCP 192.168.31.97 49733 ******* 51111 连接 中国 中国香港 中国香港 * *
SRBMiner-MULTI.exe 安全 TCP 192.168.31.97 49797 193.70.81.165 5170 连接 法国 * * * *
SRBMiner-MULTI.exe 安全 TCP 192.168.31.97 49817 49.13.120.2 20033 连接 德国 * * * *
SRBMiner-MULTI.exe 安全 TCP 192.168.31.97 50159 49.13.120.2 20033 连接 德国 * * * *
SRBMiner-MULTI.exe 安全 TCP 192.168.31.97 50214 49.13.120.2 20033 同步发送 德国 * * * *
SRBMiner-MULTI.exe 安全 TCP 192.168.31.97 50333 49.13.120.2 20033 连接 德国 * * * *
SRBMiner-MULTI.exe 安全 TCP 192.168.31.97 50652 49.13.120.2 20033 连接 德国 * * * *
*******It is a server that I purchased myself for port forwarding. 193.70.81.165:5170 is the Devfee pool for RTH. Why does the ALPH Devfee pool for 49.13.120.2:20033 need to start 5 threads and link simultaneously. I have seen SRB start 8 threads linking the same devfee pool at most, one should be enough, or starting 8 devfee pools with different links can also be understood.
Couldn't connect to a devfee pool for a long time, mining will be paused until connection to the devfee pool can be established
I have checked the logs of dozens of machines and found that due to the issue with devfee, the machines have been working for almost two hours and have been stuck for more than half an hour.
Then I checked the backend links of each computer's network, with IP 193.70.81.165, port 5170, and IP 49.13.120.2, port 20033, totaling 9 links. Why does the kernel still say it can't connect to devfee? I would rather you pump 5% of the water than let the machine run empty most of the time, hoping that the developer can modify the logic of devfee. Additionally, I am digging RTH+ALPH in a dual mine
I have checked the logs of dozens of machines and found that due to the issue with devfee, the machines have been working for almost two hours and have been stuck for more than half an hour.
Then I checked the backend links of each computer's network, with IP 193.70.81.165, port 5170, and IP 49.13.120.2, port 20033, totaling 9 links. Why does the kernel still say it can't connect to devfee? I would rather you pump 5% of the water than let the machine run empty most of the time, hoping that the developer can modify the logic of devfee. Additionally, I am digging RTH+ALPH in a dual mine
there are 12 devfee pools total for those 2 algorithms, meaning none of them could get connected from where you are. If only one of them connects (any of the two algos) that message wont be shown, and mining wont be paused.
Fix what's blocking the connections and you wont have any issue.
As a Chinese miner, network interception is not our own behavior, but rather done by the government. We also rent overseas servers to connect to some mining pools through port forwarding. Can developers provide a user-defined devfee method? The devfee pool can be customized by a certain parameter, so that we can also achieve stable links to the devfee pool through port forwarding.
MinotaurX is broken in last version. Dev fee links for many algos is broken (at least in old versions), dev is lazy ass =)
You are right about MinotaurX. About the broken devfee pools, which ones?
MinotaurX is broken in last version. Dev fee links for many algos is broken (at least in old versions), dev is lazy ass =)
Couldn't connect to a devfee pool for a long time, mining will be paused until connection to the devfee pool can be established
I have checked the logs of dozens of machines and found that due to the issue with devfee, the machines have been working for almost two hours and have been stuck for more than half an hour.
Then I checked the backend links of each computer's network, with IP 193.70.81.165, port 5170, and IP 49.13.120.2, port 20033, totaling 9 links. Why does the kernel still say it can't connect to devfee? I would rather you pump 5% of the water than let the machine run empty most of the time, hoping that the developer can modify the logic of devfee. Additionally, I am digging RTH+ALPH in a dual mine
I have checked the logs of dozens of machines and found that due to the issue with devfee, the machines have been working for almost two hours and have been stuck for more than half an hour.
Then I checked the backend links of each computer's network, with IP 193.70.81.165, port 5170, and IP 49.13.120.2, port 20033, totaling 9 links. Why does the kernel still say it can't connect to devfee? I would rather you pump 5% of the water than let the machine run empty most of the time, hoping that the developer can modify the logic of devfee. Additionally, I am digging RTH+ALPH in a dual mine
there are 12 devfee pools total for those 2 algorithms, meaning none of them could get connected from where you are. If only one of them connects (any of the two algos) that message wont be shown, and mining wont be paused.
Fix what's blocking the connections and you wont have any issue.
Couldn't connect to a devfee pool for a long time, mining will be paused until connection to the devfee pool can be established
I have checked the logs of dozens of machines and found that due to the issue with devfee, the machines have been working for almost two hours and have been stuck for more than half an hour.
Then I checked the backend links of each computer's network, with IP 193.70.81.165, port 5170, and IP 49.13.120.2, port 20033, totaling 9 links. Why does the kernel still say it can't connect to devfee? I would rather you pump 5% of the water than let the machine run empty most of the time, hoping that the developer can modify the logic of devfee. Additionally, I am digging RTH+ALPH in a dual mine
I have checked the logs of dozens of machines and found that due to the issue with devfee, the machines have been working for almost two hours and have been stuck for more than half an hour.
Then I checked the backend links of each computer's network, with IP 193.70.81.165, port 5170, and IP 49.13.120.2, port 20033, totaling 9 links. Why does the kernel still say it can't connect to devfee? I would rather you pump 5% of the water than let the machine run empty most of the time, hoping that the developer can modify the logic of devfee. Additionally, I am digging RTH+ALPH in a dual mine
V2.4.4
+ Added algorithm 'pyrinhash' (Pyrin) for GPU mining on AMD/INTEL, fee 0.85%
+ Added algorithm 'blake3_decred' (Decred) for GPU mining on AMD/NVIDIA/INTEL, fee 1.0%
+ Added support for dual mining AUTOLYKOS2/PYRINHASH on AMD RDNA/RDNA2/RDNA3 and INTEL GPU's
+ Added support for dual mining AUTOLYKOS2/BLAKE3_DECRED on AMD/NVIDIA/INTEL GPU's
+ Added support for dual mining ETHASH/BLAKE3_DECRED on AMD/NVIDIA/INTEL GPU's
+ Added support for dual mining ETCHASH/BLAKE3_DECRED on AMD/NVIDIA/INTEL GPU's
+ Added support for dual mining ETHASHB3/BLAKE3_DECRED on AMD/NVIDIA/INTEL GPU's
+ Improved efficiency on algorithm 'blake3_alephium' for AMD RDNA2/RDNA3, NVIDIA GPU's
+ Miner will now create '--gpu-id' parameter values internally (if not already defined) when using an OC parameter that has multiple different values.
+ Minor bug fixes
+ Added algorithm 'pyrinhash' (Pyrin) for GPU mining on AMD/INTEL, fee 0.85%
+ Added algorithm 'blake3_decred' (Decred) for GPU mining on AMD/NVIDIA/INTEL, fee 1.0%
+ Added support for dual mining AUTOLYKOS2/PYRINHASH on AMD RDNA/RDNA2/RDNA3 and INTEL GPU's
+ Added support for dual mining AUTOLYKOS2/BLAKE3_DECRED on AMD/NVIDIA/INTEL GPU's
+ Added support for dual mining ETHASH/BLAKE3_DECRED on AMD/NVIDIA/INTEL GPU's
+ Added support for dual mining ETCHASH/BLAKE3_DECRED on AMD/NVIDIA/INTEL GPU's
+ Added support for dual mining ETHASHB3/BLAKE3_DECRED on AMD/NVIDIA/INTEL GPU's
+ Improved efficiency on algorithm 'blake3_alephium' for AMD RDNA2/RDNA3, NVIDIA GPU's
+ Miner will now create '--gpu-id' parameter values internally (if not already defined) when using an OC parameter that has multiple different values.
+ Minor bug fixes
Can someone tell me what is this error message mean using RADEON VII ? GPU0 couldn't create program for ctx->algorithm
A bit sparse with details?
OS, mining algo and maybe some more details would not go amiss.
Like what is your command line you use to start mining.
I cannot understand why people still do not provide the necessary details is beyond me.
Can someone tell me what is this error message mean using RADEON VII ? GPU0 couldn't create program for ctx->algorithm
V2.4.3
+ Performance improvement on algorithm 'karlsenhash' for some AMD GPUs and INTEL ARC GPU's
+ Added support for dual mining AUTOLYKOS2/KARLSENHASH on AMD RDNA/RDNA2/RDNA3 and INTEL ARC GPU's
+ Added support for dual mining ETHASHB3/KARLSENHASH on AMD Ellesmere, RDNA/RDNA2/RDNA3 and INTEL ARC GPU's
+ DevFee for 'karlsenhash' algorithm lowered to 0.85%
+ Minor bug fixes
+ Performance improvement on algorithm 'karlsenhash' for some AMD GPUs and INTEL ARC GPU's
+ Added support for dual mining AUTOLYKOS2/KARLSENHASH on AMD RDNA/RDNA2/RDNA3 and INTEL ARC GPU's
+ Added support for dual mining ETHASHB3/KARLSENHASH on AMD Ellesmere, RDNA/RDNA2/RDNA3 and INTEL ARC GPU's
+ DevFee for 'karlsenhash' algorithm lowered to 0.85%
+ Minor bug fixes
Radeon VII refuse to start on windows 11 / SRBMiner-Multi giving me GPU0 couldn't create program for ctx->algorithm using latest AMD drivers and latest SRBMiner version.
doktor83
We kindly ask you to mark the released map in the log not at the end of the entire log, but at the beginning of the log. Or change the timeout for the end of the log. And not like now 5 minutes.
And please add a function for changing the display time of the table.
We kindly ask you to mark the released map in the log not at the end of the entire log, but at the beginning of the log. Or change the timeout for the end of the log. And not like now 5 minutes.
And please add a function for changing the display time of the table.
I dont understand what you are trying to say. What is 'mark the released map' ?
doktor83
We kindly ask you to mark the released map in the log not at the end of the entire log, but at the beginning of the log. Or change the timeout for the end of the log. And not like now 5 minutes.
And please add a function for changing the display time of the table.
We kindly ask you to mark the released map in the log not at the end of the entire log, but at the beginning of the log. Or change the timeout for the end of the log. And not like now 5 minutes.
And please add a function for changing the display time of the table.
Jump to: