Bitcoin Forum
December 02, 2016, 08:25:09 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 [7] 8 9 10 »  All
  Print  
Author Topic: .  (Read 34918 times)
Dabs
Staff
Legendary
*
Online Online

Activity: 1512


64blocks.com


View Profile WWW
March 12, 2013, 01:18:50 AM
 #121

I'm tempted to buy a machine with 32 Gigs of RAM. ... ... Maybe those so called "ram drives" (hardware implemented) might be useful.

@Sukrim, I can probably sync the blockchain with another computer that already has it within the network, or just copy the files over. That will save download time.

64blocks.com Social Multiplayer Dice (Gambling) - Escrow Service (Services) - GPG ID: 32AD7565, OTC ID: Dabs
All messages concerning escrow or with bitcoin addresses are GPG signed. Please verify.
CompTIA A+, Microsoft Certified Professional
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480710309
Hero Member
*
Offline Offline

Posts: 1480710309

View Profile Personal Message (Offline)

Ignore
1480710309
Reply with quote  #2

1480710309
Report to moderator
1480710309
Hero Member
*
Offline Offline

Posts: 1480710309

View Profile Personal Message (Offline)

Ignore
1480710309
Reply with quote  #2

1480710309
Report to moderator
mrb
Legendary
*
Offline Offline

Activity: 1106


View Profile WWW
March 12, 2013, 01:23:37 AM
 #122

I'm tempted to buy a machine with 32 Gigs of RAM. ... ... Maybe those so called "ram drives" (hardware implemented) might be useful.

Do it, 32GB only costs $160, assuming you already have a machine with a motherboard supporting 4 x 8GB DDR3.
But don't buy hardware ram drives. They are all horribly overpriced, as in 10x more expensive per GB, or more.
Dabs
Staff
Legendary
*
Online Online

Activity: 1512


64blocks.com


View Profile WWW
March 12, 2013, 01:51:13 AM
 #123

The hardware ram drives I know use old DDR2 memory. Maybe there are new ones that are horribly overpriced. Or I'll look around to see if someone has made one. The one I know used to use a SATA cable to emulate a hard drive. Real ram inside the motherboard is obviously going to work a lot faster.

64blocks.com Social Multiplayer Dice (Gambling) - Escrow Service (Services) - GPG ID: 32AD7565, OTC ID: Dabs
All messages concerning escrow or with bitcoin addresses are GPG signed. Please verify.
CompTIA A+, Microsoft Certified Professional
2112
Legendary
*
Offline Offline

Activity: 1708



View Profile
March 12, 2013, 02:10:26 AM
 #124

But don't buy hardware ram drives. They are all horribly overpriced, as in 10x more expensive per GB, or more.
Please pardon me for jumping in, but please post the links to those overpriced hardware RAM drives. My friends in IT operations are on the market and have hard time sourcing devices that don't wear out are reasonably non-volatile and can survice reboot/reconfig/reload of the OS.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
mrb
Legendary
*
Offline Offline

Activity: 1106


View Profile WWW
March 12, 2013, 09:29:11 AM
 #125

But don't buy hardware ram drives. They are all horribly overpriced, as in 10x more expensive per GB, or more.
Please pardon me for jumping in, but please post the links to those overpriced hardware RAM drives. My friends in IT operations are on the market and have hard time sourcing devices that don't wear out are reasonably non-volatile and can survice reboot/reconfig/reload of the OS.

http://www.ddrdrive.com - it was designed for ZFS ZIL, and the RAM is backed by SLC NAND flash. It was priced $2000 when it launched ~3 years ago. The price has probably gone down a lot, but it is still way more than 10x the price per GB than system's RAM.

Part of the reason prices are so high is because there are so few vendors, so there is practically no competition.
2112
Legendary
*
Offline Offline

Activity: 1708



View Profile
March 12, 2013, 10:25:34 AM
 #126

http://www.ddrdrive.com - it was designed for ZFS ZIL, and the RAM is backed by SLC NAND flash. It was priced $2000 when it launched ~3 years ago. The price has probably gone down a lot, but it is still way more than 10x the price per GB than system's RAM.

