On Sun, 15 Oct 2000, bert hubert wrote:
> > It does not really, provided this tcp/ip is linux-2.4 tcp/ip. 8)8)
> >
> > Yes, of course, it is problem. That's why I did not recommend
> > to use per-packet balancing and to use multipath routes instead,
> > when it is possible.
>
> For people who want to speed up single tcp/ip sessions, it's not possible. I
> have noted in the HOWTO however that Linux is 'smart' about this reordering.
>
Probably _the only OS today_ with these features, thanks to the good work
by Alexey.
> > It is possible, of course. And no doubts, it will be useful.
> > Only not ingres qdisc, I think, but netfilter plugin. ingres
> > qdisc is netfilter plugin itself.
>
> Ok.
>
Actually it can be done at the ingress qdisc; i just question its
usefulness.
Infact devik@xxxxxxxxxxxxx had a patch for the ingress qdisc (my memory is
hazy at the moment, maybe he had an alternative).
> > But it will not work very well. You will not able to answer
> > to the question what is this "some latency". If you balance modem links
> > you will have to select "some latency" bw*dev_queue_len+<some good delta>.
> > It is big number.
>
> It may not be generally useful, true. However, if we equip the reordering
> queue with some brains, it might just work. For example, it might have a
> fair chance of detecting the 'immediate-next' packet, and send that
> directly. For example
>
> 2 1
> -> send 1 2, sequence matches
>
> If it doesn't detect such a match, just send after n ms. I'm no router
> expert, just thinking out loud.
>
To re-iterate what Alexey points out (look at his mail again on this):
Where do you draw the line? How long timewise or packet-count-wise do
you wait? those are the hard questions you have to answer. And they are
hard because of the non-determinism of the re-ordering.
I have experimented with schemes like these, result: CPU utilization goes
up 1) as the number of flows increase 2) as the bandwidth of the flow goes
up. Very easily you hit the 100% CPU utilization mark even on SMP.
I think we have come a long way from the days Van Jacobson waved his hands
in the air and proclaimed you can have re-ordering of upto three packets
on the intenet (No offense to VJ, I understand the number 3 was based on a
study actually). Making any assumptions on bounds is where the core of the
issue is -- you cant.
> > > # tc qdisc add dev eth0 handle ffff: ingress
> > > RTNETLINK answers: No such file or directory
> > >
> > > I think I included everything needed in the kernel.
> >
You need to provide more information (kernel, config etc).
Questions like these should probably go on the linux-diffserv mailing
list; a few people would respond.
cheers,
jamal
|