Re: eepro100 troubles

From: Alan Cox (alan@lxorguk.ukuu.org.uk)
Date: Thu Jun 08 2000 - 20:04:02 EST


> >With a T3 you should have about 60 buffers. Having more is just damaging
> >the performance
> >
> 60 buffers could be as little at 3600 bits on a 45Mb/s medium. Im really
> surprised as your lack of understanding of the subject. But it does explain
> the problems.

Actually you should read the papers on CBQ I think you'll find its you who
doesn't understand this. The only point of buffering on a conventional T3
medium is to smooth over loading packets onto interfaces and scheduling
hiccups. In fact the on card buffers on most modern ethernets are enough.

If you run it channelised then you want maybe 3 or 4 buffers/channel to
be able to fit the channel timing constraints probably less will do.

There is no point having a queue. Once you have a queue you are doing
two things

1. You are storing up a problem that won't go away if susitained

2. You are damping the congestion feedback on the network so the hosts
        don't realise they are overloading you. That forces the tcp window
        up, increases latency, increases host overheads, and does very
        bad things to retransmit overheads especially on hosts that lack
        SACK support.

Your queue and your bandwidth control are also seperate the CBQ and
scheduling doesnt need large buffers or large data logs to do queueing for
a lot of hosts using fair sharing rules. You might find the papers on CBQ
and the like worth a read.

The only cases you end up needing a lot of buffering are link layer reliable
accidents like X.25 over LAPB where hop by hop flow control screws everyone.

>From memory the Cisco's have something like 3 packets worth of buffering
on a T1 interface by default.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.rutgers.edu



This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:40 EST