Part of the reason prices are so high is because there are so few vendors, so there is practically no competition.
Thanks. Unfortunately this is still a flash drive with RAM cache and still susceptible to write amplification abuse. Thus far we haven't found anything better than discontinued ACARD ANS-9010 (64GB with battery backup) and some other custom-made solutions.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
onelineproof
Jr. Member
*
Offline Offline

Activity: 50


View Profile WWW
March 18, 2013, 08:01:28 AM
 #127

This is nice. One feature I would like to see is the creation of a table that stores public key to balance pairs, and keeps updating from time to time. This way you can quickly look up the balance of an address. If I have time, I may use this code to do this, and I'll add it to my wallet parser: https://github.com/piratelinux/cwallet

Pirate Linux developer: https://piratelinux.org
Cwallet developer: https://github.com/piratelinux/cwallet
Donate: 1proofgtqF9JJ26ZCYatkvWfpJE8bDYxa
phelix
Legendary
*
Offline Offline

Activity: 1680


nmc:id/phelix


View Profile
March 19, 2013, 08:25:53 AM
 #128

Would it be possible to dig out what percentage of coins have ever been moved for any 2016 block period?

I would be interested in how many of the early coins have never been moved.

edit: ok, just found your post: https://bitcointalk.org/index.php?topic=98641.0  [2 Million unspent...]

blockchained.com ■ bitcointalk top posts
phathash
Member
**
Offline Offline

Activity: 75


View Profile
March 24, 2013, 10:23:22 AM
 #129

I know this is developed under Ubuntu, but it would be nice to have working on RH type distros.

I have openssl with ecdsa working, but blockparser won't compile -

Quote
# make
c++ -- cb/dumpTX.cpp
cb/dumpTX.cpp: In member function 'virtual int DumpTX::init(int, const char**)':
cb/dumpTX.cpp:80: error: expected initializer before ':' token
cb/dumpTX.cpp:84: error: expected primary-expression before 'return'
cb/dumpTX.cpp:84: error: expected ';' before 'return'
cb/dumpTX.cpp:84: error: expected primary-expression before 'return'
cb/dumpTX.cpp:84: error: expected ')' before 'return'
make: *** [.objs/dumpTX.o] Error 1

Is this something worth pursuing further?
phathash
Member
**
Offline Offline

Activity: 75


View Profile
March 27, 2013, 12:10:57 PM
 #130

Thanks. gcc now at  4.6.3.

However, now receive -

Quote
# make
lnk -- parser
.objs/util.o: In function `decompressPublicKey(unsigned char*, unsigned char const*)':
util.cpp:(.text+0x804): undefined reference to `EC_KEY_new_by_curve_name'
util.cpp:(.text+0x820): undefined reference to `o2i_ECPublicKey'
util.cpp:(.text+0x834): undefined reference to `EC_KEY_set_conv_form'
util.cpp:(.text+0x843): undefined reference to `i2o_ECPublicKey'
util.cpp:(.text+0x84f): undefined reference to `EC_KEY_free'
util.cpp:(.text+0x896): undefined reference to `EC_KEY_free'
.objs/util.o: In function `compressPublicKey(unsigned char*, unsigned char const*)':
util.cpp:(.text+0x8b4): undefined reference to `EC_KEY_new_by_curve_name'
util.cpp:(.text+0x8d0): undefined reference to `o2i_ECPublicKey'
util.cpp:(.text+0x8e4): undefined reference to `EC_KEY_set_conv_form'
util.cpp:(.text+0x8f3): undefined reference to `i2o_ECPublicKey'
util.cpp:(.text+0x8ff): undefined reference to `EC_KEY_free'
util.cpp:(.text+0x946): undefined reference to `EC_KEY_free'
collect2: ld returned 1 exit status
make: *** [parser] Error 1

I believe I do have openssl compiled correctly with ECDSA.

Is this worth pursuing?

willphase
Hero Member
*****
Offline Offline

Activity: 770


View Profile
April 03, 2013, 12:42:16 AM
 #131

