Topic: Mtgox trades per second (Read 4043 times)

Thanks for this analysis.

One possible root cause of Mt.Gox trading engine bad performance is the very liberal policy of allowing traders to issue limit orders without the corresponding dollars or bitcoins. Thus the matching engine must verify that the account has the actual dollars on hand to make a purchase, and must likewise verify the actual bitcoins on hand to make a sale.

The entire trading engine is subject to locks to prevent corruption of data by simultaneous processes. The matching engine must lock each account as it verifies account balances of candidate matched orders. High performance trading engines are designed around the notion of reducing lock contention. See http://lmax-exchange.github.io/disruptor/ .

Bitcoin needs a robust, high performance exchange - as well as security against hackers.

I think it's quite easy; store all orders in an unindexed table in MySQL and run a badly written SQL query to find the next match. I've seen enough awful code to suspect sheer incompetence way before suspecting malice, aka Hanlon/Heinlein's Razor...

MtGox will suspend all trading, but they should suspend orders not on 0.05 price increments. Or, accept order prices down to 0.0001, but charge for them, which would be fine for larger orders.

I did a quick websearch. Here is one guys trading system that does (easily) 100 trades per second on a 400Mhz machine 3 years ago.

video here : http://vimeo.com/18232653

code here : https://code.google.com/p/emte-trading/

In fact, I think it would actually be difficult to write a trading / matching engine that performed as slowly as mtgox. Seriously.

At that rate, their trading engine may be a bunch of folks watching monitors matching up buy/sell orders.

That's a total joke.

So it points to manipulation on purpose, because they just cant be that slow after all these years.

worst lag i witnessed was >50 minutes.

No, you are correct. I've been thinking the same thing for months. I just can't get my head around how it could be that slow. It must be re-sorting the entire order book on every order, added or removed. Not just re-arranging pointers. but actually copying the data on disk, every time. I just can't think of another way it could be slower.

[BTW. this kind of thread really belongs in Service Discussion for future reference.]

My guess is they're still using the old "Magic the Gathering" trading engine, which would work just fine if people traded 1 card per second.      

And they earn shitloads because people get in panic and trade and trande and trade...  Mt.Gox is the most unprofessional player with that much power, related to IT I ever saw. If they don't have enough manpower, they should be able to recruit 100s of IT professionals. It's again only the damn greed which makes it worse for everyone.

I've downloaded the list of all trades executed on Mtgox over the past 24 hours (there's an API URL for that), and wrote a tiny script to count the number of trades during every 1-minute interval.

Turns out, the single worst minute saw SIX trades per second. The top 15 worst 1-minute intervals saw an average of 3.8 trades per second.

Let's try to estimate how many trades per second their engine is capable of. The worst lag I saw over the past 24 hours was about 500 seconds, i.e. 8 minutes. Let's simplify this a lot, and assume that this lag was created after the worst 1-minute interval, when Mtgox saw 370 trades. In the most conservative scenario, a lag of 8 minutes would mean that these 370 trades took 7 minutes to execute (this is a bit of an approximation, but I think it's close enough).

That places the Mtgox trading engine speed at just 0.9 trades per second.

This is so ridiculous that I have to wonder if I made a mistake somewhere. But if I didn't, their trading engine was written by monkeys (something that everyone seems to agree on anyway).

EDIT: I've had someone question the approximation, so I wrote a better script. This one iterates 1 second at a time, queues the trades arriving in that second for execution, then executes trades from the queue at a specified speed (seconds per trade). It then measures the lag directly. Using this code, to get the worst lag of 500 seconds, "seconds per trade" is 0.65, i.e. approximately 1.5 trades per second. But I doubt 500 seconds was the worst lag during these 24 hours...

EDIT: if the worst lag during these trades was 50 minutes as suggested by 2weiX, that places the speed at pretty much exactly 1 trade per second. Hm... how suspicious... (might be an accident though)