Weird Solo Mining Problem

[daserpent1]

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]

Get a better Internet connection.

[devilfish]

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]

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.

[daserpent1]

I have 1.3Mh/s .. should i try the expiry command?

[devilfish]

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]

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.

[devilfish]

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]

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 

[daserpent1]

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]

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 

My mistake then, I guess I didn't read right.

[devilfish]

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]

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]

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