# TTN & GPRS: dealing with the latency **URL:** \ **Category:** TTN Network and Services\ **Created:** [December 18, 2019, 12:19pm UTC](https://www.thethingsnetwork.org/forum/t/ttn-gprs-dealing-with-the-latency/32763 "2019-12-18T12:19:09Z")\ **Posts on this page:** 1\ **Showing post:** 18
**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\ **Post date:** [December 20, 2019, 12:21pm UTC](https://www.thethingsnetwork.org/forum/t/ttn-gprs-dealing-with-the-latency/32763/18 "2019-12-20T12:21:28Z")
This is not an answer, but just in case it helps: - ``` INFO: Received pkt from mote: D00XXXX0 (fcnt=46037) ``` This is a Join Request. The printed DevAddr (which is not a secret) and counter [are bogus](https://www.thethingsnetwork.org/forum/t/only-activation-no-uplinks-downlink-ack-received-on-ttn-console/20867/14) but that’s not an issue. - Seeing the first Join Request at the gateway’s wall time of 10:45:33.971123Z, and then the retry at 10:45:40.253025Z is more than 6 seconds later. Also, 2287977668 - 2281695764 yields 6.281904 seconds now. That’s nicely after RX2, so that’s good; earlier it seemed we saw a difference of only 5.3 seconds, but I guess we can discard that occurrence. - ``` WARNING: [up] ignored out-of sync ACK packet ... PULL_DATA sent: 3 (133.33% acknowledged, ping 1915.86 ms) ``` This out-of-sync error and the funny 133.33% also seem to confirm latency issues. > [@cslorabox](#): > > To be fair, its not immediately clear if you are using a packet forwarder with the jit queue. That typically correlates with a different UDP protocol embedded version number, so it’s possible that if you use a packet forwarder with the queue that fact could be noticed and downlink packets not held over. Does anyone know if TTN supports JIT queues for the Semtech UDP protocol? (And above all: would then send the downlink commands much earlier? If TTN supports it, but as TTN is clearly not showing that in this case, then the protocol version in the TCP dump messages might be relevant? That’s apparently the first byte in the TCP/IP packet.) Also, I wonder if “TOO\_EARLY” isn’t a bug, which should read “TOO\_LATE”. If it is, then I’d assume Kerlink would have fixed that long ago, making me wonder if there’s more recent software available. But then: even if reported back to TTN I wonder if it’s acting on that error (by, say, sending the downlink command earlier next time). --- _[View the full topic](https://www.thethingsnetwork.org/forum/t/ttn-gprs-dealing-with-the-latency/32763)._