To answer my own question: I think there is a reason for not doing so. If cake_enqueue() gets called there is a packet we need to dequeue later on. So it wouldn't be wise to schedule the watchdog blindly at "now+q->tins[i].cparams.target" even though the scheduler's queue is still empty at that point.  >On Sunday, September 17, 2017, 10:34:31 AM EDT, George Amanakis wrote: >Dear Jonathan, >I am looking/testing the latest cobalt updates.Most of them make sense. >I have a question though. >At the end of cake_dequeue() you schedule the watchdog at >"now+q->tins[i].cparams.target" if "!sch->q.qlen". This seems very >reasonable. Instead in the beginning of cake_enqueue() you do: > > 916                 if (!sch->q.qlen) { > 917                         if (q->time_next_packet < now) { > 918                                 q->time_next_packet = now; > 919                         } else if (q->time_next_packet > now) { > 920                                 sch->qstats.overlimits++; > 921 #if LINUX_VERSION_CODE < KERNEL_VERSION(4, 8, 0) > 922 codel_watchdog_schedule_ns(&q->watchdog, q->time_next_packet, true); > 923 #else > 924 qdisc_watchdog_schedule_ns(&q->watchdog, q->time_next_packet); > 925 #endif > 926                         } > 927                 } > 928         } > >Is there any reason why you haven't scheduled the watchdog at >"now+q->tins[i].cparams.target" like in cake_dequeue()? > >Thank you, >George