On Fri, 16 Mar 2001, Mårten Wikström wrote:
[much text]
> Thanks! I'll try that out. How can I tell if the driver supports
> CONFIG_NET_HW_FLOWCONTROL? I'm not sure, but I think the cards are
> tulip-based, can I then use Robert & Jamal's optimised drivers?
> It'll probably take some time
>
> You want to have CONFIG_NET_HW_FLOWCONTROL enabled. If you don't the
> kernel gets _alot_ of interrupts from the NIC and dosn't have
> any cycles
> left to do anything. So you want to turn this on!
>
> > At the NordU/USENIX conference in Stockholm (this february) I
> > saw a nice
Manfred Spraul writes:
> >
> > http://Linux/net-development/experiments/010313
> >
> The link is broken, and I couldn't find it at www.linux.com. Did you
> forget the host?
Yes Sir!
The profile data from the Linux production router is at:
On Thu, 15 Mar 2001, Robert Olsson wrote:
>
>
> Jonathan Morton writes:
>
> > Nice. Any chance of similar functionality finding its' way outside the
> > Tulip driver, eg. to 3c509 or via-rhine? I'd find those useful, since one
> > or two of my Macs appear to be capable of generating
> > Or are you saying that the bottleneck is somewhere
> > else completely,
>
> Indeed. The bottleneck is with processing the incoming network
> packets, at the interrupt level.
Where is the counter for these dropped packets? If we run a few mbit of
traffic through the box, we see noticeble
Jonathan Morton writes:
> Nice. Any chance of similar functionality finding its' way outside the
> Tulip driver, eg. to 3c509 or via-rhine? I'd find those useful, since one
> or two of my Macs appear to be capable of generating pseudo-DoS levels of
> traffic under certain circumstances
Gregory Maxwell wrote:
> The scheduler schedules tasks not interrupts. Unless it manages to thrash the
> cache, the scheduler can not affect routing performance.
OK, thanks for the clarification - I need to get into the source.
cu
Jup
-
To unsubscribe from this list: send the line
On Thu, Mar 15, 2001 at 11:17:19AM -0800, J Sloan wrote:
> Rik van Riel wrote:
>
> > On Thu, 15 Mar 2001, J Sloan wrote:
> >
> > > There are some scheduler patches that are not part of the
> > > main kernel tree at this point (mostly since they have yet to
> > > be optimized for the common case)
On Thu, Mar 15, 2001 at 11:17:19AM -0800, J Sloan wrote:
> Rik van Riel wrote:
> > On Thu, 15 Mar 2001, J Sloan wrote:
> >
> > > There are some scheduler patches that are not part of the
> > > main kernel tree at this point (mostly since they have yet to
> > > be optimized for the common case)
> And we have done experiments with controlling interrupts and running
> the RX at "lower" priority. The idea is take RX-interrupt and immediately
> postponing the RX process to tasklet. The tasklet opens for new RX-ints.
> when its done. This way dropping now occurs outside the box since and
>
Rik van Riel wrote:
> On Thu, 15 Mar 2001, J Sloan wrote:
>
> > Fun, yes, and perhaps not directly related, however
> > under high load, where the sheer numbet of interrupts
> > per second begins to overwhelm the kernel, might it
> > not be relevant?
>
> No.
>
> > Or are you saying that the
Rik van Riel wrote:
> On Thu, 15 Mar 2001, J Sloan wrote:
>
> > There are some scheduler patches that are not part of the
> > main kernel tree at this point (mostly since they have yet to
> > be optimized for the common case) which make quite a big
> > difference under heavy load - you might
On Thu, 15 Mar 2001, J Sloan wrote:
> Rik van Riel wrote:
> > On Thu, 15 Mar 2001, J Sloan wrote:
> >
> > > http://lse.sourceforge.net/scheduling/
> >
> > Unrelated. Fun, but unrelated to networking...
>
> Fun, yes, and perhaps not directly related, however
> under high load, where the
On Thu, 15 Mar 2001, J Sloan wrote:
> There are some scheduler patches that are not part of the
> main kernel tree at this point (mostly since they have yet to
> be optimized for the common case) which make quite a big
> difference under heavy load - you might want to check out:
>
>
[Sorry for the length]
Rik van Riel writes:
> On Thu, 15 Mar 2001, Robert Olsson wrote:
>
> > CONFIG_NET_HW_FLOWCONTROL enables kernel code for it. But device
> > drivers has to have support for it. But unfortunely very few drivers
> > has support for it.
>
> Isn't it possible to
Just my .02 -
There are some scheduler patches that are not part of the
main kernel tree at this point (mostly since they have yet to
be optimized for the common case) which make quite a big
difference under heavy load - you might want to check out:
http://lse.sourceforge.net/scheduling/
On Thu, 15 Mar 2001, Robert Olsson wrote:
> CONFIG_NET_HW_FLOWCONTROL enables kernel code for it. But device
> drivers has to have support for it. But unfortunely very few drivers
> has support for it.
Isn't it possible to put something like this in the layer just
above the driver ?
It
On Thu, 15 Mar 2001, Rik van Riel wrote:
> On Thu, 15 Mar 2001, [ISO-8859-1] Mårten Wikström wrote:
>
> > I've performed a test on the routing capacity of a Linux 2.4.2 box
> > versus a FreeBSD 4.2 box. I used two Pentium Pro 200Mhz computers with
> > 64Mb memory, and two DEC 100Mbit ethernet
Rik van Riel writes:
> On Thu, 15 Mar 2001, [ISO-8859-1] Mårten Wikström wrote:
>
> > I've performed a test on the routing capacity of a Linux 2.4.2 box
> > versus a FreeBSD 4.2 box. I used two Pentium Pro 200Mhz computers with
> > 64Mb memory, and two DEC 100Mbit ethernet cards. I used a
On Thu, 15 Mar 2001, [ISO-8859-1] Mårten Wikström wrote:
> I've performed a test on the routing capacity of a Linux 2.4.2 box
> versus a FreeBSD 4.2 box. I used two Pentium Pro 200Mhz computers with
> 64Mb memory, and two DEC 100Mbit ethernet cards. I used a Smartbits
> test-tool to measure the
On Thu, 15 Mar 2001, [ISO-8859-1] Mårten Wikström wrote:
I've performed a test on the routing capacity of a Linux 2.4.2 box
versus a FreeBSD 4.2 box. I used two Pentium Pro 200Mhz computers with
64Mb memory, and two DEC 100Mbit ethernet cards. I used a Smartbits
test-tool to measure the
Rik van Riel writes:
On Thu, 15 Mar 2001, [ISO-8859-1] Mrten Wikstrm wrote:
I've performed a test on the routing capacity of a Linux 2.4.2 box
versus a FreeBSD 4.2 box. I used two Pentium Pro 200Mhz computers with
64Mb memory, and two DEC 100Mbit ethernet cards. I used a Smartbits
On Thu, 15 Mar 2001, Rik van Riel wrote:
On Thu, 15 Mar 2001, [ISO-8859-1] Mrten Wikstrm wrote:
I've performed a test on the routing capacity of a Linux 2.4.2 box
versus a FreeBSD 4.2 box. I used two Pentium Pro 200Mhz computers with
64Mb memory, and two DEC 100Mbit ethernet cards. I
On Thu, 15 Mar 2001, Robert Olsson wrote:
CONFIG_NET_HW_FLOWCONTROL enables kernel code for it. But device
drivers has to have support for it. But unfortunely very few drivers
has support for it.
Isn't it possible to put something like this in the layer just
above the driver ?
It
Just my .02 -
There are some scheduler patches that are not part of the
main kernel tree at this point (mostly since they have yet to
be optimized for the common case) which make quite a big
difference under heavy load - you might want to check out:
http://lse.sourceforge.net/scheduling/
[Sorry for the length]
Rik van Riel writes:
On Thu, 15 Mar 2001, Robert Olsson wrote:
CONFIG_NET_HW_FLOWCONTROL enables kernel code for it. But device
drivers has to have support for it. But unfortunely very few drivers
has support for it.
Isn't it possible to put
On Thu, 15 Mar 2001, J Sloan wrote:
There are some scheduler patches that are not part of the
main kernel tree at this point (mostly since they have yet to
be optimized for the common case) which make quite a big
difference under heavy load - you might want to check out:
Rik van Riel wrote:
On Thu, 15 Mar 2001, J Sloan wrote:
There are some scheduler patches that are not part of the
main kernel tree at this point (mostly since they have yet to
be optimized for the common case) which make quite a big
difference under heavy load - you might want to check
On Thu, 15 Mar 2001, J Sloan wrote:
Rik van Riel wrote:
On Thu, 15 Mar 2001, J Sloan wrote:
http://lse.sourceforge.net/scheduling/
Unrelated. Fun, but unrelated to networking...
Fun, yes, and perhaps not directly related, however
under high load, where the sheer numbet of
And we have done experiments with controlling interrupts and running
the RX at "lower" priority. The idea is take RX-interrupt and immediately
postponing the RX process to tasklet. The tasklet opens for new RX-ints.
when its done. This way dropping now occurs outside the box since and
Rik van Riel wrote:
On Thu, 15 Mar 2001, J Sloan wrote:
Fun, yes, and perhaps not directly related, however
under high load, where the sheer numbet of interrupts
per second begins to overwhelm the kernel, might it
not be relevant?
No.
Or are you saying that the bottleneck is
On Thu, Mar 15, 2001 at 11:17:19AM -0800, J Sloan wrote:
Rik van Riel wrote:
On Thu, 15 Mar 2001, J Sloan wrote:
There are some scheduler patches that are not part of the
main kernel tree at this point (mostly since they have yet to
be optimized for the common case) which make quite
Gregory Maxwell wrote:
The scheduler schedules tasks not interrupts. Unless it manages to thrash the
cache, the scheduler can not affect routing performance.
OK, thanks for the clarification - I need to get into the source.
cu
Jup
-
To unsubscribe from this list: send the line "unsubscribe
On Thu, Mar 15, 2001 at 11:17:19AM -0800, J Sloan wrote:
Rik van Riel wrote:
On Thu, 15 Mar 2001, J Sloan wrote:
There are some scheduler patches that are not part of the
main kernel tree at this point (mostly since they have yet to
be optimized for the common case) which make
Jonathan Morton writes:
Nice. Any chance of similar functionality finding its' way outside the
Tulip driver, eg. to 3c509 or via-rhine? I'd find those useful, since one
or two of my Macs appear to be capable of generating pseudo-DoS levels of
traffic under certain circumstances which
Or are you saying that the bottleneck is somewhere
else completely,
Indeed. The bottleneck is with processing the incoming network
packets, at the interrupt level.
Where is the counter for these dropped packets? If we run a few mbit of
traffic through the box, we see noticeble
On Thu, 15 Mar 2001, Robert Olsson wrote:
Jonathan Morton writes:
Nice. Any chance of similar functionality finding its' way outside the
Tulip driver, eg. to 3c509 or via-rhine? I'd find those useful, since one
or two of my Macs appear to be capable of generating pseudo-DoS
Manfred Spraul writes:
http://Linux/net-development/experiments/010313
The link is broken, and I couldn't find it at www.linux.com. Did you
forget the host?
Yes Sir!
The profile data from the Linux production router is at:
You want to have CONFIG_NET_HW_FLOWCONTROL enabled. If you don't the
kernel gets _alot_ of interrupts from the NIC and dosn't have
any cycles
left to do anything. So you want to turn this on!
At the NordU/USENIX conference in Stockholm (this february) I
saw a nice presentation on
On Fri, 16 Mar 2001, Mrten Wikstrm wrote:
[much text]
Thanks! I'll try that out. How can I tell if the driver supports
CONFIG_NET_HW_FLOWCONTROL? I'm not sure, but I think the cards are
tulip-based, can I then use Robert Jamal's optimised drivers?
It'll probably take some time before I can
40 matches
Mail list logo
