vMX strict priority queue caps packets even though the interface still has available bandwidth. This article clarifies that this behavior is expected.

vMX queue 1 shows over 10-second packet delay when it is congested:

 Queue: 1, Forwarding classes: COS1
   Queued:
     Packets              :             171832614                 25789 pps
     Bytes                :           21307245180              25583104 bps
   Transmitted:
     Packets              :             134307411                  8109 pps
     Bytes                :           16654119834               8044544 bps
     Tail-dropped packets :              37525203                 17680 pps <-- queue congestion
     RL-dropped packets   :                     0                     0 pps
     RL-dropped bytes     :                     0                     0 bps
     RED-dropped packets  :                     0                     0 pps
      Low                 :                     0                     0 pps
      Medium-low          :                     0                     0 pps
      Medium-high         :                     0                     0 pps
      High                :                     0                     0 pps
     RED-dropped bytes    :                     0                     0 bps
      Low                 :                     0                     0 bps
      Medium-low          :                     0                     0 bps
      Medium-high         :                     0                     0 bps
      High                :                     0                     0 bp

 lab@vmx# run ping 1.1.3.2 tos 128 
 64 bytes from 1.1.3.2: icmp_seq=0 ttl=64 time=10730.713 ms
 64 bytes from 1.1.3.2: icmp_seq=1 ttl=64 time=10712.496 ms 
 --- 1.1.3.2 ping statistics ---
 13 packets transmitted, 2 packets received, 84% packet loss round-trip min/avg/max/stddev = 10712.496/10721.604/10730.713/9.109 ms

This behavior is expected as per CoS on vMX Overview . See the section on fixed priorities and queues for traffic classes.

Both Traffic Class 1 and Traffic Class 2 follow strict priority, so all excess traffic is discarded as tail drops. However, Traffic Class 3 does not follow strict priority, so the shaping rate is set to the shaping rate of the VLAN.

The transmit rate of queue 1 is capped at 8M (1% of the 800M interface rate) by the following configuration:

        scheduler_COS1 {
             transmit-rate percent 1;
             buffer-size {
                 remainder;

Unlike the low priority queues, strict priority queues cannot transmit beyond the allocated transmit rate (8M) even though the interface itself still has 99% (800M-8M) available bandwidth. Excessive packets will be buffered and dropped when the buffer space is exhausted.

You can configure delay-buffer-rate to limit the buffer size in order to reduce the packet delay, but more packets could be dropped due to the reduced buffer space size. Refer to delay-buffer-rate for more details.

2019-12-13. URL for documentation on delay-buffer-rate corrected in Solution section