Is it possible to uniquely identify a Tick?

Not that I know of, ie, no unique id with the data. Resolution via various builtins or (via Windows API call is ltd to millisecs (I believe) unless maybe go down to board level but this proves nowt.

Might be rhetorical question, but let's say you found out that various h/w platforms have different data ticks etc. Is just real life is it not? viz: can you actually 100% warrant that any platform is identical down to the crystal clock on timer chip?

Just think of all the many places where a delay can be identified. Server to Terminal to interpreter etc, is a massively long pot holed road, yes?

iow, the terminal your on is where 'its at' if thats where trades are made. Ok, maybe is significant but not see it. If a trading system? is that sensitive, surely, is never going to survive the cut 'n thrust of R/T trading

Just thoughts...

Anyway, interesting to see what others may post... more learning for us all!!!

In theory, assuming that the broker's servers are all synchronised and that ticks are transmitted in order and received by every connected client, then the unique ID of a tick is Time[0] plus the number of ticks received so far in the bar. In practice, not so much. Any feasible answer really depends on why you need to establish a unique tick ID (particularly given that spot forex is OTC, and the ticks through one broker won't match the ticks through another broker, or even through different types of account on the same broker.) Personally, I'm not even certain what happens to ticks which are received while your EA is still processing the previous tick. I don't think they're queued; I think they're just discarded.

The following isn't exactly helpful, but I'll post it anyway... The GetTickCount() function in MT4/Win32 isn't even precise to the millisecond. For example, with the following code:

int start()
{
   int t1 = GetTickCount();
   Sleep(100);
   int t2 = GetTickCount();
   MessageBox("Delay: " + (t2- t1));
}

...I personally see results of either 93/94 milliseconds or 109/110 milliseconds. If you want more precise timings on Windows you have to use something like QueryPerformanceCounter() and QueryPerformanceFrequency().

Being able to identify a tick would, for example, help in analyzing data feed and reception quality between the broker's server and the MetaTrader terminal, e.g. in the case of comparing different commercial VPSs. We'd be able to see and match up in a database exactly which ticks were received and which were lost on each terminal (instead of just having a count).

At the moment all I can think of is using TimeCurrent() with local clock time (which can have millisecond or microsecond precision) via kernel32.dll function call, but this means the different computers must have their clocks perfectly synchronized.

You're still dealing with any number of variables, and it's a case of which ones you feel it's important to take into account. For example, I'm not personally a big fan of taking latency into account with MT4 (see last post in 'Mystery results on the same EA from different brokers!!!'), but it's likely to have an effect on what you're calling "reception quality".

They are discarded.

The accepting/discarding of ticks is what I'm trying to analyze, and being able to uniquely identify a tick (within one broker's server) would be a great help in such analysis.

Telling you what you doubtless already know, this means that you're concerned about more than just data transfer "between the broker's server and the MetaTrader terminal". Even just to test this facet in isolation, you obviously need to implement a super-fast logging function which is guaranteed to return from start() within microseconds, so that one tick isn't lost because your logging is still handling the last tick. Extending that, in real life your EA's ability not to miss ticks depends on how fast it runs, which is partly dependent on all sorts of things such as the VPS processing power, speed of the disk sub-system etc. Most of the VPS solutions seem to use Virtuozzo, and their results in these areas are transient. The VPS providers aren't guaranteeing that the speed performance you see today will be precisely the same as what you see next week. Putting it another way, "accepting/discarding" of ticks is partly going to depend on the contention on the VPS nodes. Even if you could record tick IDs and do comparisons, the results aren't guaranteed to be the same tomorrow, let alone in a week's or a month's time.

Yes, there are a whole lot of variables, and things can change. I'd like to make a start at analyzing such variables quantitatively, and this is why I want to be able to track ticks by running a number of different terminals on different computers/VPSs all connected to the same broker server. I can then see which terminals get which ticks through database queries which would match by an ID field, but without proper tick IDs, I'd need some kind of workaround.