[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strange results using Linux DiffServ + last packet pending



Hello all,
I have experience a similar problem in past with a priority + tbf queus. (pending
packet) Alexey released an unofficial patch for the 2.2.x series (at the 2.4
series this should probably be fixed) that it worked fine for me. I include it
and I am really curious to hear if it will improve the cbq behaviour.
(You may better apply it manually, it is very simple)

diff -ur ../vger-000131/linux/include/net/pkt_sched.h
linux/include/net/pkt_sched.h
--- ../vger-000131/linux/include/net/pkt_sched.h        Sat May  1 16:28:20 1999
+++ linux/include/net/pkt_sched.h       Mon Jan 31 22:29:12 2000
@@ -387,7 +387,7 @@
 void qdisc_run_queues(void);
 int qdisc_restart(struct device *dev);

-extern __inline__ void qdisc_wakeup(struct device *dev)
+extern __inline__ void qdisc_wakeup_one(struct device *dev)
 {
        if (!dev->tbusy) {
                struct Qdisc *q = dev->qdisc;
@@ -397,6 +397,23 @@
                }
        }
 }
+
+extern __inline__ void qdisc_wakeup(struct device *dev)
+{
+       if (!dev->tbusy) {
+               struct Qdisc *q = dev->qdisc;
+               int res;
+
+               while ((res = qdisc_restart(dev)) < 0 && !dev->tbusy)
+                       /* NOTHING */;
+
+               if (res && q->h.forw == NULL) {
+                       q->h.forw = qdisc_head.forw;
+                       qdisc_head.forw = &q->h;
+               }
+       }
+}
+

 extern __inline__ unsigned psched_mtu(struct device *dev)
 {



>
> Yes, I have. Probably the Linux CBQ implementation is buggy.
> I've also seen other anomalies: For example, it is possible for a packet to
> be indefinitely waiting on the queue, only to be sent when another packet
> arrives at the system. I found this out when some tests resulted in all but
> one packet out of sequence and with a peak jitter of more than 100
> seconds(!!!). The last packet from the flow of a previous test was still
> pending, so the first received packet would have a sequence number higher
> than all others, and thus would be the only one considered in sequence. On
> the other hand, it would take all the time between the two tests to
> transverse the network, whereas the first packet of the second test would
> take less than a second, so the measured peak jitter would be enormous.
>
> --
> Rui Prior
>
> --------------------------------------------------
>  /"\
>  \ /
>   X  ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
>  / \
> --------------------------------------------------

--
-----------------------------------------------------
Panagiotis G.Stathopoulos
National Technical University of Athens
Telecommunications Laboratory
E-mail: pstath@telecom.ntua.gr
Tel: +30 1 772 1495     Fax: +30 1 772 2534
------------------------------------------------------