7.1-PRERELEASE : bad network performance (nfe0)
rwatson at FreeBSD.org
Mon Sep 29 20:10:29 UTC 2008
On Mon, 29 Sep 2008, Arno J. Klaassen wrote:
> However, the "request/respones" tests are awfull for my notebook (test
> repeated on the notebook for the sake of conviction) :
Is it possible to rerun these tests with a 7.0 kernel of the same general
configuration? That would help us determine if it's a regression between 7.0
and 7.1, or perhaps a more general issue between 6.x and 7.x. I wouldn't
reject a hardware, driver, or general stack issue at this point as things are
still fairly unclear. If it's definitely between 7.0 and 7.1 that the problem
arises, trying a series of kernels spaced at, say, one month intervals in that
period would be quite helpful in narrowing down the source.
Robert N M Watson
University of Cambridge
> per sec
> 6-stable-x86 9801.58
> 7-stable-x64 137.61
> 7-stable-x64 89.35
> 7-stable-x64 102.29
> per sec
> 6-stable-x86 4520.98
> 7-stable-x64 7.00
> 7-stable-x64 8.10
> 7-stable-x64 18.49
> per sec
> 6-stable-x86 9473.20
> 7-stable-x64 9.60
> 7-stable-x64 0.90
> 7-stable-x64 0.10
> I can send you complete results if wanted.
>> Other possible cause of issue could be link speed/duplex mismatch
>> or excessive MAC control frames(e.g. pause frames). Does nfe(4)
>> agree on resolved speed/duplex with link partner?
> yes (1000baseTX <full-duplex>)
>> If they all agree on resolved speed/duplex, would you check number
>> of pause frames sent/received from link partner? Even though MCP65
>> supports hardware MAC statistics for pause frames nfe(4) has no
>> support code yet so you may have to resort to managed switch that
>> can show Tx/Rx statistics of each port.
> aargh; I do have a Netgear GS724TS around where I can connect it to.
> This thing should be manageable, but give me some time to
> find out how ....
> Thanx, Arno
> freebsd-stable at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
More information about the freebsd-stable