On Fri, 18 Oct 2002, Kelly Yancey wrote:

>   Hmm.  Might that explain the abysmal performance of the em driver with
> packets smaller than 333 bytes?
>
>   Kelly
>

  This is just a follow-up to report that thanks to Luigi and Prafulla we
were able to track down the cause of the problems I was seeing with the em
driver/hardware.  In our test environment we had left the IP packet queue
(net.inet.ip.intr_queue_maxlen) at its default value of 50 which, when using
the em card, was overflowing causing the dropped packets.  While it is
curious that it was not overflowing using the bge card, clearly 50 packets
is a restrictive maximum queue size for any decent amount of traffic.

  Below are some of the results from our testing.  First, a note about the
methodology: traffic was generated using 7 10/100 ethernet ports of a
SmartBits 600 (each port was set to generate 14.25Mbps of traffic for a
aggregate of 99.75Mbps, slightly higher than the theoretical maximum
wirespeed).  The traffic was then VLAN tagged before being passed to a
1.8Ghz Pentium 4 running FreeBSD 4.5p19 where it was untagged and passed
back to the SmartBits.  The numbers quoted below are the actual amount of
traffic that was delivered back to the SmartBits.  The kernel involved
included a number of modifications proprietary to NTTMCL so the numbers are
going to differ from a stock kernel and I only present them for comparative
purposes between the different network configurations.  Also note that all
interfaces were configured for 100base-TX full-duplex.

                                      Frame Size
        NICs      queue  ipfw       64      128      192
        bge->fxp     50     0   79.708   97.325   98.124 Mbps
        bge->fxp   1000     0   80.172   97.325   98.124 Mbps
        em->fxp    1000     0   77.590   97.325   98.124 Mbps
        bge->fxp     50    32   39.097   97.325   98.124 Mbps
        bge->fxp   1000    32   62.011   97.325   98.124 Mbps
        em->fxp    1000    32   63.651   97.325   98.124 Mbps

  The numbers in the ipfw column are the number of non-matching rules in the
ruleset before an "allow all from any to any" rule.

  Kelly

--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} -- [EMAIL PROTECTED]
"And say, finally, whether peace is best preserved by giving energy to the
 government or information to the people.  This last is the most certain and
 the most legitimate engine of government."
        -- Thomas Jefferson to James Madison, 1787.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Reply via email to