is RTL8139 THAT bad?

View: New views
9 Messages — Rating Filter:   Alert me  

is RTL8139 THAT bad?

by Wojciech Puchar-5 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

i have pentium 200 with that card. doing ftp from other machine, getting
3.5MB/s (HDD can 10MB/s, DMA) having 45%-55% interrupt load.

when sending it's not that bad.

tried writing file to disk with cat /dev/zero >file, it's only 3% ints
with 10MB/s traffic.


Why it's THAT bad?

3.5MB/s is less that 2500 packets/second. 50% at 200Mhz means 100000000
cycles spend on interrupt service, which is 40000 CPU cycles per packet.

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: is RTL8139 THAT bad?

by Dag-Erling Smørgrav :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Wojciech Puchar <wojtek@...> writes:
> Why it's THAT bad?

http://svn.freebsd.org/base/head/sys/pci/if_rl.c

Scroll down past the copyright, license and attribution.  Read the
38-line comment that explains just how crappy this chip really is.

Executive summary: every single transmitted frame must be copied from
the mbuf into a DMA transmit buffer, and every single received frame
must be copied from the (quite small) DMA receive buffer into an mbuf.
In addition, the transmit queue can only hold four frames.

Other chips use scatter-gather lists and other mechanisms which allow
them to DMA frames straight out of or into mbufs.

DES
--
Dag-Erling Smørgrav - des@...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: is RTL8139 THAT bad?

by Wojciech Puchar-5 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> Wojciech Puchar <wojtek@...> writes:
>> Why it's THAT bad?
>
> http://svn.freebsd.org/base/head/sys/pci/if_rl.c
>
> Scroll down past the copyright, license and attribution.  Read the
> 38-line comment that explains just how crappy this chip really is.

Well - really "low end".

But - this computer can do memcpy at 80MB/s, so at 3.5MB/s it should be 5%
CPU for memcpy, and one interrupt per one packet (2500 packets/s).

Is something more that make it consume >50% CPU?
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: is RTL8139 THAT bad?

by Sergey Babkin :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Wojciech Puchar wrote:

>
> > Wojciech Puchar <wojtek@...> writes:
> >> Why it's THAT bad?
> >
> > http://svn.freebsd.org/base/head/sys/pci/if_rl.c
> >
> > Scroll down past the copyright, license and attribution.  Read the
> > 38-line comment that explains just how crappy this chip really is.
>
> Well - really "low end".
>
> But - this computer can do memcpy at 80MB/s, so at 3.5MB/s it should be 5%
> CPU for memcpy, and one interrupt per one packet (2500 packets/s).
>
> Is something more that make it consume >50% CPU?

Accessing the on-card memory through PCI is guaranteed to be
slower than the main memory, and depending on the particular
card it may be much slower.

-SB
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: is RTL8139 THAT bad?

by Pyun YongHyeon :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Sun, Jun 21, 2009 at 05:14:29PM +0200, Wojciech Puchar wrote:

> i have pentium 200 with that card. doing ftp from other machine, getting
> 3.5MB/s (HDD can 10MB/s, DMA) having 45%-55% interrupt load.
>
> when sending it's not that bad.
>
> tried writing file to disk with cat /dev/zero >file, it's only 3% ints
> with 10MB/s traffic.
>
>
> Why it's THAT bad?
>

Because CPU always have to copy frames to/from the controller.
These CPU cycles could have been used in other task to give more
performance such as SSH encryption/decryption, checksum computation
etc.

> 3.5MB/s is less that 2500 packets/second. 50% at 200Mhz means 100000000
> cycles spend on interrupt service, which is 40000 CPU cycles per packet.
>

That depends on your application. It would be ok for normal desktop
PCs with fast CPU but it wouldn't be acceptable on servers that
have to do lots of other processing. If you have fxp(4) or txp(4)
hardwares give them try first and see what's the difference with
systat(1). Pushing the hardware to the limit by sending/receiving
64 bytes frames with netperf/iperf also would be good way to see
how well the controller works under extreme loads.
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: is RTL8139 THAT bad?

by Wojciech Puchar-5 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

>>
>> But - this computer can do memcpy at 80MB/s, so at 3.5MB/s it should be 5%
>> CPU for memcpy, and one interrupt per one packet (2500 packets/s).
>>
>> Is something more that make it consume >50% CPU?
>
> Accessing the on-card memory through PCI is guaranteed to be
> slower than the main memory, and depending on the particular
> card it may be much slower.

as comment say - this card do DMA to main memory then computer must copy.

so PCI speed needs just to be faster than 100Mbit/s, certainly is
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: is RTL8139 THAT bad?

by Wojciech Puchar-5 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

>>
>> Why it's THAT bad?
>>
>
> Because CPU always have to copy frames to/from the controller.

comment says card do DMA. just then it has to copy but within main memory
not PCI.

> These CPU cycles could have been used in other task to give more
> performance such as SSH encryption/decryption, checksum computation
> etc.
>
>> 3.5MB/s is less that 2500 packets/second. 50% at 200Mhz means 100000000
>> cycles spend on interrupt service, which is 40000 CPU cycles per packet.
>>
>
> That depends on your application. It would be ok for normal desktop
> PCs with fast CPU but it wouldn't be acceptable on servers that
> have to do lots of other processing. If you have fxp(4) or txp(4)

i know all this, but i'm asking why processing single interrupt takes
40000 CPU cycles.
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: is RTL8139 THAT bad?

by Peter Jeremy :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 2009-Jun-22 13:12:08 +0200, Wojciech Puchar <wojtek@...> wrote:
>i know all this, but i'm asking why processing single interrupt takes
>40000 CPU cycles.

All I can suggest is that you browse the sources and see what the
rl(4) interrupt handler does.  If you want to dig further, hwpmc(4)
may give you further insights.

--
Peter Jeremy


attachment0 (203 bytes) Download Attachment

Parent Message unknown Re: is RTL8139 THAT bad?

by EforeZZ :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

>i have pentium 200 with that card. doing ftp from other machine, getting
>3.5MB/s (HDD can 10MB/s, DMA) having 45%-55% interrupt load.

I had the same probelm. I rebuilt the kernel with the POLLING option
set to ON and turned on polling for all network interfaces. It helped
much :)

Best regards,
EforeZZ
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."