Rejects are back!
Edit: stratum is also dropping, maybe ongoing work.
|
|
|
Looking good! rejects have completely stopped on power2b.
argon2d-dyn also looks good to me where it didn't before.
Thanks.
|
|
|
and not only. happens on x16, neoscript, often with the password mc = "coin". I feel that one of the miners is connected to the pool with the wrong settings.
12:39:02] INFO - 24/32 Rejected : diff=0.00606529, reason: Invalid job id [12:39:06] INFO - 24/33 Rejected : diff=0.0100769, reason: Invalid job id [12:39:07] INFO - 24/34 Rejected : diff=0.0122791, reason: Invalid job id [12:39:07] INFO - 24/35 Rejected : diff=0.0233635, reason: Invalid job id [12:39:11] INFO - 24/36 Rejected : diff=0.0117603, reason: Invalid job id [12:39:11] INFO - 24/37 Rejected : diff=0.00913617, reason: Invalid job id [12:39:11] INFO - 24/38 Rejected : diff=0.0159683, reason: Invalid job id [12:39:11] INFO - 24/39 Rejected : diff=0.00591861, reason: Invalid job id [12:39:14] INFO - 24/40 Rejected : diff=0.01579, reason: Invalid job id [12:39:18] INFO - 24/41 Rejected : diff=0.0143914, reason: Invalid job id [12:39:22] INFO - 24/42 Rejected : diff=0.0097482, reason: Invalid job id [12:39:22] INFO - 24/43 Rejected : diff=0.0596705, reason: Invalid job id [12:39:22] INFO - 24/44 Rejected : diff=0.00616638, reason: Invalid job id [12:39:26] INFO - 24/45 Rejected : diff=0.0130139, reason: Invalid job id [12:39:26] INFO - 24/46 Rejected : diff=0.00646398, reason: Invalid job id [12:39:27] INFO - 24/47 Rejected : diff=0.00700622, reason: Invalid job id [12:39:28] INFO - 24/48 Rejected : diff=0.00715171, reason: Invalid job id [12:39:31] INFO - 24/49 Rejected : diff=0.0338959, reason: Invalid job id [12:39:32] INFO - 24/50 Rejected : diff=0.0072279, reason: Invalid job id [12:39:33] INFO - 24/51 Rejected : diff=0.00604158, reason: Invalid job id [12:39:37] INFO - Setting new difficulty: 768 (0.0117188) [12:39:37] INFO - Block height 386980 : Network difficulty 0.666345 [12:39:37] INFO - Received new job #9d418 [12:39:37] INFO - 24/52 Rejected : diff=0.00732371, reason: Invalid job id [12:39:46] INFO - 25/52 Accepted : diff=0.0216072 : 9630KH/s [12:39:57] INFO - 26/52 Accepted : diff=0.0237028 : 9631KH/s [12:40:06] INFO - 26/53 Rejected : diff=0.014315, reason: Invalid job id [12:40:13] INFO - 26/54 Rejected : diff=0.015676, reason: Invalid job id [12:40:18] INFO - 26/55 Rejected : diff=0.0122919, reason: Invalid job id
Yup, same problem.The problem is the pool isn't sending new jobs properly so the miner keeps hashing the old stale job. As I demonstrated in a previous post I collected data showing the miner received a job that was already stale and the pool had already rejected shares submitted using it. That's just plain wrong. Would be nice to get it fixed.
|
|
|
Thanks, it was very interesting but a little too enthusiastic. Predicting the future with confidence strained its credibility. Time will tell. Edit: I just noticed that glowing report about yespower was written by the same person testing the experimental ccminer I mentioned earlier. It looks like he has something working but the hash rate appears to be about the equivalent of an i5 CPU. I wonder what card he's testing with.
|
|
|
MicroBitcoin (MBC)-SCAMMMMMMMMMMMMMMM!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Said the newby Explorer is already up and running with it seems. a new and better design. Mobile/webwallet is in progress, should also be up soon. People with such low activity but screaming scam, you're a scam from a bastard and please, talk English, there are special places for kids like you on this forum actually normal people first make a wallet, and then hard fork Why didn't you just say that the first time? You'd look less like an idiot with your excessively exclaimed, unsupported accusation.
|
|
|
very many rejected on DYN (argon2d-dyn) CryptoDredge.
How many is many? What's the reject reason? Does it look anything like this problem? https://bitcointalk.org/index.php?topic=2759935.msg52287385#msg52287385If you get a run of stale shares it could be the problem above. A stale share occasionally is normal. How's your network latency? You'll get more stale shares with higher latency. Ratio 20/80% (80 - rejected) Delay of norms 50 ms. There are no such problems with Suprnova. If it's stale shares it's the same problem I reported previously and still hasn't been fixed. It happens on the new power2b also.
|
|
|
very many rejected on DYN (argon2d-dyn) CryptoDredge.
How many is many? What's the reject reason? Does it look anything like this problem? https://bitcointalk.org/index.php?topic=2759935.msg52287385#msg52287385If you get a run of stale shares it could be the problem above. A stale share occasionally is normal. How's your network latency? You'll get more stale shares with higher latency.
|
|
|
theres no such thing as a CPU only algo if something LOOKS like its being mined by CPUs only, you just havent FOUND the GPUs yet exactly It's technically correct there are no "CPU only" algos, but economically there are. Some algos can't exploit the advantages of GPUs, ie massive parallelism. Algos that use a large amount of memory per thread would severely limit the number of threads that can run on a GPU reducing the efficiency below that of a CPU. As far as that rplant link, I don't know what that means. The pool has no way of knowing what hardware is mining, they only have the agent id from the miner that can show anything the user wants. That being said I did see an agent id that indicated an experimental version of ccminer. I consider that slightly more reliable although, as I said, it's easy to manipulate.
|
|
|
cpuminer-opt-3.9.9https://github.com/JayDDee/cpuminer-opt/releasesAdded power2b algo for MicroBitcoin. Added generic yespower-b2b (yespower + blake2b) algo to be used with the parameters introduced in v3.9.7 for yespower & yescrypt. Display additional info when a share is rejected. Some low level enhancements and minor tweaking of log output. Additional notes: yespower-b2b is yespower with sha256 replaced with blake2b. There is no default parameter configuration when using yespower-b2b, the N and R parameters and the personalization key, if used, must be specified. The parameters work in the same way as yespower (sha256) and yescrypt. power2b is just yespower-b2b with the parameters preset for power2b.
|
|
|
Before this becomes a FAQ...
Power2b algo now used by MicroBitcoin is incompatible with current yespower code and can't be mined with cpuminer-opt at this time.
A new version is required. I'm working on it.
|
|
|
rainforestv2 algo was good. i didnt like only cpu mineable algo.
The problem is most traditional GPU algos are too easy to implement with ASIC or FPGA, But that may be changing with some novel new algos.
|
|
|
Thanks. I will need to copy modified yespower + blake2b code, too dificult to integrate.
|
|
|
The following post by me should be ignored. Power2b is incompatible with current yespower code and requires a new miner. Microbitcoin has successfully forked to a new algo. The GPU unfriendly yespower algo.
hm where can i find the AMD GPU miner for yespower? tought it was CPU only xd MY BAD Its yespowerr16? Any pool working on it? on skypool 100% rejected with yespowerr16 Ah its not yespowerr16 i see The algo is called power2b apparently based on yespower but I don't know the parameters. The OP and the web page still refer to rainforestv2. If the parameters are known it should be mineable with cpuminer-opt. https://bitcointalk.org/index.php?topic=1326803.msg52048536#msg52048536Edit: I found the parameters. I tried it at zergpool but it doesn't look like the stratum is running yet, so YMMV. -a yespower -N 2048 -R 32 -K "Now I am become Death, the destroyer of worlds"
|
|
|
Basically i am wondering if this is the unit or a power supply issue as id rather not keep burning out power supplies.
My guess is a short in the unit since swapping the PSU didn't fix the problem.
|
|
|
The stratum crash noted above is fixed in v1.2.3, and the 1080ti hashes fine and submits valid shares. Thanks. Edit2: Nevermind the following, the 970 ony has 4 GB mem. But ccminer exits on GTX970. Makefile has compute 5.2 so I assume Maxwell is supported.
[2019-10-08 14:02:32] Starting on stratum+tcp://mtp.mine.zergpool.com:3000 [2019-10-08 14:02:32] 1 miner thread started, using 'mtp' algorithm. [2019-10-08 14:02:37] Stratum difficulty set to 0.119207 [2019-10-08 14:02:37] GPU #1: Intensity set to 21.0156, 2129920 cuda threads number of multiproc 13 cudaErrorInvalidValue
I tried setting a lower intensity but it always reported the same intensity and threads. Not sure if it's related to the crash or a seperate issue.
Anything I can do to help?
Edit: tried the Windows version, same problem. It looks like Maxwell isn't supported after all.
|
|
|
How about lyra2v3?
Also you're missing a few things in Makefile.am: sph/tiger.c and compute 7.
|
|
|
@pinpins
There appears to be a stratum difficulty problem with x16rv2.
I tried to set a lower diff using "-p d=2" (default is 5) but the pool reports diff 2.5. As a result I occasionally submit low difficulty shares (between 2 and 2.5 presumably) which are rejected.
I tried d=2, d=2.5, d=3 but all three result in 2.5 at the pool and 2 at the miner.
Using the default both pool and miner report diff 5.
Possibly an issue with fractions?
|
|
|
I run the codes more than once and they aren't stable, I saw some 200+ ms. What is causing this unstable pings?
Probably your wifi, it's sensitive to all kinds of things that interfere with the signal. Mining is also very sensitive to network latency. It's a bad combination. There are things you can do to improve the wifi signal (distance, obstructions, antenna positioning, better router, etc) but still might not be ideal. An ethernet cable is much simpler if possible.
|
|
|
cpuminer-opt-3.9.8.1
Summary log report will be generated on stratum diff change or after 5 minutes, whichever comes first, to prevent incorrect data in the report.
Removed phi2-lux alias introduced in v3.9.8 due to Luxcoin's planned fork to a new algo. The new Luxcoin algo is not supported by cpuminer-opt. Until the fork Luxcoin can be mined using phi2 algo.
--hide-diff option is deprecated and has no effect. It will be removed in a future release.
Edit: TTF estimates and hash rates for algos like x16r that have variable hash rates are innacurate. No solution is apparent.
|
|
|
The problem can be virtually eliminated by running the cpuminer at a lower priority than the GPU miner. When the GPU's CPU support thread needs to run it will immediately preempt a cpuminer thread. Other than a dirty cache it's the same as if the CPU had been idle.
Running the cpuminer at a lower prio will also prevent it from competing with other processes running at the default prio.
|
|
|
|