So probability is not the only thing that matters.
Sorry, but your wrong. Probability is all that matters, and regardless what you think or see in the short term does not matter, so your point is not valid. Regardless of whether your solo or pool mining, the def fee wont change hard math. Over time, If you solo mine 100 blocks, 1 block will be missed due to the dev fee on average. If your on the pool your hashrate will be shown 1% less on average. In the theory it is the only thing that matters but I think there are other things to consider aside from theory. Let's think about a possible scenario: I mine solo with my 300 mh/s and I should hit one block every 1.5 days. If 1.5 days pass and I didn't hit a block, then I can say I missed a block. This can be due to dev time or just to bad luck, let's say it is due to dev time. Then I need to find a block "within time" the next 99, on average. This means that, if everything goes on average, after 150 days my figures will be correct. What if, by chance, I miss 2 blocks due to dev fee? Then I need luckier times or I will go to 300 days to even out. When the hashrate is so little as mine, it is possible that you need a lot of time for your figures to even out if you had bad luck. And POW is not forever. Is this a correct thought? If it is not a wrong thought, then there is a hashrate threshold below which it is dangerous to solo mine with CDM because you risk to not even out in case of bad luck. And then for the real mining, not the theory, probability is not only thing to take into account. Please I insist, I am not a math guy, correct me. Your point of view is wrong but it seems it's a complex task to prove that to you. I will try one more time. For example, you mine for one hour with some hashrate. Within this time there is some probability to find a block. After that, you mine for 59 minutes with the same hashrate. Will you agree that the probability to find a block now is less by 1/60? If you agree, you must also agree that 1% devfee time reduces probabilty to find a block within any time with any hashrate by 1%. If you don't agree, it means that you think that 1% of time means more than 0.01 of 100% time - I can advice you to read some book about probability theory. Before that, don't even reboot your rig because you will lose all blocks because of missed 1 minute of mining  |
|
|
|
@Claymore my cards running without fan attached , so i get error 20:38:35:439 20896780 Failed to get fan speed info
20:38:35:439 20896780 Failed to get fan speed info
which is fine. But it seems that this error breaks the temperature read out. Always get zero temperature. It is because miner drops any temp/fan related actions if there is any error because it can cause problems in further calculations, for example, miner must know fan speed if you specified temperature management, or if remote control asked it. It is possible to implement more complex logic, but currently you are the first person that shows me this error. I'm curious about your hardware and cooling. |
|
|
|
4. can you add rig parameters like, CPU, RAM, GPU type etc.
haha... new bot-net soon will be created? if rig urs - u know rig configs. If you have 20+ rigs, then you don't remember configs. I have put my 25th GPU into action with CDM 4.3, and I plan to also use other CPU and RAM types for the next batch. I foresee I will have a challenge to keeping up with rig configs later, I have to revert to spreadsheet at the moment. Perhaps Claymore can put a generic "remark" field at the end of each miner, so that we can store a 30 chars notes. It's a good idea, I will add it. |
|
|
|
It would be cool to have ping in remote manager Anyway, thank you for it. Made a small PHP thing for myself   If miner is not available, it becomes red. Why do you need ping? |
|
|
|
And by the way, I wouldn't use CDM to solo mine. When you solo mine, you don't want 36 or 72 seconds per hour not mining for yourself because in this time it can be when you're gonna hit a block. If you are pool mining then it is ok because shares you will be hitting a lot anyway. I'll give you an example: a few months ago when I was still solo mining, I was gonna stop one of my rigs and in the time between hitting CTRL and C this rig found one block.
Your logic is incorrect. Miner will send 1% or 2% of mining time anyway - pool or solo modes. Probability to find the block in solo mining when miner is busy in devfee mining is the same 1% or 2%. So check your math again. You're right in the probability thing. What I mean is that unless you have a huge hashrate and are solo finding blocks all the time, the situation is not like in pool mining. I miss a share in devfee time when pool mining and I don't care because it will even out in no time. I miss a block in solo mining and it will take ages to even out. And meanwhile the difficulty will be raising making the chance to even out smaller. Unless you have a huge hashrate, as I said. Please correct me if my thoughts are wrong. I can only say the same: Probability to miss the block in solo mining when miner is busy in devfee mining is the same - 1% or 2%. Not more. In your point of view, you afraid that you can miss the block. Yes you can miss it, but probability is 1-2%. But for the rest of time (98%-99%) you pay nothing for devfee at all because you would check weak hashes anyway. About slow/huge hashrate: if you mine solo with slow hashrate to find one block, probability to miss it due to devfee mining is the same - 1-2%. Of course if you are very unlucky (1-2%), you can miss it immediately. But if you are unlucky, you can also search for a block forever. It is not a devfee problem, it is a problem of bad luck. On other side, if you are lucky a bit (98-99%), you will lose absolutely nothing for devfee in solo mode. |
|
|
|
Hi it seems that eth_submitHashrate in eth-proxy mode is lacking the worker parameter: {"id":6,"jsonrpc":"2.0","method":"eth_submitHashrate","params":["0x7b64145", "0x000000000000000000000000000000000000000000000000000000009ff1e5fb"]}While a request from eth proxy for eth_submitHahrate looks like this (when worker ids are enabled): {"id":6,"worker": "rig1","jsonrpc":"2.0","method":"eth_submitHashrate","params":["0x7b64145", "0x000000000000000000000000000000000000000000000000000000009ff1e5fb"]}
Maybe you could add the worker param to the request if it is set. Ok I will do it. |
|
|
|
So does the miner stop mining when a new block is found or only when its submitting a share?
For solo minig mode every share in the miner means a block because share target = block target. Miner will continue mining when block is found, exactly as it works in pool mode. |
|
|
|
And by the way, I wouldn't use CDM to solo mine. When you solo mine, you don't want 36 or 72 seconds per hour not mining for yourself because in this time it can be when you're gonna hit a block. If you are pool mining then it is ok because shares you will be hitting a lot anyway. I'll give you an example: a few months ago when I was still solo mining, I was gonna stop one of my rigs and in the time between hitting CTRL and C this rig found one block.
Your logic is incorrect. Miner will send 1% or 2% of mining time anyway - pool or solo modes. Probability to find the block in solo mining when miner is busy in devfee mining is the same 1% or 2%. So check your math again. |
|
|
|
Thanks for the answer, is this mean that lowering number of threads will increase the eth speed?
Yes, a bit, on some cards. But there is no way to reduce number of active GPU threads, all are always active. May be you can disable some compute units via bios, but I'm not sure if it helps because in dual mode all compute units are active but some of threads are busy with decred. |
|
|
|
Claymore can you format your json output with key value pairs? Current output is very hard to parse and get individual values.
{"id": 0, "result": ["4.3", "8", "93479;11;0", "18352;18914;18191;18809;19210", "0;0;0", "0;0;0;0;0", "67;53;66;50;66;48;56;61;60;56", "us1.ethpool.org:3333"], "error": null}
something like result.eth_mh would be great to get just the hashrate value for example.
I won't change format without a serious reason. If you want to get hashrate and cannot use any json lib (which would be the best solution) you can just find 9th " character and then first ; character and take the number between them. Looks like not a big deal. |
|
|
|
Thanks to Claymore for new version!
I have some feature request if it possible.
It will be good to doesn't exit miner if -tstop is exceeded, but switch off specific GPU with overheat from mining like sgminer does.
Ok, I will do it. Claymore, Why does your miner produces a low hash rate of Ethereum in single mode, compared to dual mining?
The reason is memory accessing/caching. When all GPU threads are accessing memory by random addresses at the same time it causes some overload. When some threads are busy with Decred and don't access memory, overload is less and other threads can get required data a bit faster. Because there is no way to freeze some threads I cannot use this behaviour to improve mining speed in Ethereum-only mode. |
|
|
|
Claymore, can we point EthDcrMiner64.exe to any config file or does it have to be named config.txt
For example use a .bat with EthDcrMiner64.exe this_is_my_config.txt
like sgminer can do with .conf files.
Currently it must be named "config.txt". In next update I will improve it so you will be able to point it to any filename. |
|
|
|
Ok, I will add it in next update.
Description "API" will be available, or itself through "wireshark" look? Just need the ability to monitor under Linux and Android. The format is very simple, so no documentation for now, use wireshark. |
|
|
|
Hey claymore...
I noticed the epools.txt & dpools.txt ... the commas are used as delimiters for parsing.
This caused a problem w/ the PSW setting, one of the pools I mine on takes commas as worker config parameters.
Any chance they can be escaped in the epools/dpools file somehow?
Ok, I will add it in next update. |
|
|
|
Anybody has issues with 4.3 monitoring on Linux?
@Claymore:
Tried few 4.3 beta (as soon as they were updated). One of them dumped some error and segfaulted. Updated to the latest, the same issue. Restarted - it worked some time with monitoring utility, then turned red and no more updates. The miner itself worked. Restart helped to recover, worked few seconds and gave me the same error:
I'm working on this issue, I will upload an update for Linux today. |
|
|
|
complete log-file
Finally I got it. Issue confirmed and fixed, re-download v4.3, log must show "b142" now (means build 142). -erate: Check OP or readme for sample how to specify worker name for dwarf. Hint: -ewal YourWallet/YourWorkerName. Don't use -erate option because it is already "1" by default. |
|
|
|
So far, I know: Request: {"id":0,"jsonrpc":"2.0","method":"miner_getstat1"} Response: {"id": 0, "error": null, "result": ["<App_version>", "<Uptime(minutes)>", "<Eth_Mhs>;<Eth_accepts>;<Eth_rejects>", "<Eth_Mhs>", "<Dcr_Mhs>;<Dcr_accepts>;<Dcr_rejects>", "<Dcr_Mhs>", "<GPU_temp>;<GPU_fan_%>", "<Pool>"]} But I dunno how to make that request... Claymore, can you please tell us more info about it? It's usual tcp/ip connection - create socket, connect, send the string "{"id":0,"jsonrpc":"2.0","method":"miner_getstat1"}" and read response, disconnect, that is all. |
|
|
|
@claymore: Do you plan any output from the miner itself maybe in json format ? This would be killer feature for miner with more then just a few rigs to build central monitoring
Miner sends stats in json format, use wireshark or similar tool to see format. So you can write own monitoring utility if you want. |
|
|
|
Something wrong, on two mashines, miner crash (not freezz, but process crash):
Confirmed, probably this issue is related to Linux version only. I just saw this on my test linux rig. Since it works for several hours before crashing, it will take some time to fix it. |
|
|
|
This is the part of log-file Nothing has changed in 4.3, the bug is present. I don't need part of log. I need full log. It is because I have a rig with several 290X and I cannot reproduce the issue that you mention. So the complete log file is the only thing that can help me. win7 x64/16gb page-file size/8gb ram/catalyst 16.1 (nothing has changed with 15.12/15.11/16.3) Sorry, I will ignore your issue until you PM me complete log file. |
|
|
|
|
Show Posts
