I was just made aware of https://marc.info/?l=linux-can&m=152785826628439&w=2 Obviously I'm biased towards fixing bufferbloat, and at the same time not breaking CAN under any circumstance is also important. I wanted to note first that all qdiscs (and various other parts of the linux network subsystem) can drop packets. pfifo_fast will drop packets when the txqueuelen is exceeded. I am curious if this test will drop packets if you try to slam 1000+ packets in there? CAN drivers should specify their requisite qdisc - noqueue is a good choice if you are handling all the needed buffering yourself. The default qdisc does not apply over that. I do not know how widespread this problem is (in scanning the web I see noqueue in several CAN examples, a short txqueuelen in others, an overlarge (for can) MTU in others) I will go poke into the "PEAK USB CAN" driver and this portion of the stack this week. there's now a systemd bug: https://github.com/systemd/systemd/issues/9194 and an openwrt bug (they don't even ship pfifo_fast anymore!) https://bugs.openwrt.org/index.php?do=details&task_id=1759&string=CAN&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto= -- Dave Täht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619