Downlink delay somewhere (asap_count_us)

darkfader · August 12, 2021, 2:15pm

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

Curt_Black · August 12, 2021, 8:38pm

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?

darkfader · August 13, 2021, 7:58am

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 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.

Curt_Black · August 13, 2021, 9:13am

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.

Curt_Black · August 13, 2021, 9:42am

code reference:

github.com

brocaar/chirpstack-concentratord/blob/e611bf0bc2d30f97e7ef4198857cf99af4d8dcb8/libconcentratord/src/jitqueue.rs#L137

    
      
              pre_delay: self.tx_start_delay + self.tx_jit_delay,
              post_delay: time_on_air,
              packet: packet,
          };
          
          
// An immediate downlink becomes a timestamped downlink "ASAP".
          // Set the packet count_us to the first available slot.
          if item.packet.get_tx_mode() == TxMode::Immediate {
              item.packet.set_tx_mode(TxMode::Timestamped);
          
          
    // use now + 1 sec
              let mut asap_count_us =
                  concentrator_count.wrapping_add(Duration::from_secs(1).as_micros() as u32);
          
          
    // check if there is a collision
              if self.collision_test(asap_count_us, item.pre_delay, item.post_delay) {
                  for p in self.items.iter() {
                      asap_count_us = p.packet.get_count_us().wrapping_add(
                          (p.post_delay.as_micros()
                              + item.pre_delay.as_micros()
                              + self.tx_margin_delay.as_micros()) as u32,

brocaar · August 17, 2021, 8:15am

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.

darkfader · August 17, 2021, 8:23am

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

brocaar · August 17, 2021, 9:01am

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…