Bitcoin Forum
December 13, 2024, 09:36:03 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Weird Solo Mining Problem  (Read 893 times)
daserpent1 (OP)
Sr. Member
****
Offline Offline

Activity: 435
Merit: 250



View Profile
June 08, 2013, 07:20:26 PM
 #1

I have been trying to mine some of the new coins like InfiniteCoin, AnonCoin, DigitalCoin, Worldcoin etc
and I noticed that my miner gets the latest blocks too late.

Sometimes, i get a new block after 2 or 3 new blocks have already passed. And as a result,
I get too many rejects (as the block that i solve has already been solved)

What should I do to make sure that the miner gets the New Blocks as soon as it is
available on the network???

This issue is true with all solo mines (dgc,wdc,ifc...) I don't have this problem when pool mining.
aa
Hero Member
*****
Offline Offline

Activity: 544
Merit: 500


Litecoin is right coin


View Profile WWW
June 08, 2013, 07:27:11 PM
 #2

Get a better Internet connection.

devilfish
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
June 08, 2013, 07:33:30 PM
 #3

If using cgminer you can try changing the --expiry and some other settings, which is something that I have found to help.

Just look at the readme for it on github, all the info is there.
Remember remember the 5th of November
Legendary
*
Offline Offline

Activity: 1862
Merit: 1011

Reverse engineer from time to time


View Profile
June 08, 2013, 07:36:09 PM
 #4

Oh, ok. This problem is caused because cgminer gets new work every X seconds, depending on how long it takes for the device to scan the nonce space, and because solo mining(unless patched) has no Longpoll/Stratum.

So essentially, going at ~270-280Mh/s it will take about 15-16 seconds before cgminer gets new work, and the process repeats itself.

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
daserpent1 (OP)
Sr. Member
****
Offline Offline

Activity: 435
Merit: 250



View Profile
June 08, 2013, 07:46:38 PM
 #5

I have 1.3Mh/s .. should i try the expiry command?
devilfish
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
June 08, 2013, 07:54:45 PM
 #6

https://github.com/ckolivas/cgminer has an explanation of everything relevant to cgminer proper, along with scrypt and gpu specific settings.

you could lower the scan time using the -s flag, expiry is at default 120 seconds and can be changed with the -E or --expiry flags, you could also try shortening the queue that your miner is using via the -Q or --queue options. Really there is no universal advice and you'll just have to try playing with a couple of flags and options until the solution is fixed. I recommend copying the base file and trying new configurations in the copies until you get one that works really well and then using that as the new base.

Additionally, you could decide that ignorance is bliss and just set --no-submit-stale

Also, a caveat to the above, just because the miner thinks the share is stale does not mean that it always is
Remember remember the 5th of November
Legendary
*
Offline Offline

Activity: 1862
Merit: 1011

Reverse engineer from time to time


View Profile
June 08, 2013, 07:54:46 PM
 #7

I have 1.3Mh/s .. should i try the expiry command?
Don't bother with that hashrate. You are mining with an Intel HD graphics card, your CPU or a slow Nvidia card. Point being it's not worth it.

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
devilfish
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
June 08, 2013, 07:57:14 PM
 #8

I have 1.3Mh/s .. should i try the expiry command?
Don't bother with that hashrate. You are mining with an Intel HD graphics card, your CPU or a slow Nvidia card. Point being it's not worth it.

Solo mining with 1300Kh/s is viable if the target difficulty is around 14.5K, I run with 1.86Mh/s and do alright. I think you may have misunderstood his post as he is talking about scrypt coins and not sha256
ccplz
Full Member
***
Offline Offline

Activity: 257
Merit: 116



View Profile
June 08, 2013, 08:00:13 PM
 #9

I have 1.3Mh/s .. should i try the expiry command?
Don't bother with that hashrate. You are mining with an Intel HD graphics card, your CPU or a slow Nvidia card. Point being it's not worth it.
Scrypt  Tongue
daserpent1 (OP)
Sr. Member
****
Offline Offline

Activity: 435
Merit: 250



View Profile
June 08, 2013, 08:06:02 PM
 #10

Thanks for the replies guys. I added the following and it seems to be catching up pretty quick now

-s 1 --expiry 25 --queue 0

I suppose the expiry needs to be little less than average block time (which is 30 seconds for infinitecoin and 2.5min for litecoin)
Remember remember the 5th of November
Legendary
*
Offline Offline

Activity: 1862
Merit: 1011

Reverse engineer from time to time


View Profile
June 08, 2013, 08:06:45 PM
 #11

I have 1.3Mh/s .. should i try the expiry command?
Don't bother with that hashrate. You are mining with an Intel HD graphics card, your CPU or a slow Nvidia card. Point being it's not worth it.
Scrypt  Tongue
My mistake then, I guess I didn't read right.

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
devilfish
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
June 08, 2013, 08:19:40 PM
 #12

Thanks for the replies guys. I added the following and it seems to be catching up pretty quick now

-s 1 --expiry 25 --queue 0

I suppose the expiry needs to be little less than average block time (which is 30 seconds for infinitecoin and 2.5min for litecoin)

Yep, it's always going to depend on the particular situation at hand. New coins usually need 0 queue and a low expiry whilst more established ones can run fine with the default. Just like the --gpu-engine and --gpu-memclock all the options require a little love to get them running perfect. Glad you got it fixed
daserpent1 (OP)
Sr. Member
****
Offline Offline

Activity: 435
Merit: 250



View Profile
June 08, 2013, 08:23:30 PM
 #13

Thanks for the replies guys. I added the following and it seems to be catching up pretty quick now

-s 1 --expiry 25 --queue 0

I suppose the expiry needs to be little less than average block time (which is 30 seconds for infinitecoin and 2.5min for litecoin)

Yep, it's always going to depend on the particular situation at hand. New coins usually need 0 queue and a low expiry whilst more established ones can run fine with the default. Just like the --gpu-engine and --gpu-memclock all the options require a little love to get them running perfect. Glad you got it fixed

Thanks, what expiry should I set for litecoin ? 135 maybe? 2.5 mins = 150seconds
devilfish
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
June 08, 2013, 09:37:50 PM
 #14

Thanks for the replies guys. I added the following and it seems to be catching up pretty quick now

-s 1 --expiry 25 --queue 0

I suppose the expiry needs to be little less than average block time (which is 30 seconds for infinitecoin and 2.5min for litecoin)

Yep, it's always going to depend on the particular situation at hand. New coins usually need 0 queue and a low expiry whilst more established ones can run fine with the default. Just like the --gpu-engine and --gpu-memclock all the options require a little love to get them running perfect. Glad you got it fixed

Thanks, what expiry should I set for litecoin ? 135 maybe? 2.5 mins = 150seconds

The default should be fine for something like that. For litecoin you would usually be in a pool anyway due to the difficulty meaning that it could be > 1 day to find a single block
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!