Downlink delay somewhere (asap_count_us)

I was sending some class C downlink in DR3 (EU). I timed the log outputs and saw it took about a second before it’s actually sent out. The total time from queue to ack is longer than needed. Also my downlink queue interval is set to just 100ms, which gives like 50ms queue delay on average.
If it’s an immediate packet, I would expect just the queue delay and the short pre-delay of setting up the gateway. But perhaps I’m missing some setting somewhere?

I’m running RPi3 + Concentrator OS (+latest binaries) + Dragino PG1301 HAT containing SX1301, GNSS option disabled since PPS signal not wired properly)

The log timing may not be accurate since it’s via SSH and piped to a timing tool. Relevant lines filtered.

timestamp (sec.) message
14.00404 Enqueueing immediate packet, current_counter_us: 760804832
14.00435 Packet enqueued, count_us: 761804832
15.00342 Scheduled packet for TX, count_us: 761804832
15.00358 Frame received, count_us: 762129644 (this is 324 ms later than TX. this is totally correct for DR3 in both directions)

Edit: it may not be concentratord persay. I think I see the same with lora_pkt_fwd on an LG308 gateway. It takes like 1 sec. to even send out the downlink packet.
0.00000 lora_pkt_fwd[]: DEBUG: insert IMMEDIATE downlink, first in JiT queue (count_us=1997326471)
0.02446 lora_pkt_fwd[]: node[0]: count_us=1997326471,type=2, pre_delay=31500, post_delay=99000
0.02452 lora_pkt_fwd[]: enqueued packet with count_us=1997326471 (size=15 bytes, toa=99000 us, type=2)
0.96764 lora_pkt_fwd[]: peek packet with count_us=1997326471 at index 0
0.97529 lora_pkt_fwd[]: dequeued packet with count_us=1997326471 from index 0
0.99641 lora_pkt_fwd[]: INFO~ [LGWSEND] lgw_send done: count_us=1997326471, freq=869525000, size=15

Yes semtech packet forwarder also does this. I found this line of code in the JIT scheduler of pkt_forwarder, which is doing this:

asap_count_us = time_us + 1E6; /* TODO: Take 1 second margin, to be refined */

Anything similar in concentratord?

Ah yes, I found it:

let mut asap_count_us =
            concentrator_count.wrapping_add(Duration::from_secs(1).as_micros() as u32);

I wonder how it could be refined :slight_smile: I think a configuration option may be sufficient.
Edit: For now, I just changed from_secs(1) to from_millis(100) and built the thing with the easy-to-use makefile.

This is a question for @brocaar – I am not really sure why Semtech put “+1 second” into the packet forwarder for immediate packets (e.g. imme:“true” / Class C). Maybe he knows the reason behind this.

1 Like

code reference:

When implementing the Concentratord, I initially followed the Semtech UDP Packet Forwarder source, which includes this 1sec delay. As the “immediate” packet needs to be converted to an internal board counter value for collision checking, probably this interval could be reduced.

It seems for Semtech basicstation, it’s configurable and seems to have 100ms as default.
“CLASS_C_BACKOFF_BY”: “100ms”,

Would you mind creating an issue here: Issues · brocaar/chirpstack-concentratord · GitHub? Then I can look into this at a later moment. Or if you would like to create a pull-request for this… :slight_smile: