|
Make sure your computer's date and time are correct.
|
|
|
|
Any non-Mac i5 love?
Windows i5 64-bit got slower here.
That's the first I've heard anyone say i5 was slower. Everyone else has said 4way was faster on i5. Moreso with hyperthreading enabled. And i5, at least on my macbookpro
Good, so I take it that's a confirmation that it's working on Mac as well? Laszlo told me he did compile in the -4way stuff on Mac, so the -4way switch is also available to try on Mac. I don't think makefile.osx on SVN has it yet, just the built version. |
|
|
|
|
That's a really well written walkthough. Someone should confirm if they followed it and didn't run into any snags.
|
|
|
|
WxWidgets is not really a problem. My problem is the version that is used (2.9), which is considered unstable by many distro packagers (although the WxWidgets devs say it isn't). On the other side, as far as I know WxWidgets uses gtk under Linux for drawing the whole stuff and makes it for the bitcoins devs easy to make things cross platform.
wxWidgets 2.9 is their first UTF-8 version. We are UTF-8 on all platforms including Windows. The distro packages of 2.8 are UTF-16, so they just trip people up. People had endless build problems with 2.8 and its wxString UTF-16/ANSI conditional build options until we standardized on 2.9. Also, to use 2.8, we were using ANSI, which was just a temporary stopgap until wxWidgets supported UTF-8. This is a problem that will solve itself. With time, 2.9 will become a more mainline release. |
|
|
|
|
In the next SVN rev, I'll make it only go back to the last checkpoint at block 74000. If we need to correct a problem in the future, we can always make sure it goes back at least as far back as the problem. Also, I'm adding code to verify the block index, which means the proof-of-work chain is checked.
Still, the system won't be entirely secure against your blk*.dat files. You are trusting someone if you use a copy of their blk files.
|
|
|
|
|
The performance numbers posted from a VIA C7's hardware SHA-256 weren't astronomical. Only in the 1500 khash/s range. If you think about it, just because it's implemented in hardware doesn't mean it's crazy fast. It still has to do all the steps. It's only if simplifying it down to single-purpose hardware makes it small enough to fit many in parallel. That's not necessarily easy or a given.
|
|
|
|
|
Definitely. The old screenshots of 0.1 are very outdated.
Windows Aero is a good choice. Windows is still the largest user group. Mind what's behind it for the transparent parts.
What to have displayed in the transaction list? Not completely filled up with stuff, just a few things.
|
|
|
|
How is the strength of the chain calculated?
Total proof-of-work. |
|
|
|
|
Un-upgraded nodes have the correct chain most of the time, but they are still trying to include the overflow transaction in every block, so they're continually trying to fork and generate invalid blocks. If an old version node is restarted, its transaction pool is emptied, so it may generate valid blocks for a while until the transaction gets broadcast again. 0.3.9 and lower nodes still must upgrade.
The SVN now has the code we needed to automatically reorg the block chain without having to delete the blk*.dat files manually. I knew I couldn't write that code fast and carefully enough yesterday, so I went with the quick manual option.
|
|
|
|
|
There is no way for the software to automatically know if one chain is better than another except by the greatest proof-of-work. In the design it was necessary for it to switch to a longer chain no matter how far back it has to go.
The only exception to that is the manual checkpoints I've added. If it weren't for those, it would be able to reorg all the way back to the first block.
|
|
|
|
|
SVN rev 139 does a basic check of the block chain after loading.
With this we wouldn't have needed to delete blk*.dat, it would have automatically done a reorg back to the fork. There wasn't time to do a careful implementation of this at the time.
It might take longer than we want, since it has to load all the blocks. If it's too slow, we could have it only go back to a certain block number.
|
|
|
|
It would probably be possible to initiate an AddToBlockIndex or Reorganize after the check, but it would require a lot more careful attention. I probably should break out part of AddToBlockIndex that sets the new best block. I'll probably end up doing that instead of the code below.
This is what I ended up doing in SVN rev 139. Instead of deleting the bad chain, I added an extra CheckBlock to ConnectBlock so bad blocks can't get back into the best chain once they're kicked out. |
|
|
|
I'd like to reduce the number of blocks displayed in the status bar by 1. When you first load the program, it'll display 0 blocks instead of 1: "0 connections 0 blocks 0 transactions" It's always been "nBestHeight + 1" because it's counting the genesis block. Technically, yes, the genesis block is a block. It's a hardcoded block that you start out with. You can't not have the genesis block. Maybe think of it as a reference coin that you measure other coins against. The block count people are looking for is the number of blocks they've downloaded. The main benefit is that blocks will be equal to the block number of the current best block. If blocks is 10, then the highest block number you have is 10. It means you have block 10 and you don't have block 11. It would reduce the confusion we had here: ... It already is on block 74638. I assume that means that block is now a good one?
I had some confusion on this myself and got clarification in #bitcoin-dev: The bad block was number 74638, the last good one was 74637. The numbers start at 0, so when your client shows there are 74638 blocks then that means you have up to block number 74637, the last good one. |
|
|
|
That's a difficult approach. We need to cause a reorg, which will disconnect the invalid chain. This is code that will rarely ever get tested, and is fairly intricate, so something simple and safe is best. Here's what I was thinking of. (I haven't tested this yet) It checks all the blocks in the main chain. If it finds a bad one, it sets all that chain's bnChainWork to 0 so it can't win best chain again, and it reduces best chain work to the fork level so any new block after the fork will cause a reorg. (It can't change pindexBest without actually doing a reorg) This isn't perfect yet. It still needs to receive one valid block to trigger the reorg. It would probably be possible to initiate an AddToBlockIndex or Reorganize after the check, but it would require a lot more careful attention. I probably should break out part of AddToBlockIndex that sets the new best block. I'll probably end up doing that instead of the code below. bool CTxDB::LoadBlockIndex()
{
...
// Verify blocks in the main chain
vector<CBlockIndex*> vChain;
for (CBlockIndex* pindex = pindexBest; pindex && pindex->pprev; pindex = pindex->pprev)
{
vChain.push_back(pindex);
CBlock block;
if (!block.ReadFromDisk(pindex))
return error("LoadBlockIndex() : block.ReadFromDisk failed");
if (!block.CheckBlock())
{
bnBestChainWork = pindex->pprev->bnChainWork;
foreach(CBlockIndex* pindex2, vChain)
pindex2->bnChainWork = 0;
}
}
return true;
}
|
|
|
|
|
I wrapped sha256.cpp in
#ifdef FOURWAYSSE2
#endif // FOURWAYSSE2
try it now.
|
|
|
|
|
It looks like we overtook the bad chain somewhere around 74689. 0.3.9 and lower nodes have been responding with the current block number for some hours now.
That means it's no longer necessary to delete blk*.dat before upgrading. You can just upgrade and it'll reorg away the bad block chain.
Thanks to everyone for the quick response!
|
|
|
|
cpu family : 6
model : 26
model name : Genuine Intel(R) CPU 000 @ 3.20GHz
stepping : 4 cpu family 6 model 26 stepping 4 is an Intel Core i7. That's a 23% speedup with -4way, 63% total speedup with -4way + hyperthreading. 33% faster with hyperthreading than without it. |
|
|
|
try -march=amdfam10
That works. That's strange... are we sure that's the same thing? tcatm, try amdfam10 and make sure you get the same speed measurement. |
|
|
|
I propose to compile sha256.cpp with -O3 -march=amdfamk10 (will work on 32bit and 64bit) as only CPUs supporting this instruction set (AMD Phenom, Intel i5 and newer) benefit from -4way and it'll improve performance by ~9%.
GCC 4.3.3 doesn't support -march=amdfamk10. I get: sha256.cpp:1: error: bad value (amdfamk10) for -march= switch With 4way, I get significantly better performance when I have all my virtual cores enabled. I think I get about the same amount of hashes when hyper threading is turned off with or without 4way.
Hey, you may be onto something! hyperthreading didn't help before because all the work was in the arithmetic and logic units, which the hyperthreads share. tcatm's SSE2 code must be a mix of normal x86 instructions and SSE2 instructions, so while one is doing x86 code, the other can do SSE2. How much of an improvement do you get with hyperthreading? Some numbers? What CPU is that? |
|
|
|
|
Show Posts
