Re: Abysmal re(4) performance under 8.1-STABLE (mid-August)
On Mon, 15.11.2010 at 18:03:25 -0800, Pyun YongHyeon wrote: > On Sun, Nov 14, 2010 at 10:41:03AM +0100, Ulrich Sp??rlein wrote: > > On Mon, 08.11.2010 at 22:41:12 +0100, Ulrich Sp??rlein wrote: > > > On Sun, 07.11.2010 at 15:10:20 -0800, Pyun YongHyeon wrote: > > > > On Sun, Nov 07, 2010 at 12:24:21PM +0100, Ulrich Sp??rlein wrote: > > > > > On Sat, 06.11.2010 at 23:19:33 -0700, Pyun YongHyeon wrote: > > > > > > On Sat, Nov 6, 2010 at 2:37 AM, Ulrich Sp??rlein > > > > > > wrote: > > > > > > > Hello Pyun, > > > > > > > > > > > > > > On this new server, I cannot get more than ~280kByte/s > > > > > > > up/downstream out of > > > > > > > re(4) without any tweaking. > > > > > > > > > > > > > > re0: flags=8843 metric 0 > > > > > > > mtu 1500 > > > > > > > ?? ?? ?? > > > > > > > ??options=389b > > > > > > > ?? ?? ?? ??ether 00:21:85:63:74:34 > > > > > > > ?? ?? ?? ??inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 > > > > > > > scopeid 0x1 > > > > > > > ?? ?? ?? ??inet 46.4.12.147 netmask 0xffc0 broadcast > > > > > > > 46.4.12.191 > > > > > > > ?? ?? ?? ??nd6 options=3 > > > > > > > ?? ?? ?? ??media: Ethernet autoselect (100baseTX ) > > > > > > > ?? ?? ?? ??status: active > > > > > > > > > > > > > > > > > > > It seems the link was resolved to half-duplex. Does link partner > > > > > > also agree on the resolved speed/duplex? > > > > > > > > > > As this is a dedicated server in a colo hundreds of km away, I have no > > > > > means to check this easily. Especially I cannot change the setting > > > > > from > > > > > auto-neg. Btw, linux will show a negotiated 100/full link via > > > > > mii-tool. > > > > > > > > > > > > > I guess you can contact network administrator of the data center to > > > > check the switch configuration. IEEE 802.3 says if link parter use > > > > forced full-duplex media and you use auto media, the resolved > > > > duplex is half-duplex by definition. I think RealTek may have > > > > followed the standard. There is no reason to use manual media > > > > configuration unless your link partner is severely broken with > > > > auto-negotiation. > > > > > > > > Due to silicon bug of RealTek PHYs, rgephy(4) always use > > > > auto-negotiation so manual media configuration is a kind of > > > > auto-negotiation with limited set of available media advertising. > > > > I don't know how Linux solve the silicon bug though. One of magic > > > > DSP fixups might fix the issue, the DSP fixups vendor released is > > > > not under BSD license and does not say more detailed information > > > > for the code. > > > > > > Luckily the provider switch me to another switch that is set to > > > autoneg, instead of hardcoded to 100/full. re(4) now happily transfers > > > with reasonable speeds, ie. 11MByte/s. > > > > Alas, spoken too soon. While the throughput is now up to speed, I have > > severe problems with packet loss on this device. Again, the linux rescue > > system works fine, but under a recent -STABLE (including your latest > > MFCs) I get an average packet loss of 10-20%. But it is not constant, > > meaning every 5th packet or so, but instead will drop no packets for > > minutes-hours and then blackout for 1-5 min straight (these times are > > estimates, I haven't used a stop watch or anything.) > > > > At first, putting the card into promisc mode seemed to alleviate the > > issue, but the average ping packet loss during the last 10h was again up > > to 10%. Due to the "blackout" nature, this drops all TCP sessions and is > > really annoying. > > > > Do you have any other ideas that I could try? Or should I simply switch > > to a different hardware altogether? > > > > Could you try latest re(4) in HEAD? It has a new feature that > displays hardware MAC counters and it contains a couple of PHY > access enhancements. You would get the MAC counters on console with > "sysctl dev.re.0.stats=1". And let me know how many frames were > dropped. This is very weird, I managed to narrow it down to IPv4 forwarding, that is making the box unreachable for certain periods. One the server, I did: # sysctl net.inet.ip.forwarding=1; sleep 7200; sysctl net.inet.ip.forwarding=0 And on a client, I did: # ping -c 7200 ... 7200 packets transmitted, 5269 packets received, 26.8% packet loss round-trip min/avg/max/stddev = 5.386/23.155/64.633/21.594 ms I have a couple of virtual interfaces, gif, tun (openvpn) and pf(4) running on that box, but no routing daemons or anything. I also had an IPv6 ping running simultaneously (using net/mtr) and this is showing me ~0% packet loss over IPv6 (net.inet6.ip6.forwarding is set, but this does not exhibit the problem). Now I had this very same software setup running on another box without any blackouts, so I'm wondering what the re(4) hardware would have to do with IPv4 forwarding. Next up, I'm going to test if net.inet.ip.fastforwarding exhibits the same blackouts. I will also take down all other interfaces, pf and openvpn and see if I can make any sense of this.
Re: Abysmal re(4) performance under 8.1-STABLE (mid-August)
On Sun, Nov 14, 2010 at 10:41:03AM +0100, Ulrich Sp??rlein wrote: > On Mon, 08.11.2010 at 22:41:12 +0100, Ulrich Sp??rlein wrote: > > On Sun, 07.11.2010 at 15:10:20 -0800, Pyun YongHyeon wrote: > > > On Sun, Nov 07, 2010 at 12:24:21PM +0100, Ulrich Sp??rlein wrote: > > > > On Sat, 06.11.2010 at 23:19:33 -0700, Pyun YongHyeon wrote: > > > > > On Sat, Nov 6, 2010 at 2:37 AM, Ulrich Sp??rlein > > > > > wrote: > > > > > > Hello Pyun, > > > > > > > > > > > > On this new server, I cannot get more than ~280kByte/s > > > > > > up/downstream out of > > > > > > re(4) without any tweaking. > > > > > > > > > > > > re0: flags=8843 metric 0 > > > > > > mtu 1500 > > > > > > ?? ?? ?? > > > > > > ??options=389b > > > > > > ?? ?? ?? ??ether 00:21:85:63:74:34 > > > > > > ?? ?? ?? ??inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid > > > > > > 0x1 > > > > > > ?? ?? ?? ??inet 46.4.12.147 netmask 0xffc0 broadcast 46.4.12.191 > > > > > > ?? ?? ?? ??nd6 options=3 > > > > > > ?? ?? ?? ??media: Ethernet autoselect (100baseTX ) > > > > > > ?? ?? ?? ??status: active > > > > > > > > > > > > > > > > It seems the link was resolved to half-duplex. Does link partner > > > > > also agree on the resolved speed/duplex? > > > > > > > > As this is a dedicated server in a colo hundreds of km away, I have no > > > > means to check this easily. Especially I cannot change the setting from > > > > auto-neg. Btw, linux will show a negotiated 100/full link via mii-tool. > > > > > > > > > > I guess you can contact network administrator of the data center to > > > check the switch configuration. IEEE 802.3 says if link parter use > > > forced full-duplex media and you use auto media, the resolved > > > duplex is half-duplex by definition. I think RealTek may have > > > followed the standard. There is no reason to use manual media > > > configuration unless your link partner is severely broken with > > > auto-negotiation. > > > > > > Due to silicon bug of RealTek PHYs, rgephy(4) always use > > > auto-negotiation so manual media configuration is a kind of > > > auto-negotiation with limited set of available media advertising. > > > I don't know how Linux solve the silicon bug though. One of magic > > > DSP fixups might fix the issue, the DSP fixups vendor released is > > > not under BSD license and does not say more detailed information > > > for the code. > > > > Luckily the provider switch me to another switch that is set to > > autoneg, instead of hardcoded to 100/full. re(4) now happily transfers > > with reasonable speeds, ie. 11MByte/s. > > Alas, spoken too soon. While the throughput is now up to speed, I have > severe problems with packet loss on this device. Again, the linux rescue > system works fine, but under a recent -STABLE (including your latest > MFCs) I get an average packet loss of 10-20%. But it is not constant, > meaning every 5th packet or so, but instead will drop no packets for > minutes-hours and then blackout for 1-5 min straight (these times are > estimates, I haven't used a stop watch or anything.) > > At first, putting the card into promisc mode seemed to alleviate the > issue, but the average ping packet loss during the last 10h was again up > to 10%. Due to the "blackout" nature, this drops all TCP sessions and is > really annoying. > > Do you have any other ideas that I could try? Or should I simply switch > to a different hardware altogether? > Could you try latest re(4) in HEAD? It has a new feature that displays hardware MAC counters and it contains a couple of PHY access enhancements. You would get the MAC counters on console with "sysctl dev.re.0.stats=1". And let me know how many frames were dropped. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Abysmal re(4) performance under 8.1-STABLE (mid-August)
On Mon, 08.11.2010 at 22:41:12 +0100, Ulrich Spörlein wrote: > On Sun, 07.11.2010 at 15:10:20 -0800, Pyun YongHyeon wrote: > > On Sun, Nov 07, 2010 at 12:24:21PM +0100, Ulrich Sp??rlein wrote: > > > On Sat, 06.11.2010 at 23:19:33 -0700, Pyun YongHyeon wrote: > > > > On Sat, Nov 6, 2010 at 2:37 AM, Ulrich Sp??rlein > > > > wrote: > > > > > Hello Pyun, > > > > > > > > > > On this new server, I cannot get more than ~280kByte/s up/downstream > > > > > out of > > > > > re(4) without any tweaking. > > > > > > > > > > re0: flags=8843 metric 0 mtu > > > > > 1500 > > > > > ?? ?? ?? > > > > > ??options=389b > > > > > ?? ?? ?? ??ether 00:21:85:63:74:34 > > > > > ?? ?? ?? ??inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > > > > > ?? ?? ?? ??inet 46.4.12.147 netmask 0xffc0 broadcast 46.4.12.191 > > > > > ?? ?? ?? ??nd6 options=3 > > > > > ?? ?? ?? ??media: Ethernet autoselect (100baseTX ) > > > > > ?? ?? ?? ??status: active > > > > > > > > > > > > > It seems the link was resolved to half-duplex. Does link partner > > > > also agree on the resolved speed/duplex? > > > > > > As this is a dedicated server in a colo hundreds of km away, I have no > > > means to check this easily. Especially I cannot change the setting from > > > auto-neg. Btw, linux will show a negotiated 100/full link via mii-tool. > > > > > > > I guess you can contact network administrator of the data center to > > check the switch configuration. IEEE 802.3 says if link parter use > > forced full-duplex media and you use auto media, the resolved > > duplex is half-duplex by definition. I think RealTek may have > > followed the standard. There is no reason to use manual media > > configuration unless your link partner is severely broken with > > auto-negotiation. > > > > Due to silicon bug of RealTek PHYs, rgephy(4) always use > > auto-negotiation so manual media configuration is a kind of > > auto-negotiation with limited set of available media advertising. > > I don't know how Linux solve the silicon bug though. One of magic > > DSP fixups might fix the issue, the DSP fixups vendor released is > > not under BSD license and does not say more detailed information > > for the code. > > Luckily the provider switch me to another switch that is set to > autoneg, instead of hardcoded to 100/full. re(4) now happily transfers > with reasonable speeds, ie. 11MByte/s. Alas, spoken too soon. While the throughput is now up to speed, I have severe problems with packet loss on this device. Again, the linux rescue system works fine, but under a recent -STABLE (including your latest MFCs) I get an average packet loss of 10-20%. But it is not constant, meaning every 5th packet or so, but instead will drop no packets for minutes-hours and then blackout for 1-5 min straight (these times are estimates, I haven't used a stop watch or anything.) At first, putting the card into promisc mode seemed to alleviate the issue, but the average ping packet loss during the last 10h was again up to 10%. Due to the "blackout" nature, this drops all TCP sessions and is really annoying. Do you have any other ideas that I could try? Or should I simply switch to a different hardware altogether? Regards, Uli ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Abysmal re(4) performance under 8.1-STABLE (mid-August)
On Sun, 07.11.2010 at 15:10:20 -0800, Pyun YongHyeon wrote: > On Sun, Nov 07, 2010 at 12:24:21PM +0100, Ulrich Sp??rlein wrote: > > On Sat, 06.11.2010 at 23:19:33 -0700, Pyun YongHyeon wrote: > > > On Sat, Nov 6, 2010 at 2:37 AM, Ulrich Sp??rlein > > > wrote: > > > > Hello Pyun, > > > > > > > > On this new server, I cannot get more than ~280kByte/s up/downstream > > > > out of > > > > re(4) without any tweaking. > > > > > > > > re0: flags=8843 metric 0 mtu > > > > 1500 > > > > ?? ?? ?? > > > > ??options=389b > > > > ?? ?? ?? ??ether 00:21:85:63:74:34 > > > > ?? ?? ?? ??inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > > > > ?? ?? ?? ??inet 46.4.12.147 netmask 0xffc0 broadcast 46.4.12.191 > > > > ?? ?? ?? ??nd6 options=3 > > > > ?? ?? ?? ??media: Ethernet autoselect (100baseTX ) > > > > ?? ?? ?? ??status: active > > > > > > > > > > It seems the link was resolved to half-duplex. Does link partner > > > also agree on the resolved speed/duplex? > > > > As this is a dedicated server in a colo hundreds of km away, I have no > > means to check this easily. Especially I cannot change the setting from > > auto-neg. Btw, linux will show a negotiated 100/full link via mii-tool. > > > > I guess you can contact network administrator of the data center to > check the switch configuration. IEEE 802.3 says if link parter use > forced full-duplex media and you use auto media, the resolved > duplex is half-duplex by definition. I think RealTek may have > followed the standard. There is no reason to use manual media > configuration unless your link partner is severely broken with > auto-negotiation. > > Due to silicon bug of RealTek PHYs, rgephy(4) always use > auto-negotiation so manual media configuration is a kind of > auto-negotiation with limited set of available media advertising. > I don't know how Linux solve the silicon bug though. One of magic > DSP fixups might fix the issue, the DSP fixups vendor released is > not under BSD license and does not say more detailed information > for the code. Luckily the provider switch me to another switch that is set to autoneg, instead of hardcoded to 100/full. re(4) now happily transfers with reasonable speeds, ie. 11MByte/s. Thanks! Uli ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Abysmal re(4) performance under 8.1-STABLE (mid-August)
On Sun, Nov 07, 2010 at 12:24:21PM +0100, Ulrich Sp??rlein wrote: > On Sat, 06.11.2010 at 23:19:33 -0700, Pyun YongHyeon wrote: > > On Sat, Nov 6, 2010 at 2:37 AM, Ulrich Sp??rlein wrote: > > > Hello Pyun, > > > > > > On this new server, I cannot get more than ~280kByte/s up/downstream out > > > of > > > re(4) without any tweaking. > > > > > > re0: flags=8843 metric 0 mtu 1500 > > > ?? ?? ?? > > > ??options=389b > > > ?? ?? ?? ??ether 00:21:85:63:74:34 > > > ?? ?? ?? ??inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > > > ?? ?? ?? ??inet 46.4.12.147 netmask 0xffc0 broadcast 46.4.12.191 > > > ?? ?? ?? ??nd6 options=3 > > > ?? ?? ?? ??media: Ethernet autoselect (100baseTX ) > > > ?? ?? ?? ??status: active > > > > > > > It seems the link was resolved to half-duplex. Does link partner > > also agree on the resolved speed/duplex? > > As this is a dedicated server in a colo hundreds of km away, I have no > means to check this easily. Especially I cannot change the setting from > auto-neg. Btw, linux will show a negotiated 100/full link via mii-tool. > I guess you can contact network administrator of the data center to check the switch configuration. IEEE 802.3 says if link parter use forced full-duplex media and you use auto media, the resolved duplex is half-duplex by definition. I think RealTek may have followed the standard. There is no reason to use manual media configuration unless your link partner is severely broken with auto-negotiation. Due to silicon bug of RealTek PHYs, rgephy(4) always use auto-negotiation so manual media configuration is a kind of auto-negotiation with limited set of available media advertising. I don't know how Linux solve the silicon bug though. One of magic DSP fixups might fix the issue, the DSP fixups vendor released is not under BSD license and does not say more detailed information for the code. > > > # ifconfig re0 > > > re0: flags=8843 metric 0 mtu 1500 > > > ?? ?? ?? ??options=88 > > > ?? ?? ?? ??ether 00:21:85:63:74:34 > > > ?? ?? ?? ??inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > > > ?? ?? ?? ??inet 46.4.12.147 netmask 0xffc0 broadcast 46.4.12.191 > > > ?? ?? ?? ??nd6 options=3 > > > ?? ?? ?? ??media: Ethernet 100baseTX (100baseTX > > > ) > > > ?? ?? ?? ??status: active > > > > > > > This time, it seems you used forced media configuration > > instead of auto. It still shows duplex mismatch so it's > > normal to see poor performance. What makes me wonder > > is why you have duplex mismatch? > > Did you use forced media configuration on link partner? > > What happens when you use different switch? > > Sadly, none of these options are available to me :/ > But even 100/half should give more than enough performance, right? > No, with half-duplex link, you can't send frames while RX is in progress. The reverse is also true for half-duplex link. The more severe problem is your link partner think it established full-duplex link so it does not care about possible collisions. Either change your link partner's media configuration to half-duplex or auto. auto is preferred one, of course. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Abysmal re(4) performance under 8.1-STABLE (mid-August)
On Sun, Nov 07, 2010 at 12:24:21PM +0100, Ulrich Spörlein wrote: > On Sat, 06.11.2010 at 23:19:33 -0700, Pyun YongHyeon wrote: > > On Sat, Nov 6, 2010 at 2:37 AM, Ulrich Spörlein wrote: > > > Hello Pyun, > > > > > > On this new server, I cannot get more than ~280kByte/s up/downstream out > > > of > > > re(4) without any tweaking. > > > > > > re0: flags=8843 metric 0 mtu 1500 > > > > > > options=389b > > > ether 00:21:85:63:74:34 > > > inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > > > inet 46.4.12.147 netmask 0xffc0 broadcast 46.4.12.191 > > > nd6 options=3 > > > media: Ethernet autoselect (100baseTX ) > > > status: active > > > > > > > It seems the link was resolved to half-duplex. Does link partner > > also agree on the resolved speed/duplex? > > As this is a dedicated server in a colo hundreds of km away, I have no > means to check this easily. Especially I cannot change the setting from > auto-neg. Btw, linux will show a negotiated 100/full link via mii-tool. you can always ask the guys responsible for network infrastructure > > > # ifconfig re0 > > > re0: flags=8843 metric 0 mtu 1500 > > > options=88 > > > ether 00:21:85:63:74:34 > > > inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > > > inet 46.4.12.147 netmask 0xffc0 broadcast 46.4.12.191 > > > nd6 options=3 > > > media: Ethernet 100baseTX (100baseTX ) > > > status: active > > > > > > > This time, it seems you used forced media configuration > > instead of auto. It still shows duplex mismatch so it's > > normal to see poor performance. What makes me wonder > > is why you have duplex mismatch? > > Did you use forced media configuration on link partner? > > What happens when you use different switch? > > Sadly, none of these options are available to me :/ > But even 100/half should give more than enough performance, right? no, not if the other end is 100/full. Duplex mismatch usually gives around 100-200 kB/s. I've experienced this (around 75kB/s), setting speed/duplex manually fixed the problem. > Uli > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" Buki -- PGP public key: http://dev.null.cz/buki.asc /"\ \ / ASCII Ribbon Campaign X Against HTML & Outlook Mail / \ http://www.thebackrow.net pgpeRB7KovI3p.pgp Description: PGP signature
Re: Abysmal re(4) performance under 8.1-STABLE (mid-August)
On Sat, 06.11.2010 at 23:19:33 -0700, Pyun YongHyeon wrote: > On Sat, Nov 6, 2010 at 2:37 AM, Ulrich Spörlein wrote: > > Hello Pyun, > > > > On this new server, I cannot get more than ~280kByte/s up/downstream out of > > re(4) without any tweaking. > > > > re0: flags=8843 metric 0 mtu 1500 > > > > options=389b > > ether 00:21:85:63:74:34 > > inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > > inet 46.4.12.147 netmask 0xffc0 broadcast 46.4.12.191 > > nd6 options=3 > > media: Ethernet autoselect (100baseTX ) > > status: active > > > > It seems the link was resolved to half-duplex. Does link partner > also agree on the resolved speed/duplex? As this is a dedicated server in a colo hundreds of km away, I have no means to check this easily. Especially I cannot change the setting from auto-neg. Btw, linux will show a negotiated 100/full link via mii-tool. > > # ifconfig re0 > > re0: flags=8843 metric 0 mtu 1500 > > options=88 > > ether 00:21:85:63:74:34 > > inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > > inet 46.4.12.147 netmask 0xffc0 broadcast 46.4.12.191 > > nd6 options=3 > > media: Ethernet 100baseTX (100baseTX ) > > status: active > > > > This time, it seems you used forced media configuration > instead of auto. It still shows duplex mismatch so it's > normal to see poor performance. What makes me wonder > is why you have duplex mismatch? > Did you use forced media configuration on link partner? > What happens when you use different switch? Sadly, none of these options are available to me :/ But even 100/half should give more than enough performance, right? Uli ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Abysmal re(4) performance under 8.1-STABLE (mid-August)
On Sat, Nov 6, 2010 at 2:37 AM, Ulrich Spörlein wrote: > Hello Pyun, > > On this new server, I cannot get more than ~280kByte/s up/downstream out of > re(4) without any tweaking. > > re0: flags=8843 metric 0 mtu 1500 > > options=389b > ether 00:21:85:63:74:34 > inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > inet 46.4.12.147 netmask 0xffc0 broadcast 46.4.12.191 > nd6 options=3 > media: Ethernet autoselect (100baseTX ) > status: active > It seems the link was resolved to half-duplex. Does link partner also agree on the resolved speed/duplex? > r...@pci0:2:0:0: class=0x02 card=0x368c1462 chip=0x816810ec rev=0x01 > hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' > class = network > subclass = ethernet > > re0: port > 0xd800-0xd8ff mem 0xfeaff000-0xfeaf irq 19 at device 0.0 on pci2 > re0: Using 1 MSI messages > re0: Chip rev. 0x3800 > re0: MAC rev. 0x > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > re0: Ethernet address: 00:21:85:63:74:34 > re0: [FILTER] > > > It's interesting to note, that re0 only negotiates half-duplex, where > linux will negotiate full-duplex (and gets ~10MByte/s as expected). > > Next, I disabled almost all options, except that I cannot disable > VLAN_MTU, VLAN_HWCSUM. I also forced the adapter into full-duplex. > > # ifconfig re0 -vlanmtu > # ifconfig re0 -vlanhwcsum > ifconfig: -vlanhwcsum: bad value I'm sure this has nothing to do that this issue. If you want to disable checksum offloading of VLAN interface, use vlan interface instead of parent interface of the VLAN interface(i.e. ifconfig vlan0 -txcsum -rxcsum). And you can't disable VLAN_MTU on re(4). There is no reason to disable supporting VLAN oversized frames. > # ifconfig re0 > re0: flags=8843 metric 0 mtu 1500 > options=88 > ether 00:21:85:63:74:34 > inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > inet 46.4.12.147 netmask 0xffc0 broadcast 46.4.12.191 > nd6 options=3 > media: Ethernet 100baseTX (100baseTX ) > status: active > This time, it seems you used forced media configuration instead of auto. It still shows duplex mismatch so it's normal to see poor performance. What makes me wonder is why you have duplex mismatch? Did you use forced media configuration on link partner? What happens when you use different switch? > If I then immediately start the test-download, I get a ~2MByte/s spike, > which quickly returns to something around 250kByte/s. > > Booting with > hw.pci.enable_msix=0 > hw.pci.enable_msi=0 > > I can get almost up to 400kByte/s, but this may be coincidence. > > So this is usually as far as it gets: > > re0 in 190.504 KB/s 246.136 KB/s 66.709 MB > out 10.290 KB/s 12.985 KB/s 6.076 MB > > But then I ran tcpdump in another session, and it looks like the ssh traffic > on > the upstream of the interface will make the downloads running in another > window > go faster: > > re0 in 805.961 KB/s 1.577 MB/s 116.523 MB > out 222.940 KB/s 502.045 KB/s 19.267 MB > > Any ideas? > > Uli > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Abysmal re(4) performance under 8.1-STABLE (mid-August)
Am 06.11.2010 um 10:37 schrieb Ulrich Spörlein: > On this new server, I cannot get more than ~280kByte/s up/downstream out of > re(4) without any tweaking. > > re0: flags=8843 metric 0 mtu 1500 > > options=389b >ether 00:21:85:63:74:34 >inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 >inet 46.4.12.147 netmask 0xffc0 broadcast 46.4.12.191 >nd6 options=3 >media: Ethernet autoselect (100baseTX ) >status: active AOL: r...@pci0:1:0:0:class=0x02 card=0x82c61043 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' class = network subclass = ethernet re0: port 0xd800-0xd8ff mem 0xfdfff000-0xfdff,0xfdfe-0xfdfe irq 18 at device 0.0 on pci1 re0: Using 1 MSI messages re0: Chip rev. 0x3c00 re0: MAC rev. 0x0040 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:26:18:d5:2c:23 re0: [FILTER] I believe that it was working properly some months ago, but reading Rick's thread over on -current I checked and transfer over NFS seems to be limited to a couple hundred KB as well. Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Abysmal re(4) performance under 8.1-STABLE (mid-August)
> Hello Pyun,
>
> On this new server, I cannot get more than ~280kByte/s up/downstream
>
I have been working on a similar problem with Pyun's help. Not yet
resolved and no idea if it is the same problem, but see below...
>
> Any ideas?
I have been chasing a similar problem w.r.t. re(4) { slow NFS reads on
-current }. You could try building a kernel with "options DEVICE_POLLING"
and see if that helps. If that makes it work faster, then it might be the
same issue.
rick
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Abysmal re(4) performance under 8.1-STABLE (mid-August)
On Sat, 06.11.2010 at 10:37:00 +0100, Ulrich Spörlein wrote: > Hello Pyun, > > On this new server, I cannot get more than ~280kByte/s up/downstream out of > re(4) without any tweaking. > > re0: flags=8843 metric 0 mtu 1500 > > options=389b > ether 00:21:85:63:74:34 > inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > inet 46.4.12.147 netmask 0xffc0 broadcast 46.4.12.191 > nd6 options=3 > media: Ethernet autoselect (100baseTX ) > status: active > > r...@pci0:2:0:0: class=0x02 card=0x368c1462 chip=0x816810ec rev=0x01 > hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' > class = network > subclass = ethernet One more datapoint, I know that this (newer) revision r...@pci0:6:0:0: class=0x02 card=0x75221462 chip=0x816810ec rev=0x02 hdr=0x00 is working just fine in another system/board. > re0: port > 0xd800-0xd8ff mem 0xfeaff000-0xfeaf irq 19 at device 0.0 on pci2 > re0: Using 1 MSI messages > re0: Chip rev. 0x3800 > re0: MAC rev. 0x > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > re0: Ethernet address: 00:21:85:63:74:34 > re0: [FILTER] > > > It's interesting to note, that re0 only negotiates half-duplex, where > linux will negotiate full-duplex (and gets ~10MByte/s as expected). > > Next, I disabled almost all options, except that I cannot disable > VLAN_MTU, VLAN_HWCSUM. I also forced the adapter into full-duplex. > > # ifconfig re0 -vlanmtu > # ifconfig re0 -vlanhwcsum > ifconfig: -vlanhwcsum: bad value > # ifconfig re0 > re0: flags=8843 metric 0 mtu 1500 > options=88 > ether 00:21:85:63:74:34 > inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > inet 46.4.12.147 netmask 0xffc0 broadcast 46.4.12.191 > nd6 options=3 > media: Ethernet 100baseTX (100baseTX ) > status: active > > If I then immediately start the test-download, I get a ~2MByte/s spike, > which quickly returns to something around 250kByte/s. > > Booting with > hw.pci.enable_msix=0 > hw.pci.enable_msi=0 > > I can get almost up to 400kByte/s, but this may be coincidence. > > So this is usually as far as it gets: > > re0 in190.504 KB/s246.136 KB/s 66.709 MB > out10.290 KB/s 12.985 KB/s6.076 MB > > But then I ran tcpdump in another session, and it looks like the ssh traffic > on > the upstream of the interface will make the downloads running in another > window > go faster: > > re0 in805.961 KB/s 1.577 MB/s 116.523 MB > out 222.940 KB/s502.045 KB/s 19.267 MB > > Any ideas? > > Uli > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
