4 ms·

After seeing some of their posts earlier and comparing it to live data I record at the colocations, I've concluded that they have clock issues which makes these

by niggler 14y ago

After seeing some of their posts earlier and comparing it to live data I record at the colocations, I've concluded that they have clock issues which makes these types of anomalies appear frequently. Or they have a bad data vendor. Interestingly enough, even the regulators don't have good (only millisecond-resolution) trade data.

aidenn0 14y ago
Interesting, so you are saying that Nanex is wrong about someone trading 400ms before the report?
- niggler 14y ago
  To give an example of how this could happen (not saying this is what happened, but I've heard this happened before): Suppose you left ntpd running and automatically adjusting the clock every hour. If your clock is running faster than pool.ntp.org, and you are synchronizing to it, you may end up adjusting in the middle of an event. Because your clock is running fast, you would jump back in time, breaking the sequence of time (this is somewhat equivalent to what you see during daylight savings time if you aren't intelligent in the way you handle the backwards hour shift) In this case, if the adjustment was forward in time, there would be a gap.
  - Firehed 14y ago
    My understanding is that ntpd corrects clock drift by replaying milliseconds consecutively, not by actually jumping back. However I can't remember where I read that and could be totally wrong.
    - wiml 14y ago
      I'm sure there are lots of buggy NTP implementations out there that "adjust the clock every hour", but the way it's supposed to work is by continuously varying the speed of the clock (for example, using adjtime()) to correct any discrepancies. At no point should the clock jump backwards or forwards, or even have milliseconds that are more than X percent longer or shorter than usual.
nanex 14y ago
These are charted with CQS (official) timestamps. Try again.
- rikacomet 14y ago
  hmm, its not only the activity just before the official announcement, but also, just after it. There is no way possible that people can just make make a trade 'after' hearing a report 100-200 milliseconds after the report. The trading before the official announcement is a concrete proof, if this is official, and bug/error free. But then again, this is not my forte.
- niggler 14y ago
  CQS has had issues in the past. You should know this. More importantly, why wouldn't you invest in colocations and collect the data yourself using direct feeds (with GPS clock synchronization etc to validate the data)?
  - nanex 14y ago
    We do. You are grossly misinformed. The charts correctly show the sequence and times of this event. I'm not going to engage this discussion further, though pmail is fine.
    - rikacomet 14y ago
      Hi, sorry for being off-topic for other reasons, I want to have a personal chat with you, my email is abtocool'at'gmail please send me a line, when you can. Cheers.
    - scott_s 14y ago
      As a bystander who does not have the background necessary to evaluate either of your claims at face value, I would really like to hear your explanation for why you disagree with his explanation.
      - niggler 14y ago
