Your bets for 2014

[grondilu]

Plenty of data structures can look up individual transactions in O(log u) where u is the number of unspent transactions.

O(log u) - proof pls.

No need for proof, it's common knowledge.   Just look on the top right.

[notme]

Plenty of data structures can look up individual transactions in O(log u) where u is the number of unspent transactions.  Even using the lowest base of two, if there are u= 1 trillion unspent transactions, we are looking at about 40*16 lookups per second.  Even a spinning disk can easily hit 2000 seeks per second, and a SSD would handle that many reads trivially.  Only if we assume 1 trillion unspent transactions, a suboptimal data structure, 16 transactions a second and 3 inputs per transaction do we move to SSD as a necessity.  And that's assuming spinning drives don't improve in the decade minimum it takes to get to these levels.

Your move.

O(log u) - proof pls.

afaik, spinning drive has about 100 iops performance.

http://en.wikipedia.org/wiki/B-tree

And I'll give you the point on 100 iops for low end consumer drives.  IOPS is a better measure than seeks.  Good drives can get you close to 200 and SSDs can blow the 2000 I calculated around out of the water: http://en.wikipedia.org/wiki/IOPS#Examples

[notme]

Plenty of data structures can look up individual transactions in O(log u) where u is the number of unspent transactions.

O(log u) - proof pls.

No need for proof, it's common knowledge.   Just look on the top right.

Not the best example... Binary search trees are only average case log(n), worst case n.  Btrees are worst case log(n).

[lucif]

This is my 7200 seagate stats under running bitcoin. Regular disks have lower rates.

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda              50,67     0,00  122,00    2,00   690,67     6,67    11,25     1,02    8,27    8,09   19,17   7,47  92,60
sda              51,33     5,67  124,33   22,67   702,67   105,33    10,99     1,18    8,00    7,88    8,62   6,32  92,97
sda             100,33     2,67  123,33   29,33   894,67   113,33    13,21     1,14    7,48    8,05    5,10   6,10  93,17
sda              51,00     0,00  111,33   35,67   664,00   132,00    10,83     1,13    7,66    8,52    4,96   6,35  93,37

As you can see, its about 100 requests per second with almost busy heads.

And this is cached sequental read, when caches are available as not so much data in DB. And first column displays how many requests were merged.

[lucif]

Guys, cumon You are talking with highload architect and unix sysadmin

[notme]

This is my 7200 seagate stats under running bitcoin. Regular disks have lower rates.

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda              50,67     0,00  122,00    2,00   690,67     6,67    11,25     1,02    8,27    8,09   19,17   7,47  92,60
sda              51,33     5,67  124,33   22,67   702,67   105,33    10,99     1,18    8,00    7,88    8,62   6,32  92,97
sda             100,33     2,67  123,33   29,33   894,67   113,33    13,21     1,14    7,48    8,05    5,10   6,10  93,17
sda              51,00     0,00  111,33   35,67   664,00   132,00    10,83     1,13    7,66    8,52    4,96   6,35  93,37

As you can see, its about 100 requests per second with almost busy heads.

And this is cached sequental read, when caches are available as not so much data in DB. And first column displays how many requests were merged.

For the third time, quit using the old code.  We know it's shitty.  The new code is already available and barely touches the disk.

[notme]

Guys, cumon You are talking with highload architect and unix sysadmin

Who doesn't believe that optimal search is log(n)

[lucif]

I dont talk about the code - I show you HDD capabilities. Where are 2000 seeks?

[grondilu]

Guys, cumon You are talking with highload architect and unix sysadmin

Who doesn't believe that optimal search is log(n)

 

[notme]

I dont talk about the code - I show you HDD capabilities. Where are 2000 seeks?

Sorry, I read "stats under running bitcoin" and mistranslated your gibberish as stats with bitcoin running.  I already agreed that 100 IOPS was correct, I thought we were moving on.

[lucif]

So you staff going to announce that good highend SSD needed for using bitcoin? My 7200 is not the cheapest HDD.

[lucif]

Guys, cumon You are talking with highload architect and unix sysadmin

Who doesn't believe that optimal search is log(n)

Yeah. Haha. I dont too close familiar with BDB, but afaik MySQL uses BTREE in indexes also. I didnt noticed your log(n) formula works there.

[notme]

So you staff going to announce that good highend SSD needed for using bitcoin? My 7200 is not the cheapest HDD.

I have no staff.

[lucif]

Here is a guy with "Staff" near nickname talking to me.

[notme]

Here is a guy with "Staff" near nickname talking to me.

Oh grondilu... he just helps run the boards.  You should know bitcoin has no staff, and forum staff don't really have any more weight with the bitcoin community than anyone else.

But I imagine if SSD becomes necessary (it isn't even close now) that is what people will recommend.

[lucif]

But I imagine if SSD becomes necessary (it isn't even close now) that is what people will recommend.

That is what i said. Regular user will expirence difficulties, including HW incompatibility to run bitcoin. At least vanilla bitcoin.

All other - empty bubble talk.

[notme]

But I imagine if SSD becomes necessary (it isn't even close now) that is what people will recommend.

That is what i said. Regular user will expirence difficulties, including HW incompatibility to run bitcoin. At least vanilla bitcoin.

All other - empty bubble talk.

Right, once we reach the 1 trillion unspent transactions in a decade or 3.  And all advances in storage technology will stop from today forward.

[lucif]

Right, once we reach the 1 trillion unspent transactions in a decade or 3.  And all advances in storage technology will stop from today forward.

Looks you are completely theoretical, while I'm practical.

With your optimism paypal can run their processing on raspberry PI 

1 trillion? And PC will survive? LOL.

[notme]

Right, once we reach the 1 trillion unspent transactions in a decade or 3.  And all advances in storage technology will stop from today forward.

Looks you are completely theoretical, while I'm practical.

With your optimism paypal can run their processing on raspberry PI  

1 trillion? And PC will survive? LOL.

No, you're being theoretical too.  There is currently no problem, and you are imagining usage levels that will take decades to arrive.  I'm being much more practical than you about adoption rate, yet somehow I'm more bullish .

[lucif]

Allright   You laugh me a lot here.

I saw databases above 4G with good btree indexes (on integer field!) and know what is it for single SATA HDD.

I'll check your 0.8 version