 Show Posts
|
|
Pages: [1]
|
Rigel 1.11.1
The miner does not cache more than 1 DAG for kawpow algorithms in video memory (like gminer). This option is very useful for nicehash |
|
|
|
Rigel 1.10.1
Dag builts whithout memory offset when ethash. Add this as option to kawpow, please. |
|
|
|
Rigel 1.9.2
Hi! SOCKS5 proxy is not supported? |
|
|
|
All versions 16.x.x do not work in windows 7.
Panic: runtime error: invalid memory address or nil pointer dereference.
Fix please.
Same |
|
|
|
Does anyone have such problem - on Win 7, v15, drvs 436.30 and 441.66 and GTX1070 cards hashrate is about 22Mhash.... Tried to clean drivers with DDU and reinstall them, tried with/withous straps, w/wo OC etc.... On other algorythms speed is same as before, no change. And some months ago with older claymore all was fine, but now, with v15 such problem
upd: same issue on Phoenix miner, but all fine on nanominer and gminer.... can't even guess what it can be...
Confirmed, got the same issue on 1070TI. Problem is related to ETC mining. Hashrate drops to 17-20 MH/s when mining ETC. Tested on Nicehash and Ethermine ETC pool. Tried almost all avaiable miner software (Claymore, PhoenixMiner, GMiner, Ethminer 0.18/0.19a) and always got the same behaviour. Probably this only related to Nvidia cards, or even Pascal family. Also confirmed, win7 and GTX1070 low hashrate on ETC. win10 - ok. |
|
|
|
I think I have corrected the bulk of these problems, however for the remaining, I will force the miner to crash, so it can be restarted. I will publish an update tonight
Thanks for the development. |
|
|
|
was there a problem when it happens like a lost of connection ? (this really doesn't happen in normal condition)
I haven't logs and screenshots now, but very similar like here: ...Sometimes
- miner stops completely / script loop not working because the process is still alive
- miner is flooded with stratum errors / no accepts
- miner is flooded with increasing nonce / no accepts ...
|
|
|
|
yes would be good. How big was the memory leak ?
RAM and swap usage increases until all memory is full |
|
|
|
I did a rapid check over several cycle (initialization, mining, change of block etc...) I don't see any memory leak. The amount of swap and RAM vary along a cycle however it is always freed before a new initialization. The only case which could cause subtantial increase of RAM would be running at very low difficulty where you would be solving solution faster than you send them to the pool (but again, once it is sent to the pool, the memory is freed). If it is the case, you should probably increase the difficulty
I watched a memory leak after several hours of stable mining. I'll try to make screenshots next time. |
|
|
|
--debug, after you can just use >> log & (on linux)
There may be a memory leak. I see an increase of RAM and swap usage in 1.1.22. I saw the same thing in some early version. |
|
|
|
Yes my bad. Please delete NeoScrypt.dll from the algo folder.
Sorry - forgot to delete it.
Yes, now working fine! |
|
|
|
Hello  There was such a mistake and only in this miner. Win 8.1 x64   msvcp140d.dll is debug version Any idea what that mean??? Some people reported only 50% hashrate using Windows 7! try to compile without debug versions dll's |
|
|
|
Hi dgeo, this has been added in the latest version, v1.0h.
Hello! It works fine but shows average ping rather than actual. When I start mining, I see a large ping and after a while it becomes relevant. And hive os support is also interesting Thanks for your job |
|
|
|
|
Nice job
[ 0d 3h34m39s] S:248/1 215(217) [btg.2miners.com] (97.9) (2.1)
0>GTX 1070 [63°C/87] 27.19 I/s 54.8(54.2) Sol/s 155.1W clk=1911MHz mclk=4353MHz Sol/W=0.35
1>GTX 1070 [63°C/87] 27.18 I/s 53.2(54.4) Sol/s 169.4W clk=1923MHz mclk=4387MHz Sol/W=0.32
2>GTX 1070 [61°C/85] 27.46 I/s 53.9(55.0) Sol/s 161.1W clk=1923MHz mclk=4387MHz Sol/W=0.34
3>GTX 1070 [65°C/92] 26.43 I/s 53.4(53.0) Sol/s 138.9W clk=1911MHz mclk=4387MHz Sol/W=0.38
about +10% than ewbf with same settings
Please add pool ping
|
|
|
|
|