blockchain.info satoshidice profit/loss seems to be a bit flaky at the moment - so right now to work out my profit/loss I'm exporting my transactions then pulling tx info from blockchain.info for each of my transactions and working out if it contains a 1dice* address then assuming that's a bet and adding/removing from the total.

it would be nice to do this using your tool - so supplied with a list of all my addresses, parse blockchain for tx with either { my address } -> { 1dice* } or { 1dice* } -> { my address }

Is this possible?

Will

willphase
Hero Member
*****
Offline Offline

Activity: 770


View Profile
April 03, 2013, 07:55:07 AM
 #132

You can try this:

[snip]

ought to  give you what you want.

Sounds good - I'll give that a go.

Cheers

Will

r.willis
Jr. Member
*
Offline Offline

Activity: 42


View Profile
April 03, 2013, 08:23:31 AM
 #133

2112, your friends' best bet is http://www.ramsan.com/products/rackmount-ram-storage-line
But price can be quite high.

1GVmS56pvVL7YZA7YqMBXmaDedCoputKuJ BitEN - Bitcoin Erlang Node
2112
Legendary
*
Offline Offline

Activity: 1708



View Profile
April 03, 2013, 05:54:58 PM
 #134

2112, your friends' best bet is http://www.ramsan.com/products/rackmount-ram-storage-line
But price can be quite high.
Thank you very much. Those are primarily aimed at the "IOPS desperation" market niche. We aren't there yet. I would call our niche "rapid reboot & real reliability" for write-ahead-logging internal drive. The flash EEPROM storage is so full of misinformation about reliability that its is nearly impossible to make sensible product choices.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
r.willis
Jr. Member
*
Offline Offline

Activity: 42


View Profile
April 03, 2013, 06:48:42 PM
 #135

If reliability is main concern, you can use RAID1 (preferably staggered in such a way that two disk in each array have different wear level). Also, larger disks will last longer before wearing.

1GVmS56pvVL7YZA7YqMBXmaDedCoputKuJ BitEN - Bitcoin Erlang Node
2112
Legendary
*
Offline Offline

Activity: 1708



View Profile
April 03, 2013, 09:04:51 PM
 #136

If reliability is main concern, you can use RAID1 (preferably staggered in such a way that two disk in each array have different wear level). Also, larger disks will last longer before wearing.
I wish the life would be so simple. The flash storage sector is so full of cheats and fly-by-nights, that the total cost of building a reliable and long lasting Unix server simply approaches or exceeds the cost of an equivalent mainframe solution. C.f. the recent trend of using supercapacitors to power hidden write-back caches. Combined with the various wear-leveling cheats it produces failures that are extremely hard to locate. Consider this trivialized example of a circular on-disk-buffer of 3 blocks:

1 2 3
4 5 6
7 8 9

If you read it after simple reboot you'll get "7 8 9". If you read it after proper power down with super-cap discharge, you'll get "7 5 9" or "7 2 9" or various other combinations. The culprit really isn't flash technology, it is nearly always firmware problem due to its extreme complexity and trivialized testing.

There are various options available on the market, but they aren't openly advertised because they tend to use some technologies that IBM has either patented or keeps a tight contractual grip on the channel partners. e.g. SCSI disk drives with AS/400-like formatting with 520 bytes per block for 512 bytes of user data per block.

On the other hand we've never suffered a bug in a true RAM drive, possibly because of the extreme simplicity of the required firmware.

I apologise for contributing to a derailment of this thread.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
mrb
Legendary
*
Offline Offline

Activity: 1106


View Profile WWW
April 05, 2013, 01:02:57 AM
 #137

If reliability is main concern, you can use RAID1 (preferably staggered in such a way that two disk in each array have different wear level). Also, larger disks will last longer before wearing.
I wish the life would be so simple. The flash storage sector is so full of cheats and fly-by-nights, that the total cost of building a reliable and long lasting Unix server simply approaches or exceeds the cost of an equivalent mainframe solution.

Self-healing (ZFS) can make unreliable flash storage reliable.
MeatPopsicle
Jr. Member
*
Offline Offline

