> > To achieve this capacity with HZ=1000 without increasing the storage size > by another level, we reduced the granularity of the first wheel level from > 1ms to 4ms. According to our data, there is no user which relies on that > 1ms granularity and 99% of those timers are canceled before expiry. >
Ah... This might be a problem for people using small TCP RTO timers in datacenters (order of 5 ms) (and small delay ack timers as well, in the order of 4 ms) TCP/pacing uses high resolution timer in sch_fq.c so no problem there. If we arm a timer for 5 ms, what are the exact consequences ? I fear we might trigger lot more of spurious retransmits. Or maybe I should read the patch series. I'll take some time today. Thanks !
