The most likely explanation: no one got anything early.
Venue timestamps can often disagree by a significant amount. It is very likely that SIAC (distributors of CQS and CTS) simply are not well synced to the reference clocked used to distribute the report.
Nanex spends a lot of time doing analysis based on precision timing without providing any sort of error analysis as to how well timestamps produced from different references synchronize. It would lend credibility to their hypotheses if they either provided their own reference or provided some measure of margin of error to the timestamps they so heavily rely upon.
For example, if Nanex had stated that they measured the time of release and the time of trades themselves as they appeared in CQS as observed from their machines then they could make a much more concrete statement as to whether: (a) the report was "early" or (b) the trades were "early" relative to one another. Most likely they would observe that the report appeared "early" as measured to their system clock (or possibly some other reference), but the trades did not appear before the report. Of course, Nanex would be smart enough to account for transit latency and other what-not.
The data are printed with the CME's and NYSE's official timestamps. It would not be unprecedented for the CME's timestamps to diverge from, say, the NYSE's. That would present itself as a consistent temporal dislocation between the CME and NYSE, but would be invisible within each data-set (sort of like your calendar putting itself into the wrong time-zone where - the times are off, but they're consistently off, i.e. spacing between events is preserved).
Instead, we see a signal within each dataset and symmetry between them. It could still be a data aberration, but that would implicate the CME and NYSE of having irregular clocks, a far more serious problem than some twat front-running a government report.
Most likely is that this is a real trading signal, but not one based on insider information.
Relative timestamps between venues don't matter. More importantly, using timestamps without a common reference point makes it impossible to assert what happened first, because the absolute value of the timestamp does not matter. What matters is what "really" happened first. Of course, everyone's view of "first" can differ, but that's a different issue.
Whether there is signal here or not wasn't my point. There may well could be. My point was simply that the analysis provided by Nanex is spurious without a definition of the timestamps, where they came from, and their relationship to known reference points. Taking three events with a timestamp from each of: CQS, CME, and an arbitrary point in time such as 10:30:00 and then asserting that events observed within a CQS or CME event stream happened "before" the arbitrary point in time, 10:30:00, is impossible.
Unless either (a) one observes CQS, CME, and the event scheduled for 10:30:00 from a known reference and accounts for all variables (differing transit latencies, etc) or (b) each of the generating events are known synchronized and the current state of that synchronization is observable (CQS lags CME by 475us, government event source leads CME by 1.2ms, etc). Clearing (b) is not happening today. (a) can be accomplished by Nanex, if they so choose.
I've seen exchanges screw up clock time more often than I care to remember, often for the stupidest reason. I once had an exchange claim it was "due to a roofing contractor accidentally interfering with the satellite used to get a GPS time signal".
Network syncing time is hard, my team (at a bank) built our own infrastructure to monitor time sync errors on our own internal servers, we synced externally with two independent clocks. An atomic clock in London and NIST in the US. But we also modelled the exchange's time as well.
We had six independent connections to the exchange (hitting different servers) and we'd reverse engineered the exchanges internal infrastructure so based upon the timing of their messages, the tcp packet headers and their own timestamps we knew exactly what clocks their internal servers were running on (more valuably in our case is it also gave us their internal latency figures). Half the time we knew when their clocks were drifting before they did and could tell them which internal server had the wrong time.
This stuff is hard, you need to know a lot about network latency and time to make sure you're doing it right (have a look at the NTP spec for starters), there's probably only a handful of people in the world who are capable of nailing it and probably most of them work in the military or atomic physics research labs.
> This stuff is hard, you need to know a lot about network latency and time to make sure you're doing it right (have a look at the NTP spec for starters), there's probably only a handful of people in the world who are capable of nailing it and probably most of them work in the military or atomic physics research labs.
Since Hacker News uses a dynamic sorting algorithm for comments, "below" can quickly become "above". It's best to just say something with a link, like, "See my post elsewhere in this thread (https://news.ycombinator.com/item?id=5147300)."
This is the first time I heard about that meme, which means your comment contained the most usable information I gained across all comments in this thread.
Then you will probably find knowyourmeme.com to be educational and edifying ;). HN, however, is not usually where I want to find out about these things, especially when they're so wholly tangential.
Venue timestamps can often disagree by a significant amount. It is very likely that SIAC (distributors of CQS and CTS) simply are not well synced to the reference clocked used to distribute the report.
Nanex spends a lot of time doing analysis based on precision timing without providing any sort of error analysis as to how well timestamps produced from different references synchronize. It would lend credibility to their hypotheses if they either provided their own reference or provided some measure of margin of error to the timestamps they so heavily rely upon.
For example, if Nanex had stated that they measured the time of release and the time of trades themselves as they appeared in CQS as observed from their machines then they could make a much more concrete statement as to whether: (a) the report was "early" or (b) the trades were "early" relative to one another. Most likely they would observe that the report appeared "early" as measured to their system clock (or possibly some other reference), but the trades did not appear before the report. Of course, Nanex would be smart enough to account for transit latency and other what-not.