bentcorner 14y ago
(I don't know a whole lot about the intricacies of trading) Is there a minimum standard "resolution" for trades, or is everything sort of a best effort based on the speed of the computing hardware involved?
- niggler 14y ago
  Each exchange is implemented differently. Some have much lower round trip latency times, but currently latency numbers are in the microsecond range. The quotes themselves are provided with resolution from 1msec to 1nsec (depending on the exchange and on the type of data you wish to receive)
swalsh 14y ago
400 ms is an eternity of time. I can't imagine they'd be off by that much.
- niggler 14y ago
  "is plotted with official exchange timestamps" suggests that they are doing it wrong. You can't compare apples to oranges without knowing how the exchanges are timed. For those who do latency tests, this is a very important point: you should always be on the lookout for what clock is recording the 'start' and the 'stop' and to be sure to consider clock skew. To get a sense for how far timestamps can diverge, OATS -- the reports that are sent to the Financial Industry Regulatory Authority -- require that machines be synced to within 3 seconds of NIST (which is nearly 7.5x longer than the 400ms quoted).
  - nathan_f77 14y ago
    You do seem to know a lot about this topic, but I don't think you should draw any conclusions based on speculation.
    - niggler 14y ago
      There is no "speculation" here: When you measure latency, you always have to be careful about clock issues at the point where you measure the start and the point where you measure the end. This is old-hat for sysadmins and others who deal with these types of issues. This is why round-trip latency numbers are easier to work with: both the start and the end times are taken on the same clock. It's clear, given nanex's responses, that they depended on someone else to give the timestamps. Before concluding that someone had inside information ahead of time, they should check their processes. It's like someone claiming they built a perpetual energy machine because they confused power with energy (i want to say it was paul newman but the name escapes me -- this actually happened)
- varelse 14y ago
  Could be completely explained by someone having the right relay for this data in the right place at the right time (which would have been the result of a considerable outlay of resources and compensation to establish, thus boosting economic output long ahead of any potential killing(tm) made here). And I can't see any particularly efficient way to level the playing field with a government that barely understands facebook and fair use. Just try to explain microsecond latency to them, go ahead, really, should be even more fun than a series of tubes(tm).

by niggler 14y ago

aidenn0 14y ago

Interesting, so you are saying that Nanex is wrong about someone trading 400ms before the report?

niggler 14y ago
To give an example of how this could happen (not saying this is what happened, but I've heard this happened before): Suppose you left ntpd running and automatically adjusting the clock every hour. If your clock is running faster than pool.ntp.org, and you are synchronizing to it, you may end up adjusting in the middle of an event. Because your clock is running fast, you would jump back in time, breaking the sequence of time (this is somewhat equivalent to what you see during daylight savings time if you aren't intelligent in the way you handle the backwards hour shift) In this case, if the adjustment was forward in time, there would be a gap.
- Firehed 14y ago
  My understanding is that ntpd corrects clock drift by replaying milliseconds consecutively, not by actually jumping back. However I can't remember where I read that and could be totally wrong.
  - wiml 14y ago
    I'm sure there are lots of buggy NTP implementations out there that "adjust the clock every hour", but the way it's supposed to work is by continuously varying the speed of the clock (for example, using adjtime()) to correct any discrepancies. At no point should the clock jump backwards or forwards, or even have milliseconds that are more than X percent longer or shorter than usual.

nanex 14y ago

These are charted with CQS (official) timestamps. Try again.

rikacomet 14y ago
hmm, its not only the activity just before the official announcement, but also, just after it. There is no way possible that people can just make make a trade 'after' hearing a report 100-200 milliseconds after the report. The trading before the official announcement is a concrete proof, if this is official, and bug/error free. But then again, this is not my forte.
niggler 14y ago
CQS has had issues in the past. You should know this. More importantly, why wouldn't you invest in colocations and collect the data yourself using direct feeds (with GPS clock synchronization etc to validate the data)?
- nanex 14y ago
  We do. You are grossly misinformed. The charts correctly show the sequence and times of this event. I'm not going to engage this discussion further, though pmail is fine.
  - rikacomet 14y ago
    Hi, sorry for being off-topic for other reasons, I want to have a personal chat with you, my email is abtocool'at'gmail please send me a line, when you can. Cheers.
  - scott_s 14y ago
    As a bystander who does not have the background necessary to evaluate either of your claims at face value, I would really like to hear your explanation for why you disagree with his explanation.
    - niggler 14y ago

bentcorner 14y ago

(I don't know a whole lot about the intricacies of trading) Is there a minimum standard "resolution" for trades, or is everything sort of a best effort based on the speed of the computing hardware involved?

niggler 14y ago
Each exchange is implemented differently. Some have much lower round trip latency times, but currently latency numbers are in the microsecond range. The quotes themselves are provided with resolution from 1msec to 1nsec (depending on the exchange and on the type of data you wish to receive)

swalsh 14y ago

400 ms is an eternity of time. I can't imagine they'd be off by that much.

niggler 14y ago
"is plotted with official exchange timestamps" suggests that they are doing it wrong. You can't compare apples to oranges without knowing how the exchanges are timed. For those who do latency tests, this is a very important point: you should always be on the lookout for what clock is recording the 'start' and the 'stop' and to be sure to consider clock skew. To get a sense for how far timestamps can diverge, OATS -- the reports that are sent to the Financial Industry Regulatory Authority -- require that machines be synced to within 3 seconds of NIST (which is nearly 7.5x longer than the 400ms quoted).
- nathan_f77 14y ago
  You do seem to know a lot about this topic, but I don't think you should draw any conclusions based on speculation.
  - niggler 14y ago
    There is no "speculation" here: When you measure latency, you always have to be careful about clock issues at the point where you measure the start and the point where you measure the end. This is old-hat for sysadmins and others who deal with these types of issues. This is why round-trip latency numbers are easier to work with: both the start and the end times are taken on the same clock. It's clear, given nanex's responses, that they depended on someone else to give the timestamps. Before concluding that someone had inside information ahead of time, they should check their processes. It's like someone claiming they built a perpetual energy machine because they confused power with energy (i want to say it was paul newman but the name escapes me -- this actually happened)
varelse 14y ago
Could be completely explained by someone having the right relay for this data in the right place at the right time (which would have been the result of a considerable outlay of resources and compensation to establish, thus boosting economic output long ahead of any potential killing(tm) made here). And I can't see any particularly efficient way to level the playing field with a government that barely understands facebook and fair use. Just try to explain microsecond latency to them, go ahead, really, should be even more fun than a series of tubes(tm).