Effective capacity less than the actual capacity


#1

mine at http://burst.btfg.space/, but the effective capacity is less than the capacity of my HDD. I have 25TB in HD, but in mining it appears that I have 3,250 TB of effective capacity. Can someone help me?


#2

Can you show a screenshot of your miner in action?


#3

I believe that effective capacity is based on your activity that helps the pool. Now remember that a lot of this is based on luck, and so it will vary day by day, week over week. Give it some time and it should average out.

I’m currently running 100TBs and my effective is at 71TB, but I expect that to change over time to even out.

Cheers,
Paul


#4

That’s it. is increasing gradually. already in 8TB. Does anyone know if I need to optimize my plot files? I did the plotting by XPLOTTER


#5

There are two things that will help your effective capacity out.

First, make sure your scan times are fast.

Second, set your deadline limit to something more representative of your capacity.

You can read on this page, “Choosing a Reasonable TargetDL”.

http://burst.btfg.space/info

I have one miner I manage that has 28TB. I set the deadline to 9000000, and the effective capacity is almost right on the money.


#6

Thank you, it helped me a lot. I put my DL to 6000000.


#7

So I get home all ready to tweak my target deadline but I can’t find that setting for jminer.
There is a targetDeadline but it is only for Solo Mining, not Pool Mining.
Am I missing something?

In fact I just saw in my jminer output a line that said: dl ‘141539541’ > ‘31536000’ skipped
So that makes me think that jminer knows the pool limit of 31536000, and won’t send anything larger than that.

Thanks


#8

I haven’t used jminer, but I do know the miners use info from the pool. However, this is their hard limit.


#9

That was my suspicion, that miners got DL clues from the pools.

Thanks


#10

yes, MasterMC, as far as i know jminer uses the pools targetDL if there is one. This is an unfortunate feature of jminer for the new pool software. I am not sure if it got fixed in the newest version already, but otherwise i would recommend to switch to creep or blago miner. There you can set your own targetDL independent from the pools.


#11

So for the real question, do I care that my effective capacity is half of what my actual capacity is? Does it affect the historic payout in any way? If it does then I’ll do everything I can to fix it, but if it doesn’t I’m okay using jminer.

Thanks


#12

On some pools it will make a difference. Not sure on btfg but on crypto it makes a huge difference. Network difficulty is a factor on effective capacity so keep that in mind. Crypto pools have a calculator for target dl’s you should check out


#13

Yes it directly affects your historical share. If it shows only half of your actual capacity, your historical share is only half of the value it can be.


#14

Thanks everyone. I’ll spend some more time trying to get creep to mine.

Paul


#15

I must be missing something but I am unable to find creepMiner pre-compiled with opencl support. Any suggestions. (I did get it working with AVX, so I’m close.) I need to GPU mine as my CPU is practically single-threaded.


#16

i think one of the older versions came with precompiled gpu support (version 1.7.6 maybe?). But today an update got activated that should have improved your effective capacity a bit. As you are still at 50tb of 100tb you should maybe doublecheck your plotfiles for overlaps.


#17

I do have some overlap but we are talking a nonce or two per file (I forgot to +1 for my next starting nonce). I’ll run creep for a day after tweaking the DL. Right now I am only getting 30-40MB/s using AVX. Not sure what I was getting with jminer as it uses total plotfile size to determine MB/s, so it was like 300MB/s or something crazy unlike blago and creep which use actual read speeds.

If I find some time I might go about hacking the jminer java and adding a manual deadline and see how that does. Hmmmm

I went with 2301602 which is about 26 days (338894 * 720 / 106).


#18

Thanks @Herscht for the pointer. I did find an opencl version, playing around with it now.
I’ll keep the 26 day deadline and see if my effective capacity goes up over the next 360 blocks.
Thanks for the assist!


#19

Now I am down to 10TB effective capacity. I think I need an intervention. Who wants to help me out?

E:\creepgpu>creepMiner.exe
14:08:25: creepMiner 1.7.6 Windows x64
14:08:25: Release mode +CUDA +OpenCL +SSE4 +AVX +AVX2
14:08:25: ----------------------------------------------
14:08:25: Github:   https://github.com/Creepsky/creepMiner
14:08:25: Author:   Creepsky [creepsky@gmail.com]
14:08:25: Burst :   BURST-JBKL-ZUAV-UXMB-2G795
14:08:25: ----------------------------------------------
14:08:26: There is a new version (1.7.16) on
14:08:26:       https://github.com/Creepsky/creepMiner
14:08:26: Available OpenCL platforms:
14:08:26:       Platform[0]: AMD Accelerated Parallel Processing, Version: OpenCL 2.1 AMD-APP     (2527.8)
14:08:26: Using platform[0]
14:08:26: Available OpenCL devices on platform[0]:
14:08:26:       Device[0]: Hawaii
14:08:26:       Device[1]: AMD A6-6400K APU with Radeon(tm) HD Graphics
14:08:27: Using device[0]
14:08:28: Successfully initialized OpenCL!
14:08:28: Submission Max Retry : 10 seconds
14:08:28: Buffer Size : ~24 GB
14:08:28: Submission URL : http://burst.cryptoguru.org:8124
14:08:28: Mininginfo URL : http://burst.cryptoguru.org:8124
14:08:28: Server URL : http://127.0.0.1:8080
14:08:28: Log path : E:\creep\logs\creepMiner_20180303_200825.653220.log
14:08:28: Total plots size: 97.52 TB
14:08:28: Mining intensity : 3
14:08:28: Max plot readers : 8
14:08:28: Get mining info interval : 3 seconds
14:08:28: Processor type : OPENCL
14:08:28: Benchmark mode activated!

#20

Well you have to wait 24-30 hours to come to any conclusion. But 10tb seems very low, while waiting you may use the time to doublecheck your plots for overlaps :smiley: maybe you made some mistakes and have more overlaps than expected … already had some cases of people who were very cautious while plotting but still got some larger overlaps.