---

   tc-hfcs    ( 7 )

---

REALTIME CRITERION

RT criterion ignores class hierarchy and guarantees precise
       bandwidth and delay allocation. We say that a packet is eligible
       for sending, when the current real time is later than the
       eligible time of the packet. From all eligible packets, the one
       most suited for sending is the one with the shortest deadline
       time. This sounds simple, but consider the following example:

       Interface 10Mbit, two classes, both with two-piece linear service
       curves:

           •   1st class - 2Mbit for 100ms, then 7Mbit (convex - 1st
               slope < 2nd slope)

           •   2nd class - 7Mbit for 100ms, then 2Mbit (concave - 1st
               slope > 2nd slope)

       Assume for a moment, that we only use D() for both finding
       eligible packets, and choosing the most fitting one, thus
       eligible time would be computed as D^(-1)(w) and deadline time
       would be computed as D^(-1)(w+l). If the 2nd class starts sending
       packets 1 second after the 1st class, it's of course impossible
       to guarantee 14Mbit, as the interface capability is only 10Mbit.
       The only workaround in this scenario is to allow the 1st class to
       send the packets earlier that would normally be allowed. That's
       where separate E() comes to help. Putting all the math aside (see
       HFSC paper for details), E() for RT concave service curve is just
       like D(), but for the RT convex service curve - it's constructed
       using only RT service curve's 2nd slope (in our example
        7Mbit).

       The effect of such E() - packets will be sent earlier, and at the
       same time D() will be updated - so the current deadline time
       calculated from it will be later. Thus, when the 2nd class starts
       sending packets later, both the 1st and the 2nd class will be
       eligible, but the 2nd session's deadline time will be smaller and
       its packets will be sent first. When the 1st class becomes idle
       at some later point, the 2nd class will be able to "buffer" up
       again for later active period of the 1st class.

       A short remark - in a situation, where the total amount of
       bandwidth available on the interface is larger than the allocated
       total realtime parts (imagine a 10 Mbit interface, but
       1Mbit/2Mbit and 2Mbit/1Mbit classes), the sole speed of the
       interface could suffice to guarantee the times.

       Important part of RT criterion is that apart from updating its
       D() and E(), also V() used by LS criterion is updated. Generally
       the RT criterion is secondary to LS one, and used only if there's
       a risk of violating precise realtime requirements. Still, the
       "participation" in bandwidth distributed by LS criterion is
       there, so V() has to be updated along the way. LS criterion can
       than properly compensate for non-ideal fair sharing situation,
       caused by RT scheduling. If you use UL service curve its F() will
       be updated as well (UL service curve is an extension to LS one -
       see UPPERLIMIT CRITERION section).

       Anyway - careless specification of LS and RT service curves can
       lead to potentially undesired situations (see CORNER CASES for
       examples). This wasn't the case in HFSC paper where LS and RT
       service curves couldn't be specified separately.