Like @kersing asked: can you confirm that these downlinks are actually accepted by the gateway?
Though a DevAddr is not unique, it seems that the 0x26012FD3 device is sending 24 bytes SF12 uplinks at 16:21:57, 16:22:04 and 16:24:25. That means it’s either not adhering to neither the maximum duty cycle (if applicable in your country), nor the TTN Fair Access Policy (which would allow for less than one such message per hour), or did not receive the downlink and is trying again. And again.
Doesn’t the application’s/device’s Data page show a “retry” in TTN Console? And am I right to assume that those devices are not Tek766 sensors, as they apparently do not initiate a new OTAA Join when not receiving the confirmation or when not seeing some ADR response every now and then?
I think all of the following does not help much, if at all. But here goes, just in case:
Like already noted by @kersing, this already tells you that the total latency is 1.2 seconds. A quick search shows much better values for some others:
Just to confirm that TTN is doing okay, assuming that the timestamps in TTN Console and the gateway are almost in sync, we see:
-
The 15:19:04 Join Request is received by TTN at 15:19:05.441Z. If the clocks are perfectly in sync, lacking the milliseconds in the gateway log that might show it’s been on the network between 0.45 up to 1.44 seconds.
-
It is accepted by the application at 15:19:05.437680347Z.
-
The Join Accept is delegated to the gateway at 15:19:10.443Z, so handling/scheduling in TTN took 5.002 seconds. It’s using 869.525000 MHz, hence is using RX2 which is 6 seconds for an OTAA Join, allowing for almost 1 second of latency. (The RX2 is also confirmed by the 6 seconds difference for the counters in the gateway log, being 3,829,093,340 for the Join Request and 3,835,093,340 in the Join Accept.) So, TTN does not seem to be the bottleneck here. (Well, at least not TTN’s network server; other components might still introduce some latency within TTN itself.)
-
The Join Accept is received at the gateway at 15:19:10, which for perfectly synced clocks would indicate it’s been on the network for 0 up to 0.557 seconds. It claims this is 3835529449 - 3835093340 = 0.436 seconds too late (if the gateway would need zero processing time itself).
I guess one could use some ethernet connected gateway to see if the timestamps in TTN Console and the gateway are almost in sync. Above, as the Join Accept is logged at 15:19:10 in both TTN and the gateway, one might conclude that the worst latency is in receiving the Join Request (from gateway to TTN), not in receiving the Join Accept (from TTN to gateway). But I’d assume this just indicates that the clocks are off a bit, so it’s simply impossible to compare the timestamps.