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

Re: Strange results using Linux DiffServ + last packet pending



Hello all,
That is interesting. Do you think that the CBQ traffic shaping problems that
have been repeatedly been reported is due to this??? If this is the case CBQ for
DiffServ PHBs at the 2.2.4 kernel should work correctly and this is something
that we should test.
Rui, about the qdisc_wakeup_one I didn't have noticed it on the first place, but
I think that it is useless, probably it was something left over from testing...
I will recompile the kernel without this function. BTW this patch was not
included on any of the 2.2.2 kernels but it supposed to be a 2.2.4 feature.
Regards,
Panagiotis

"Buhler, William" wrote:

> I applied the patch and it seems to have corrected the problem.  I am no
> longer getting the burst when transferring over two or more flows.  In fact
> the whole diffserv functionality seems to be working better (or should I
> say, the way I think it should).  I haven't tried the 2.4.1 kernel but I
> will.  I did some checking on another machine that I have set up and had
> applied the ds-8 patches.  This system is running 2.2.16 and this patch is
> also missing.  Thanks for the great help.
>
> William
>
> -----Original Message-----
> From: jamal [mailto:hadi@cyberus.ca]
> Sent: Wednesday, January 31, 2001 7:06 AM
> To: Panagiotis Stathopoulos
> Cc: Rui Prior; diffserv-linux
> Subject: Re: Strange results using Linux DiffServ + last packet pending
>
> This patch is not in 2.2.17. I wonder actually if it ever made it into
> 2.2 at all.
> William, could you re-test with this patch and/or test with kernel 2.4.1
> to see if the problem is still there? Rui, are you also using the 2.2
> patches or is it 2.4?
> Panagiotis, there seems to be something missing in that patch. Where does
> qdisc_wakeup_one get used?
>
> cheers,
> jamal
>
> On Wed, 31 Jan 2001, Panagiotis Stathopoulos wrote:
>
> > 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
> > ------------------------------------------------------
> >
> >

--
-----------------------------------------------------
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
------------------------------------------------------