Topic: MTGox: data streaming bug or Gox is tricking? ( or maybe i'm wrong :) ) (Read 1001 times)
January 11, 2014, 04:41:59 AM
I've just received an answer from PubNub, they are now working on it with MTGox
January 09, 2014, 04:27:35 AM
As always, i was working on improvements of Bitcoingain Trading Platform. Watching the log, i've seen some trades was received but not computed by the platform's server. After looking in depth on the code, and no error found, i opened log again for a better analysis. That's what i've found:
The system logs every received trade in real time. At a certain point i've seen a series of not computed trades. Here the first two
The server received a trade where time=1389204597696247 (time is in microseconds) at local server time=2014-1-8 19.9.58
The next received trade has time=1389204583244090 , at local server time=2014-1-8 19.10.4 trade not computed
Converting the time in microseconds to normal datetime using http://www.onlineconversion.com/unix_time.htm (cancelling the last 6 digits) i've seen that the first trade has time Wed, 08 Jan 2014 18:09:57 GMT, received on 2014-1-8 19.9.58, and the second trade has time Wed, 08 Jan 2014 18:09:43 GMT, received on 2014-1-8 19.10.4. Server is GMT +1.
What happend? The server received the latest trade for first, the first trade for last. Plus this, the second trade was sent from MTGox servers many seconds after it was effectively created. After this, the server received many unvalid trades in a row. Looking on Bitcoingain's data, wrong trades are about 50% of all trades that are sent from MTGox! Other platforms seen on the web doesn't detect this streaming problem, but the trades you see from them are old, maybe happend 10 seconds ago, despite it's clock tells you they happend right now.
I've written to PubNub (the new streaming service of MTGox) to tell them what's happening. Maybe it is a temporary problem, but it should be solved: at the reported datetime there wasn't a high load of trades slowing down MTGox server, so this bug is really not acceptable, and must be solved in the name of transparency
..... or maybe i'm wrong?
The system logs every received trade in real time. At a certain point i've seen a series of not computed trades. Here the first two
The server received a trade where time=1389204597696247 (time is in microseconds) at local server time=2014-1-8 19.9.58
The next received trade has time=1389204583244090 , at local server time=2014-1-8 19.10.4 trade not computed
Converting the time in microseconds to normal datetime using http://www.onlineconversion.com/unix_time.htm (cancelling the last 6 digits) i've seen that the first trade has time Wed, 08 Jan 2014 18:09:57 GMT, received on 2014-1-8 19.9.58, and the second trade has time Wed, 08 Jan 2014 18:09:43 GMT, received on 2014-1-8 19.10.4. Server is GMT +1.
What happend? The server received the latest trade for first, the first trade for last. Plus this, the second trade was sent from MTGox servers many seconds after it was effectively created. After this, the server received many unvalid trades in a row. Looking on Bitcoingain's data, wrong trades are about 50% of all trades that are sent from MTGox! Other platforms seen on the web doesn't detect this streaming problem, but the trades you see from them are old, maybe happend 10 seconds ago, despite it's clock tells you they happend right now.
I've written to PubNub (the new streaming service of MTGox) to tell them what's happening. Maybe it is a temporary problem, but it should be solved: at the reported datetime there wasn't a high load of trades slowing down MTGox server, so this bug is really not acceptable, and must be solved in the name of transparency
..... or maybe i'm wrong?
Jump to: