Title: Slow update of bitcoind or bitcoin-qt 0.8.1, a possible solution Post by: old c coder on May 11, 2013, 06:41:46 PM Hello all
This discussion is only on windows PCs, as that is all I have here, XPs and windows7. When I first installed bitcoind.exe and bitcoin-qt.exe in March of this year (2013) I too had a slow update of the block chain. But it did update after a day or so. I was "watching" bitcoind.exe update, using -printtoconsole and it seemed to take a "long time" to connect and disconnected frequently, never able to "catch up", especially if was "mining" too! It was always about 3 blocks "behind". I was comparing the block count in real time to http://blockexplorer.com/ and http://blockchain.info/ I have read various comments in the Development & Technical Discussion area, and none seemed to offer anything definitive, and some information contradicted other information, even the new 0.8.2 version. So I looked at the code (of 0.8.1) and just recompiled after changing the manifest constant MAX_OUTBOUND_CONNECTIONS from 8 to 16, just as a test. It is about line 28 in net.cpp I am able to compile bitcoind.exe on windows, thanks to nitrogenetics, see https://bitcointalk.org/index.php?topic=149479.msg1587734#msg1587734 Lo and behold, bitcoind behaved much more nicely, even when not mining, and the block chain updates fast! Sometimes I see a block a second or two before I see it on http://blockchain.info/ Now using one machine to just keep the block chain up to date, as it were, I connect other windows machines using the -connect=192.168.0.x etc. as a command line argument or in bitcoin.conf, directing their attention on my LAN to that machine only. Whether I use a bitcoind or a bitcoin-qt they update a block every second or so, no matter how many days behind they are! So one day of about 144 blocks will update in a couple of minutes. Also the cpu load of bitcoind that is only getting block info is very low. And the other machines then don't "bother" the bitcoin network community so there is less superfluous requests. I tried to offer this information, and other ideas, but us "noobs" can only watch, we can't contribute until...? Ron If this is of any help, small fragments may be donated to my profile btc $, 1DPvP6WoZzaNQ9Nxzd64hjYad1kyQzTTbx, thereby rounding up your wallet ;) Title: Re: Slow update of bitcoind or bitcoin-qt 0.8.1, a possible solution Post by: Raoul Duke on May 11, 2013, 06:53:05 PM You could just turn uPnP on and have 125 connections or more, if you raised the limit in the bitcoin.conf file.
If uPnP doesn't work you can always forward the right port on your router and have the same effect. Any of the 2 solutions above sure beats the crap out of having to compile Bitcoin-Qt from scratch. ;D Title: Re: Slow update of bitcoind or bitcoin-qt 0.8.1, a possible solution Post by: old c coder on May 11, 2013, 10:00:18 PM Hello
On Windows it is/was a known fact that upnp is a security risk that is not worth taking and is off on my windows (virtual) firewall. See https://www.grc.com/unpnp/unpnp.htm http://www.sans.org/security-resources/malwarefaq/win_upnp.php etc. Which port is the "right one" to forward, 8332, 8333? What if I want to use more than one machine? I am assuming I can only forward to one "internal" IP $? Ron Title: Re: Slow update of bitcoind or bitcoin-qt 0.8.1, a possible solution Post by: Raoul Duke on May 11, 2013, 10:04:04 PM Hello On Windows it is/was a known fact that upnp is a security risk that is not worth taking and is off on my windows (virtual) firewall. See https://www.grc.com/unpnp/unpnp.htm http://www.sans.org/security-resources/malwarefaq/win_upnp.php etc. Which port is the "right one" to forward, 8332, 8333? What if I want to use more than one machine? I am assuming I can only forward to one "internal" IP $? Ron You can change the port in bitcoin.conf, if you have more than 1 bitcoin client that needs port forwarding. Title: Re: Slow update of bitcoind or bitcoin-qt 0.8.1, a possible solution Post by: old c coder on May 12, 2013, 01:34:16 AM Hello Gweedo
I think you "under-read" this so much! I never said I forwarded any port, and still haven't. I only was answering the notion that one could use uPnp or port forwarding to "up the throughput". On another point. As to recompiling, I should think that with today's and even yesterday's compiler-linkers, one basically only has to relink as it were, after only recompiling those files that depend upon the one change made. And those files are only the ones that the declarations and header files claim. But that is another issue... Ron |