Activity: 48


View Profile
April 05, 2013, 11:01:43 PM
 #138

Compiles fine but then segafaults.

There's logic issues with the mmap'ing.
MeatPopsicle
Jr. Member
*
Offline Offline

Activity: 48


View Profile
April 06, 2013, 03:18:10 AM
 #139

ext3, and pretty sure it's crashing from a null ptr. Always dies once you try to operate on the last element in vecMap.
MeatPopsicle
Jr. Member
*
Offline Offline

Activity: 48


View Profile
April 07, 2013, 12:33:46 AM
 #140

When I didn't have any blockchain files it would crash on unmapping somewhere in cleanMaps, but with blockchain data it dies on:

Code:
while(i!=e) totalSize += (i++)->size;

in initHashtables.

Code:
ovrlrdq@thedarkcitadel:/tmp/blockparser$ ./parser stats

info: starting command "simpleStats"
Segmentation fault (core dumped)
ovrlrdq@thedarkcitadel:/tmp/blockparser$ gdb parser core
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /tmp/blockparser/parser...done.
[New LWP 20039]

warning: Can't read pathname for load map: Input/output error.

warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fffb238a000
Core was generated by `./parser stats'.
Program terminated with signal 11, Segmentation fault.
#0  0x000000000044f2d3 in google::dense_hashtable<std::pair<unsigned char const* const, unsigned char const*>, unsigned char const*, Hash256Hasher, google::dense_hash_map<unsigned char const*, unsigned char const*, Hash256Hasher, Hash256Equal, google::libc_allocator_with_realloc<std::pair<unsigned char const* const, unsigned char const*> > >::SelectKey, google::dense_hash_map<unsigned char const*, unsigned char const*, Hash256Hasher, Hash256Equal, google::libc_allocator_with_realloc<std::pair<unsigned char const* const, unsigned char const*> > >::SetKey, Hash256Equal, google::libc_allocator_with_realloc<std::pair<unsigned char const* const, unsigned char const*> > >::dense_hashtable(google::dense_hashtable<std::pair<unsigned char const* const, unsigned char const*>, unsigned char const*, Hash256Hasher, google::dense_hash_map<unsigned char const*, unsigned char const*, Hash256Hasher, Hash256Equal, google::libc_allocator_with_realloc<std::pair<unsigned char const* const, unsigned char const*> > >::SelectKey, google::dense_hash_map<unsigned char const*, unsigned char const*, Hash256Hasher, Hash256Equal, google::libc_allocator_with_realloc<std::pair<unsigned char const* const, unsigned char const*> > >::SetKey, Hash256Equal, google::libc_allocator_with_realloc<std::pair<unsigned char const* const, unsigned char const*> > > const&, unsigned long) ()
(gdb) bt
#0  0x000000000044f2d3 in google::dense_hashtable<std::pair<unsigned char const* const, unsigned char const*>, unsigned char const*, Hash256Hasher, google::dense_hash_map<unsigned char const*, unsigned char const*, Hash256Hasher, Hash256Equal, google::libc_allocator_with_realloc<std::pair<unsigned char const* const, unsigned char const*> > >::SelectKey, google::dense_hash_map<unsigned char const*, unsigned char const*, Hash256Hasher, Hash256Equal, google::libc_allocator_with_realloc<std::pair<unsigned char const* const, unsigned char const*> > >::SetKey, Hash256Equal, google::libc_allocator_with_realloc<std::pair<unsigned char const* const, unsigned char const*> > >::dense_hashtable(google::dense_hashtable<std::pair<unsigned char const* const, unsigned char const*>, unsigned char const*, Hash256Hasher, google::dense_hash_map<unsigned char const*, unsigned char const*, Hash256Hasher, Hash256Equal, google::libc_allocator_with_realloc<std::pair<unsigned char const* const, unsigned char const*> > >::SelectKey, google::dense_hash_map<unsigned char const*, unsigned char const*, Hash256Hasher, Hash256Equal, google::libc_allocator_with_realloc<std::pair<unsigned char const* const, unsigned char const*> > >::SetKey, Hash256Equal, google::libc_allocator_with_realloc<std::pair<unsigned char const* const, unsigned char const*> > > const&, unsigned long) ()
#1  0x000000000044b8fc in initHashtables() ()
#2  0x0000000000404c4c in main ()


Valgrind output:

Code:
info: starting command "simpleStats"
==22223== Invalid write of size 8
==22223==    at 0x44EA23: google::dense_hashtable<std::pair<unsigned char const* const, unsigned char const*>, unsigned char const*, Hash256Hasher, google::dense_ha
sh_map<unsigned char const*, unsigned char const*, Hash256Hasher, Hash256Equal, google::libc_allocator_with_realloc<std::pair<unsigned char const* const, unsigned c
har const*> > >::SelectKey, google::dense_hash_map<unsigned char const*, unsigned char const*, Hash256Hasher, Hash256Equal, google::libc_allocator_with_realloc<std:
:pair<unsigned char const* const, unsigned char const*> > >::SetKey, Hash256Equal, google::libc_allocator_with_realloc<std::pair<unsigned char const* const, unsigne
d char const*> > >::dense_hashtable(google::dense_hashtable<std::pair<unsigned char const* const, unsigned char const*>, unsigned char const*, Hash256Hasher, google
::dense_hash_map<unsigned char const*, unsigned char const*, Hash256Hasher, Hash256Equal, google::libc_allocator_with_realloc<std::pair<unsigned char const* const,
unsigned char const*> > >::SelectKey, google::dense_hash_map<unsigned char const*, unsigned char const*, Hash256Hasher, Hash256Equal, google::libc_allocator_with_re
alloc<std::pair<unsigned char const* const, unsigned char const*> > >::SetKey, Hash256Equal, google::libc_allocator_with_realloc<std::pair<unsigned char const* cons
t, unsigned char const*> > > const&, unsigned long) (in /tmp/blockparser/parser)
==22223==    by 0x44B76D: initHashtables() (in /tmp/blockparser/parser)
==22223==    by 0x404C4B: main (in /tmp/blockparser/parser)
==22223==  Address 0x10 is not stack'd, malloc'd or (recently) free'd
==22223==
==22223==
==22223== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==22223==  Access not within mapped region at address 0x10
==22223==    at 0x44EA23: google::dense_hashtable<std::pair<unsigned char const* const, unsigned char const*>, unsigned char const*, Hash256Hasher, google::dense_ha
sh_map<unsigned char const*, unsigned char const*, Hash256Hasher, Hash256Equal, google::libc_allocator_with_realloc<std::pair<unsigned char const* const, unsigned c
har const*> > >::SelectKey, google::dense_hash_map<unsigned char const*, unsigned char const*, Hash256Hasher, Hash256Equal, google::libc_allocator_with_realloc<std:
:pair<unsigned char const* const, unsigned char const*> > >::SetKey, Hash256Equal, google::libc_allocator_with_realloc<std::pair<unsigned char const* const, unsigne
d char const*> > >::dense_hashtable(google::dense_hashtable<std::pair<unsigned char const* const, unsigned char const*>, unsigned char const*, Hash256Hasher, google
::dense_hash_map<unsigned char const*, unsigned char const*, Hash256Hasher, Hash256Equal, google::libc_allocator_with_realloc<std::pair<unsigned char const* const,
unsigned char const*> > >::SelectKey, google::dense_hash_map<unsigned char const*, unsigned char const*, Hash256Hasher, Hash256Equal, google::libc_allocator_with_re
alloc<std::pair<unsigned char const* const, unsigned char const*> > >::SetKey, Hash256Equal, google::libc_allocator_with_realloc<std::pair<unsigned char const* cons
t, unsigned char const*> > > const&, unsigned long) (in /tmp/blockparser/parser)
==22223==    by 0x44B76D: initHashtables() (in /tmp/blockparser/parser)
==22223==    by 0x404C4B: main (in /tmp/blockparser/parser)
Pages: « 1 2 3 4 5 6 [7] 8 9 10 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!