Is it possible to mine ETC and ZIL after the EtcHash fork?
Yes, it should be. Cause ETCHash and Ethash are identical up to epoch 390 and Zil uses epoch 0 - ETC + Zil should be no issue.
I got some doubts
1 - have the watchdog enable by default to watch if some gpu is dead and restart himself? or we only have the emergency .bat ?
2- can you insert some json config file example?
3- Have lolminer some discord or telegram?
4 - where can we see eth dag countdown time?
1) Well right now there is only the .bat ... but into this you can insert a line of code to kill the miner and to restart it. But often this does not work, cause a hung up AMD card sadly often requires a rig reboot. So thats why I created the opportunity with this scripts for mining OS to pick up the call to issue a reboot.
2) Yes, ofc
For example:
{
"DEFAULTS" : {
"DEVICES" : "AUTO",
"APIPORT" : 8080
},
"EXAMPLE_BEAM" :
{
"ALGO" : "BEAM-III",
"POOLS" : [
{"POOL" : "beam.sunpool.top",
"PORT" : "3334",
"USER" : "32f2e8765c2e8f5ea41becc5f397024c94d80cc5fc50ee917af23b260ecb3a5f.testMe",
"PASS" : "x"}
]
},
"EXAMPLE_GRIN_32" :
{
"ALGO" : "C32",
"POOLS" : [
{"POOL" : "eu.stratum.grin-pool.org",
"PORT" : "3416",
"USER" : "Lolliedieb",
"PASS" : "testRigName"}
]
}
}
This is a file with one default profile (always loaded options) and two coin profiles (that can be selected via --profile). Note that "POOLS" is a vector - so that can have multiple entries for fail-over. Also field "TLS" : 1 can be used in there for activating TLS.
3) I have a telegram channel:
https://t.me/lolMiner Also you can find me e.g. in Red Panda Discord.
4) Good question. Hard to build in the miner, cause the pools do not send the current block height. But the epoch changes every approx 5.5 days
hi, Beam Hash III unsupporte version o drive version amd r9 380 adrenalina 20.10.1 and 20.9.1 same error, any solution?
Oh ... let me check that... and fix for 1.13
Sorry, I was wrong to write about the epoch.
I meant that when the epoch changed to #372 I was already using version 1.12 for a few hours.
Yes, I'm trying these settings too: --keepfree 16 --4g-alloc-size 3992
Currently it seems stable even if the hashrate has dropped by about 2MH
Your problem is that 3992 MByte is the size for epoch 371 (1024 + epoch*
, so with 3992 your miner will already be in Zombie mode and thus mine slower. Can you test if you can put the --4g-alloc-size higher? (maybe with higher --keepfree)?
Let me try to explain the issue: Windows memory allocation is a pretty mess. Although the card reports x MBytes are free one does not have an always working strategy to get this free memory. In Linux I just need to create two buffer, with the first one in size of cl_device_max_mem_alloc_size (a value the driver reports) and the 2nd buffer taking the rest. Done and works.
On Windows I need to create 4 (!!) buffers to allocate a lot of memory at all. Here then the first one needs to be cl_device_max_mem_alloc_size minus some MBytes (this is controlled via --keepfree) ... using it all does not work different to Linux
The other three buffers need to be around ~64 MByte, where the last one often already has to be 32-48 MByte max. What happens if I take more? Well then the Windows drivers do put them in system memory instead of on the card and the mining drops to 1 mh/s or so ...
So: --keepfree is capping the first buffer, --4g-alloc-size sets the amount of memory for all 4 together. Sadly even 3 identical cards in one rig might act differently in what they accept. Also in one driver (2020.09) my 4G allows a --4g-alloc-size up to 4026 (slightly more then epoch 375) while on an other its only 4008. Also moving same card to a friends rig there then the max is 4016. So well ... it is a mess and I tried to give the two parameters to config it somehow and rewrote the kernel so either configuration does no longer give invalids. But it is hard to predict what this drivers do and if you want to mine ETH really long I would suggest installing a Linux on an USB drive - that is far more reliable.
