1

I use Geth 1.7.3 in Azure Ubuntu VM to test run mining.

First I sync with main network using:

geth --fast --cache=2048

After I run for 24 hours, the progress is still 4476201 / 4973527 (around 90% sync). Then I stop the sync and change to sync light mode:

geth --syncmode "light" --cache=2048

The sync completed in few minutes. Then, I start mining by:

geth --mine --minerthreads=8

The mining starts, but very soon, it displays the following messages:

INFO [01-26|02:45:44] Commit new mining work                   number=1       txs=0 uncles=0 elapsed=57.163ms
INFO [01-26|02:45:58] Upgrading chain index                    type=bloombits percentage=99
INFO [01-26|02:46:08] Finished upgrading chain index           type=bloombits
INFO [01-26|02:46:34] Block synchronisation started
INFO [01-26|02:46:34] Mining aborted due to sync
INFO [01-26|02:46:46] Imported new block headers               count=0 elapsed=10.641ms number=4457698 hash=8e53f3…0ffac5 ignored=192

Seems that the sync is incomplete, and sync starts at block 4457698 (I thought I have completed syncing already). I cross-verify with the eth.syncing command in geth console:

{
  currentBlock: 4478249,
  highestBlock: 4973527,
  knownStates: 264144,
  pulledStates: 261773,
  startingBlock: 4457506
}

So, do I need to sync all over again? Since I'm not specifying sync mode in the mining command, does the Sync mode run in full mode now? How to check which mode the syncing is using?

Thanks in advance.

|improve this question|||||
  • As far as I know, you cannot change syncmode "like that". Fast gets all headers until a few blocks before the head, and then download the states. But light only has the headers, not the states, so you are not supposed to do anything with ligth mode. – Florian Castelain Jan 26 '18 at 3:15
  • So, what's the light mode for? It's fast, but it has no practical use at all? – Raptor Jan 26 '18 at 3:40
  • 1
    ethereum.stackexchange.com/a/11300/20808 – Florian Castelain Jan 26 '18 at 3:42
1

You will need to delete your chaindata folder and start again. If you start a sync in fast mode, you must sync in fast mode until it stops syncing. The last time I did a mainnet fast node sync, fast sync stops on its own and will continue a normal syncing process.

If you start a fast mode sync do not interrupt its sync process to switch syncmodes.

|improve this answer|||||
  • really I have to start over again? Seems it's syncing in fast mode normally now. – Raptor Jan 26 '18 at 3:40
  • 1
    Generally yes it is much quicker to start over (this is actually an extremely common recommendation, just do google searches for geth and sync modes and you'll find similar recommendations. I'm able to download the entire mainnet chain with a fresh fast sync in under 12 hours. I've tried resyncing after interrupting a fast sync and it's taken up to 3 days before. Also there's a security risk for syncing in fast mode, stopping a fast mode sync to sync normally or via lightmode, and then resuming your fast sync. – hextet Jan 26 '18 at 5:54
  • Thanks for the recommendation. Maybe the network is not fast enough, as the fast sync took at least 3 days to complete. – Raptor Jan 26 '18 at 7:07
  • What kind of bandwidth are you running with? You using an SSD or HDD? SSD's SIGNIFICANTLY increase performance. I also run with a cache of 16GB. – hextet Jan 26 '18 at 8:54
  • I'm using 64GB SSD (with 2GB swap memory), 7GB RAM, 2 vCPU in Windows Azure D2S V2. Maybe I should add more RAM to my VM. – Raptor Jan 26 '18 at 9:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.