The Crash Continues! 
Oh no! The price is...exactly where it's been most of the day? Whaaaaaaaaaaaaaaaaaaaaaaaaaa?
Topic: Wall Observer - MtGoxUSD wall movement tracker - page 544. (Read 1811613 times)
Oh no! The price is...exactly where it's been most of the day? Whaaaaaaaaaaaaaaaaaaaaaaaaaa?
The Crash Continues!
Oh no! The price is...exactly where it's been most of the day? Whaaaaaaaaaaaaaaaaaaaaaaaaaa?
The Crash Continues!
Adam, are you trying to uncrash it? Because it's working...
Please do not panic
The bitcoin economy is still very much alive, we do not
think price will go down by very much. We suggest you
hold on to your coins and wait out the
we are currently experiencing. We strongly believe their
is no cause for concern at this time.
thank you.
good night, I sold
lol!
this thread is best viewed with 1680X1050 resolution
buy one they are cheep like dirt!
http://bitcoinstore.com/information-technology/computer-displays.html?dir=asc&order=price
There is something weird about looking a prices of things that you know the value of in dollars to then see the bitcoin value. I think I feel disconnected about the value of the numbers I trade back and fourth.this thread is best viewed with 1680X1050 resolution
buy one they are cheep like dirt!
http://bitcoinstore.com/information-technology/computer-displays.html?dir=asc&order=price
Kind of reminds me of the cliché stories your grandparents say how they could feed the whole family on a nickel back in the day. It is going to be the opposite now with bitcoin, "you whipper snappers have it easy, you can buy a whole car with only a few bitcoins, back in my day a pizza cost 10,000 bitcoins!"
Daily volume atm: 6,348,767.4
Looks like things are heading down ! There appears to be a large sell off happening.
The Crash Continues!
You doing 600 sequential write TPS to the same table?
No. Across (on average) 50 tables. The 600 attributes equates to about 80 rows.Quote
Because Gox can't be issuing simultaneous txns -- all trades must happen right against the highest bid and lowest ask. If so, man... something is wrong with my database and right with yours!
They should be able to. Consider a single buyer hitting 6 different sellers at the same price. It should be matched as a set and serialised sequentially.
Quote
It can't be the matching... that's just popping the top element off a sorted list in RAM. Lock, pop, unlock. The DB write has the same exclusivity (lock) requirements but the op takes a LOT longer...
It's hard to tell what algo they are using but I am starting to think they have bids and asks in the same table and then attempt to pull data and match in
Personally (and given the lack of info), I would have spun the bids and asks into separate tables and used a JOIN for the matching algo.
(You can tell I am a DBA because I shove as much data logic into the back end)
Quote
Edit: Anyway speculation abt this is fun but probably fruitless, Gox is making so much $ right now they aren't going to risk changing anything right now and unfortunately it doesn't seem like the market share will change b/c Gox has "shown" that they can handle holding onto the $ if not the txn speed. We need a trusted player like bitinstant to compete...
Agreed. The worst critics are programmers. If I didn't write it, it sucks :-)
We're headed to a billion, boys.
I agree. We just hit 500 Million on the Market Cap. That's huge. We should see something happen right about now. Not a total collapse, but some sort of consolidation or retracement.
correction is now
I agree. We just hit 500 Million on the Market Cap. That's huge. We should see something happen right about now. Not a total collapse, but some sort of consolidation or retracement.
@adamstgBit
Perhaps its time to lock this thread and start a new one? Screen is almost filled with page numbers as this thread is getting a bit too long.
Perhaps its time to lock this thread and start a new one? Screen is almost filled with page numbers as this thread is getting a bit too long.
Don't do it adam. Be bullish on your on thread at least.
Buy a bigger screen!
this thread is best viewed with 1680X1050 resolution
buy one they are cheep like dirt!
http://bitcoinstore.com/information-technology/computer-displays.html?dir=asc&order=price
@adamstgBit
Perhaps its time to lock this thread and start a new one? Screen is almost filled with page numbers as this thread is getting a bit too long.
Perhaps its time to lock this thread and start a new one? Screen is almost filled with page numbers as this thread is getting a bit too long.
Don't do it adam. Be bullish on your on thread at least.
Buy a bigger screen!
this thread is best viewed with 1680X1050 resolution
buy one they are cheep like dirt!
http://bitcoinstore.com/information-technology/computer-displays.html?dir=asc&order=price
You doing 600 sequential write TPS to the same table? Because Gox can't be issuing simultaneous txns -- all trades must happen right against the highest bid and lowest ask. If so, man... something is wrong with my database and right with yours!
It can't be the matching... that's just popping the top element off a sorted list in RAM. Lock, pop, unlock. The DB write has the same exclusivity (lock) requirements but the op takes a LOT longer...
Actually I suppose they wouldn't have to do it that way; all bids and asks could be in RAM only and just be lost in the unlikely event of a crash (no one would lose $). But based on the performance I think they are not...
Edit: Anyway speculation abt this is fun but probably fruitless, Gox is making so much $ right now they aren't going to risk changing anything right now and unfortunately it doesn't seem like the market share will change b/c Gox has "shown" that they can handle holding onto the $ if not the txn speed. We need a trusted player like bitinstant to compete...
Not reads. Writes (update & inserts). I use the word "unique attribute" to ignore the composite keys.
Agreed. But any half arsed SATA (or probably IDE) drive should not blink at the tps produced by Gox.
But it all depends on the db logical-to-physical mapping...
I reckon it is the front end matching algo implementation that is screwing performance. I hazard a guess they are suffering lock/threading issues.
It can't be the matching... that's just popping the top element off a sorted list in RAM. Lock, pop, unlock. The DB write has the same exclusivity (lock) requirements but the op takes a LOT longer...
Actually I suppose they wouldn't have to do it that way; all bids and asks could be in RAM only and just be lost in the unlikely event of a crash (no one would lose $). But based on the performance I think they are not...
Edit: Anyway speculation abt this is fun but probably fruitless, Gox is making so much $ right now they aren't going to risk changing anything right now and unfortunately it doesn't seem like the market share will change b/c Gox has "shown" that they can handle holding onto the $ if not the txn speed. We need a trusted player like bitinstant to compete...
Its just an informed guess on my part derived from writing the Gox stream to a RDBMS. When you say "producing 600 unique..." it sounds like you are telling me about reads. These can be cached, etc and so respond much faster... I can also run complex queries rapidly across the Gox data I've written to my RDBMS.
Not reads. Writes (update & inserts). I use the word "unique attribute" to ignore the composite keys.
Quote
But transactional writes cannot be cached -- by the nature of a transaction they need to be written to persistent backing storage before they are acked. And of course its very important to commit a trade as a transaction so there is no chance that person A spends his $ or BTC but person B does not receive it. So essentially the DB performance is chained to the latency speed of the disk -- the time to "seek" and write a few bytes. But because the time to seek and write a few bytes is not much > then the time to seek and write 10k bytes, if the application chunks multiple operations into a single txn you get massive speedup. So even with writes its not the RDBMS, but HOW it is used.
Agreed. But any half arsed SATA (or probably IDE) drive should not blink at the tps produced by Gox.
But it all depends on the db logical-to-physical mapping...
Quote
Anyway, this is just a theory... but just watch Gox unwind a big market buy, ticking through 100's of .1 btc asks at a human readable speed and it becomes pretty obvious that each trade is handled individually. This causes all kinds of problem with efficient price discovery, like "fake" walls. Basically, it looks to me like a bot can use a bunch of .00X btc asks to slow down a big buy and use the time to take down the wall before the buy ticks up to it.
I reckon it is the front end matching algo implementation that is screwing performance. I hazard a guess they are suffering lock/threading issues.
@adamstgBit
Perhaps its time to lock this thread and start a new one? Screen is almost filled with page numbers as this thread is getting a bit too long.
Perhaps its time to lock this thread and start a new one? Screen is almost filled with page numbers as this thread is getting a bit too long.
Don't do it adam. Be bullish on your on thread at least.
Buy a bigger screen!
@adamstgBit
Perhaps its time to lock this thread and start a new one? Screen is almost filled with page numbers as this thread is getting a bit too long.
Perhaps its time to lock this thread and start a new one? Screen is almost filled with page numbers as this thread is getting a bit too long.
Don't do it adam. Be bullish on your on thread at least.
@adamstgBit
Perhaps its time to lock this thread and start a new one? Screen is almost filled with page numbers as this thread is getting a bit too long.
Perhaps its time to lock this thread and start a new one? Screen is almost filled with page numbers as this thread is getting a bit too long.
btw: last wall pic was like, three pages ago... 
Since looking at Bitcoinity, I see they have a section for trading engine lag. Might I ask that when I normally place an order and it's executed by the second I refresh or even after 5 seconds, is that the real "normal" time then?
What do you guys feel is an acceptable amount of delay or what is normal? Under heavy volume I suppose it can't be instant all the time but a 20+ second (or 20 minute) delay is simply not good.
What do you guys feel is an acceptable amount of delay or what is normal? Under heavy volume I suppose it can't be instant all the time but a 20+ second (or 20 minute) delay is simply not good.
I would say a <20 execution for market orders is acceptable if its the same for everyone, i get the feeling that bots making use of the api directly have an unfair advantage, for example theres people on this forum using a penny bot but i cant trade in those small amounts through the web interface, for a penny bot to be successfull i imagine they have to execute trades pretty fast.
but its the cancellation of orders that dosn't work, that is not acceptable for me.
Jump to: