L3 Miner Very Inefficient

[Swimmer63]

I could use some direction or suggestions for my L3+ Miner on this pool. I started on this pool for the first time about an hour ago and my mining efficiency is only 85%.

In the password field I only listed "a=scrypt n=worker1". Difficulty and targeted difficulty right now is 262,144.

Are there any settings I can add or change to improve my efficiency? Anything that every L3+ needs maybe?

I really don't want to switch pools, but I can't keep mining at 85% either. I have another L3+ I would like to move to this pool too if I can solve this.

Thanks in advance.

[ArjunaX]

I am running everything default on my L3+ and I've consistently had efficiency around 95-100%, EXCEPT yesterday I was stuck around 70-80 all night. Tons of rejected shares. I think it may be related to an issue Steve is working on, not sure. I'm back at 100 now.

[micca410evo]

you can remove a=scrypt, since this is the default setting. I heard lots of guys with L3 setting d=131072

Good luck

[hashingpro]

You may want to also give it over 2 hours.
Im told the average mining efficiency reading is a 2 hour reading.
Not having readings for a full 2 hour spread will give inaccurate readings on the dial.

After 2 hours see if it has come up any, im just about at 94% for the day.

[JKDReaper]

Personally I seem to have better efficiency using g 131k difficulty, but the over all efficiency of the pool is down, they are working to fix it now

[Swimmer63]

Thanks. The pool is down so I have to go by what my miner is telling me. After removing a=scrypt and adding d=131072, I'm averaging 92.2% efficiency over the past few hours. Still not great, but a 50% improvement from where I was.

Will stick with it for 24 hours and see what the payout looks like.

I like this pool because it takes care of all the converting to btc. H2C and Multipool.us drive me crazy with all their wallets. Nicehash is good but one L3+ is in Washington state and the other is hosted in Colorado. The Colorado one won't stay connected to Nicehash for some reason.

[dog1965]

try this I have a l3+ and these settings work nice for me. use winscp go into your L3+ miner go to main root directory then into your config folder and edit user settings it should say "queue 8192" this is how you know your in the right file than just add these two lines to it.


--scan-time=7
--expiry 28

then save file press ctrl-s this will save the file then exit winscp then set yor miner config for d=65535 then just restart your miner you should see much better results it works for me.

[treberto]

What does this do exactly?

[n00bminer]

try this I have a l3+ and these settings work nice for me. use winscp go into your L3+ miner go to main root directory then into your config folder and edit user settings it should say "queue 8192" this is how you know your in the right file than just add these two lines to it.


--scan-time=7
--expiry 28

then save file press ctrl-s this will save the file then exit winscp then set yor miner config for d=65535 then just restart your miner you should see much better results it works for me.

1. how did you get WinSCP to work with open-embedded software of L3+? (I get closed unexpectedly after authentication) Putty SSH works
2. Does not scan-time and expiry work best for http, not stratum based work? YMMV, but see below.

https://bitcointalk.org/index.php?topic ... msg5494025
Also there's a lot of poor and misguided advice on how the expiry, scan-time and queue settings actually influence the rejections you're experiencing.
A lot of these settings were made for HTTP communication and not the much more efficient stratum protocol*.

--expiry
This setting defines how long time it takes before a work share is declared stale.
It is not used on stratum servers, since stratum servers supply it with work shares.
Only exception is when the statrum server is broken, then the setting is used as a fallback value.

Recommendation: Leave at default setting. Server will supply a proper setting.

To verify above simply follow the opt_expiry variable in cgminer.c source file.

--scan-time
This setting defines how long time, in seconds, the client should spend scanning current active work.
Again a setting that is not used on stratum servers, since stratum servers supply it with work shares.
Only exception is when the setting is lower than the server supplied setting, then it'll potentially generate more stale work.

Recommendation: Leave at default setting, which is 30 seconds for scrypt.

To verify above simply follow the opt_scantime variable in cgminer.c source file.

--queue
This setting defines how many work items you minimum got waiting in queue.
It is only relevant to prevent downtime when the stratum server is too slow at serving new work shares.

Recommendation: Leave at default setting, which is 1.

To verify above simply follow the opt_queue variable in cgminer.c source file.

* Stratum mining protocol: http://mining.bitcoin.cz/stratum-mining and http://bitcointalk.org/index.php?topic=108533.0

[Swimmer63]

So it's now just past 24 hours of continuous hashing here. I only made the one change - removing a=scrypt and adding d=131072. Left my n=worker name alone. Pretty much all day I have been at 100%. Had a few dips in the upper 90's, but on average I would say today has been very close to 100%. It definitely took a while to settle in. I wish there was a longer term efficiency figure to look at but I see is the 2 hour rolling average.
From the miner, which has not reset for 23 hours I have 4629 accepted and 317 rejected. 93.3%. But I don't think that's accurate because the accepted shares could be much more dense than the rejected. Not sure the tech term for that.