Search content
Sort by
Showing 20 of 28 results by BS0D
Will there be any speed improvement using AVX2 and hugepages for CPUs? As well as L3 cache usage of ryzen cpus which in some cases may replace ram reads increasing the speed by times.
It is happen to be using a xmrig on the same machine as Keyhunt.Is it possible to boost command from here increase the number of keys per second on AMD EPYC
https://raw.githubusercontent.com/xmrig/xmrig/dev/scripts/randomx_boost.sh
I have strange results.
Will there be any speed improvement using AVX2 and hugepages for CPUs? As well as L3 cache usage of ryzen cpus which in some cases may replace ram reads increasing the speed by times.
Re: == Bitcoin challenge transaction: ~1000 BTC total bounty to solvers! ==UPDATED==
Hello,
Due to the situation that happened in this challenge - I allowed myself to refresh the topic - I corrected the name of the thread, added a new date to "important dates", changed the image of the remaining amount of BTC up for grabs, and restored the functioning of my website zielar.pl from which you can now restart download the VanitySearch builds, because I saw somewhere earlier that someone mentioned that the links are out of date. It's a fact - they were outdated because I didn't extend the hosting :-) Nevertheless, everything is fine now. I'm also considering re-entering with some power... therefore, to shorten the necessary time to refresh the news about currently running programs - give me the details of any latest and greatest versions you are currently using (VanitySearch, Kangaroo) - and whether poolem 66bit also works pool fighting for 125?
Regards
My man! Thanks for updating and refreshing the topics and links!Due to the situation that happened in this challenge - I allowed myself to refresh the topic - I corrected the name of the thread, added a new date to "important dates", changed the image of the remaining amount of BTC up for grabs, and restored the functioning of my website zielar.pl from which you can now restart download the VanitySearch builds, because I saw somewhere earlier that someone mentioned that the links are out of date. It's a fact - they were outdated because I didn't extend the hosting :-) Nevertheless, everything is fine now. I'm also considering re-entering with some power... therefore, to shorten the necessary time to refresh the news about currently running programs - give me the details of any latest and greatest versions you are currently using (VanitySearch, Kangaroo) - and whether poolem 66bit also works pool fighting for 125?
Regards
I am running a kangaroo pool/server and have posted to see the interest in the community (before posting and giving out IP and port) but there have only been two people interested.
I have locked up agreements from gpu farms. I will have (so far) 480 cards connecting to the pool BUT for only 20-25 minutes each day. In the agreement I have to pay for storage space so that I can save and keep each card's kangaroos (paths). I am currently trying to work out additional agreements. I also have 72 cards that are constantly running in the pool. All are RTX 30xx and above; 30xx. I would love to have many CPUs running in the race as well as their paths (although less paths) become much longer than a GPUs path.
Current progress = 2^19.06/2^27.05
Could i join to your work? Please send me PM to more details. I can use 8x Tesla A100 to work for this task per 1-2 months
What is A100 performance on kangaroo and BSGS?
Getting 128GB to work with a desktop PC can be tricky. With modern processors incorporating memory controllers on die, the load from 4 DIMMS is problematic.
If anyone is interested in using 4 DIMMS, make sure to check the memory QVL for the motherboard you have and be prepared to spend some time tweaking the BIOS to make it work. Using memory that is not on the QVL may also work but will most likely need tweaking and loosening of the timings and speed.
I think I was getting about 450/620Pkeys/s on Ryzen 5950X/32GB with k=1440/2048 on #120
Would like to have 128GB on my system but that's impossible due some reasons
If anyone is interested in using 4 DIMMS, make sure to check the memory QVL for the motherboard you have and be prepared to spend some time tweaking the BIOS to make it work. Using memory that is not on the QVL may also work but will most likely need tweaking and loosening of the timings and speed.
I think I was getting about 450/620Pkeys/s on Ryzen 5950X/32GB with k=1440/2048 on #120
Would like to have 128GB on my system but that's impossible due some reasons
I use a mini-itx board so only two dimm slots available. Plus I just want to use b-die sticks which is a total limit. Seems there were G.Skill 2x32GB b-die kits in production but it's almost impossible to find or the price is oof
1 Ekeys/s (1021708069969158067 keys/s)
1.021.708.069.969.158.067 keys/s
128gb + 16 AMD Ryzen 7 5800X
http://kknd.com.br/etc/keyhunt.png
1.021.708.069.969.158.067 keys/s
128gb + 16 AMD Ryzen 7 5800X
http://kknd.com.br/etc/keyhunt.png
Code:
ubuntu@:~/kknd/keyhunt$ ./keyhunt -m bsgs -f 125.pub -b 125 -R -q -S -n 0x400000000000 -k 4096 -t 15
[+] Version 0.2.230428 Satoshi Quest, developed by AlbertoBSD
[+] Random mode
[+] Quiet thread output
[+] K factor 4096
[+] Threads : 15
[+] Mode BSGS random
[+] Opening file 125.pub
[+] Added 1 points from file
[+] Bit Range 125
[+] -- from : 0x10000000000000000000000000000000 [+] -- to : 0x20000000000000000000000000000000
[+] N = 0x400000000000
[+] Bloom filter for 34359738368 elements : 117781.20 MB
[+] Bloom filter for 1073741824 elements : 3680.66 MB
[+] Bloom filter for 33554432 elements : 115.02 MB
[+] Allocating 512.00 MB for 33554432 bP Points
[+] Reading bloom filter from file keyhunt_bsgs_4_34359738368.blm .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_6_1073741824.blm .... Done!
[+] Reading bP Table from file keyhunt_bsgs_2_33554432.tbl .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_7_33554432.blm .... Done!
[+] Total 82543794972808280276992 keys in 80790 seconds: ~1 Ekeys/s (1021708069969158067 keys/s)
http://kknd.com.br/etc/htop.png[+] Version 0.2.230428 Satoshi Quest, developed by AlbertoBSD
[+] Random mode
[+] Quiet thread output
[+] K factor 4096
[+] Threads : 15
[+] Mode BSGS random
[+] Opening file 125.pub
[+] Added 1 points from file
[+] Bit Range 125
[+] -- from : 0x10000000000000000000000000000000 [+] -- to : 0x20000000000000000000000000000000
[+] N = 0x400000000000
[+] Bloom filter for 34359738368 elements : 117781.20 MB
[+] Bloom filter for 1073741824 elements : 3680.66 MB
[+] Bloom filter for 33554432 elements : 115.02 MB
[+] Allocating 512.00 MB for 33554432 bP Points
[+] Reading bloom filter from file keyhunt_bsgs_4_34359738368.blm .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_6_1073741824.blm .... Done!
[+] Reading bP Table from file keyhunt_bsgs_2_33554432.tbl .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_7_33554432.blm .... Done!
[+] Total 82543794972808280276992 keys in 80790 seconds: ~1 Ekeys/s (1021708069969158067 keys/s)
Code:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 48 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Vendor ID: AuthenticAMD
Model name: AMD Ryzen 7 5800X 8-Core Processor
CPU family: 25
Model: 33
Thread(s) per core: 2
Core(s) per socket: 8
Socket(s): 1
Stepping: 2
Frequency boost: enabled
CPU max MHz: 3800.0000
CPU min MHz: 2200.0000
BogoMIPS: 7586.05
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 48 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Vendor ID: AuthenticAMD
Model name: AMD Ryzen 7 5800X 8-Core Processor
CPU family: 25
Model: 33
Thread(s) per core: 2
Core(s) per socket: 8
Socket(s): 1
Stepping: 2
Frequency boost: enabled
CPU max MHz: 3800.0000
CPU min MHz: 2200.0000
BogoMIPS: 7586.05
I think I was getting about 450/620Pkeys/s on Ryzen 5950X/32GB with k=1440/2048 on #120
Would like to have 128GB on my system but that's impossible due some reasons
Re: == Bitcoin challenge transaction: ~1000 BTC total bounty to solvers! ==UPDATED==
Hello,
Due to the situation that happened in this challenge - I allowed myself to refresh the topic - I corrected the name of the thread, added a new date to "important dates", changed the image of the remaining amount of BTC up for grabs, and restored the functioning of my website zielar.pl from which you can now restart download the VanitySearch builds, because I saw somewhere earlier that someone mentioned that the links are out of date. It's a fact - they were outdated because I didn't extend the hosting :-) Nevertheless, everything is fine now. I'm also considering re-entering with some power... therefore, to shorten the necessary time to refresh the news about currently running programs - give me the details of any latest and greatest versions you are currently using (VanitySearch, Kangaroo) - and whether poolem 66bit also works pool fighting for 125?
Regards
My man! Thanks for updating and refreshing the topics and links!Due to the situation that happened in this challenge - I allowed myself to refresh the topic - I corrected the name of the thread, added a new date to "important dates", changed the image of the remaining amount of BTC up for grabs, and restored the functioning of my website zielar.pl from which you can now restart download the VanitySearch builds, because I saw somewhere earlier that someone mentioned that the links are out of date. It's a fact - they were outdated because I didn't extend the hosting :-) Nevertheless, everything is fine now. I'm also considering re-entering with some power... therefore, to shorten the necessary time to refresh the news about currently running programs - give me the details of any latest and greatest versions you are currently using (VanitySearch, Kangaroo) - and whether poolem 66bit also works pool fighting for 125?
Regards
I am running a kangaroo pool/server and have posted to see the interest in the community (before posting and giving out IP and port) but there have only been two people interested.
I have locked up agreements from gpu farms. I will have (so far) 480 cards connecting to the pool BUT for only 20-25 minutes each day. In the agreement I have to pay for storage space so that I can save and keep each card's kangaroos (paths). I am currently trying to work out additional agreements. I also have 72 cards that are constantly running in the pool. All are RTX 30xx and above; 30xx. I would love to have many CPUs running in the race as well as their paths (although less paths) become much longer than a GPUs path.
Current progress = 2^19.06/2^27.05
Any requirements for joining the pool?
How does V100 perform btw? I'm asking cause nterested what kind of specs are preferable when using BSGS or kang. Teslas got high speed and a decent amount of HBM vram but less cuda cores compared to consumer grade cards. But V100 is about 5 years old which is a lot.
Is 'n' 32bit limited?
sadly yes, but are you going to do a list of more of 2 billion address?
Also when trying to make a big file I've found it working very slow. Uses only 4 threads (or maybe 2 cores). Thought the drive may be the problem but ram drive doesn't make any change.
Would be nice (and code simple I guess) to make the output file parted for such experiments
Re: [JCE]Fast & stable CN/v8/Heavy/Tube/XHV miner, CPU+GPU, Vega56 1800+ RX580 1200+
Re: [JCE] Ultrafast CN-Heavy/Tube/HVX miner, low power, Vega56 1750+h/s
Had the stable heavy 1920h/s on V64 with the latest Vega driver. What is interesting that stable 1920 hashrate I could catch with several miner restarts when some first starts were unstable and lower. But when caught it was working stable till I manually stop it. 12H nonstop tested with 2 last gpu releases. But then I decided to test different drivers and now I cannot reproduce previous 1920. Only 1820 available. Could miner reserve some extra memory? Or maybe there's a way to forbid win10 using video memory for its needs.
I've noticed that teamred uses less mem with higher V8 hashes than SRB and JCE. Thats strange imo.
I've noticed that teamred uses less mem with higher V8 hashes than SRB and JCE. Thats strange imo.
Re: [JCE] Ultrafast CN-Heavy/Tube/HVX miner, low power, Vega56 1750+ h/s
JSON: is it really forbidden by the json standard to write
Code:
"a" :
{42}
rather than{42}
Code:
"a" :{
42}
?42}
It may be acceptable by json standard but any json validator fixes the code that way.
May be the problem occurs when using 'json.parse' where every single string should be understood as it should be. For example the string starting with "hashrate": should end with a value or a bracket.
I maybe wrong ofcourse.
Some headers like 'Access-Control-Allow-Origin' and 'Access-Control-Allow-Methods' are missing. Which are needed to make for example GET requests.
As for json, there maybe some services or functions need an iconic-like syntax to work properly.
Re: [JCE] Ultrafast CN-Heavy/Tube/HVX miner, low power, Vega56 1750+ h/s
Quote
And that's with usage of FX4330(4-core, 8M, 4GHz)
CN-Heavy consumes 4M of cache, better use two threads with multi-hash 1Agree with your logic but it does less hashes that way.
So, I've got some observes:
01 + 31 = 114 01 + 32 = 128 02 + 31 = 128
01 + 21 = 114 02 + 21 = 128
01 + 11 = 92 02 + 11 = 85 01 + 12 = 85
11 + 21 = 114 12 + 21 = 128 11 + 22 = 128
21 + 31 = 92 22 + 31 = 85
The conclusion may be that miner uses not the only L3 cache which is one for all cores but it uses L2 caches which are numbered to core modules on the exact cpu.
FX4330 has 2 modules by 2 cores with 2MB L2 each. And the sum of L2 and L3 is exact 12MB.
Unfortunately I've already sold all of my 8300 and 6300 FXes. Would be nice to test them again.
That can be used to tune any CPU.
Re: [JCE] Ultrafast CN-Heavy/Tube/HVX miner, low power, Vega56 1750+ h/s
The last point I've reached is quite stable heavy 1920-1930h/s, single Vega 64 (1478/920 1100/910). But still I don't understand what it depends on.
{ "mode" : "GPU", "worksize" : 8, "alpha" : 68, "beta" : 64, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 1, "multi_hash":960 },
{ "mode" : "GPU", "worksize" : 8, "alpha" : 68, "beta" : 16, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 1, "multi_hash":1008 }
About 80-100h/s appears when playing with alpha 64-68 on threads.
It can start with rising to 1950-1970 but then it falls to 1830-1840 (which is very good too). But it can also start with straight 1920 and work with stable 1920-1930h/s with no issues.
And that's with usage of FX4330(4-core, 8M, 4GHz) in that same config:
{ "cpu_architecture": "auto", "affine_to_cpu": 0, "use_cache": true, "multi_hash": 1 },
{ "cpu_architecture": "auto", "affine_to_cpu": 3, "use_cache": true, "multi_hash": 2 }
which does 120h/s.
I think it's all about some megabytes of memory usage.
{ "mode" : "GPU", "worksize" : 8, "alpha" : 68, "beta" : 64, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 1, "multi_hash":960 },
{ "mode" : "GPU", "worksize" : 8, "alpha" : 68, "beta" : 16, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 1, "multi_hash":1008 }
About 80-100h/s appears when playing with alpha 64-68 on threads.
It can start with rising to 1950-1970 but then it falls to 1830-1840 (which is very good too). But it can also start with straight 1920 and work with stable 1920-1930h/s with no issues.
And that's with usage of FX4330(4-core, 8M, 4GHz) in that same config:
{ "cpu_architecture": "auto", "affine_to_cpu": 0, "use_cache": true, "multi_hash": 1 },
{ "cpu_architecture": "auto", "affine_to_cpu": 3, "use_cache": true, "multi_hash": 2 }
which does 120h/s.
I think it's all about some megabytes of memory usage.
Re: [JCE] Ultrafast CN-Heavy/Tube/HVX miner, low power, Vega56 1750+ h/s
[JCE] Ultrafast CN-Heavy/Tube/HVX miner, low power, Vega56 1750+ h/s
I've got 1800h/s with cn-tube on V64. Very good result.
I've got 1800h/s with cn-tube on V64. Very good result.
Please can you share your setup?
I easily got 1800 on single vega pc but on my rigs hashrates are anywhere from 1500 to 1800. Hoping that b6 version will resolve that and provide consistent hashrate
I use that, but got one vega:
"gpu_threads_conf" :
[
{"index": 0, "mode": "GPU", "worksize": 8, "alpha": 64, "beta": 32, "multi_hash": 960},
{"index": 0, "mode": "GPU", "worksize": 8, "alpha": 64, "beta": 16, "multi_hash": 1008}
]
This conf seems very close to max available memory usage and after miner restart it cannot allocate memory for one of threads. IDK if that is about vega memory or swapfile. It somehow keeps some data after use. SRB solves the same like issue when restarting vega and releasing memory if I'm right.
Re: SRBMiner Cryptonight AMD GPU Miner V1.6.9 - native algo switching
I use that with OD v.0.2.6 on my Sapphire V64 nitro+:
GPU_P0=852;800
GPU_P1=991;820
GPU_P2=1084;825
GPU_P3=1138;850
GPU_P4=1150;910
GPU_P5=1202;875
GPU_P6=1212;875
GPU_P7=1478;920
Mem_P0=167;800
Mem_P1=500;800
Mem_P2=800;825
Mem_P3=1100;910
Fan_Min=400
Fan_Max=2400
Fan_Target=40
Fan_Acoustic=0
Power_Temp=65
Power_Target=0
Try to set target temp to 50C to look what should happen.
Re: SRBMiner Cryptonight AMD GPU Miner V1.6.9 - native algo switching
Again, temps are pretty much identical on both cards, and were still the same when the second GPU worked at full. With Claymore Cryptonote miner both were running fully, but there's no new releases that support v8. I don't know what's the issue, it seems so random. First Windows update made it working correctly for several minutes?. Then the BIOS update for a couple of hours. After that initial window its the same story again. My last resort is reinstalling the Windows again.
BTW what is that card vendor/model? And what is your overdriventool config.
Re: [JCE] Ultrafast CN-Heavy/Tube/HVX miner, low power, Vega56 1750+ h/s
JSON: is it really forbidden by the json standard to write
Code:
"a" :
{42}
rather than{42}
Code:
"a" :{
42}
?42}
It may be acceptable by json standard but any json validator fixes the code that way.
May be the problem occurs when using 'json.parse' where every single string should be understood as it should be. For example the string starting with "hashrate": should end with a value or a bracket.
I maybe wrong ofcourse.