RE: em driver problem on vmware
Hi Rick, The FreeBSD -current works fine for me with the newest em(4) under the VMware player. Kevin On Friday, 2010-10-29 at 19:22 -0700, Ricky Charlet wrote: Thanks Jack, The failure is that ifconfig is unaware of em0. My em0 is not configured, so link partners are also unaware of it. ifconfig em0 ifconfig: interface em0 does not exist and you already have my dmes stuff on em0 (which I am now up to agreeing looks positive and would not indicate a problem) My amalgamated file is a private combination of some 8.1, some 9.0, some stuff a cohort did. We have been motivated to 'upgrade' from e1000 in 8.0 to a newer/modified e1000 because of our desire to incorporate the altq patches. For the curious and the diligent, the e1000/if_em.c file I am using is attached. Ricky From: Jack Vogel [mailto:jfvo...@gmail.com] Sent: Friday, October 29, 2010 7:13 PM To: Ricky Charlet Cc: freebsd-net@freebsd.org Subject: Re: em driver problem on vmware I remember seeing the same thing when running a FreeBSD guest on Linux/KVM, its informational, the code will enable said bits right after it says that. So, the focus should be on the data, you are saying the delivered driver in 8.0 out of the box works and which driver exactly are you trying to use, my last checked in? More on the failure, does it ping, does its link partner see anything, etc, etc.. Jack On Fri, Oct 29, 2010 at 6:27 PM, Ricky Charlet rchar...@adaranet.commailto:rchar...@adaranet.com wrote: FYI, That dmesg output I get from my franken-driver on vmware is exactly the same output I get from the *working* bsd80Release on vmware: cut [r...@npx7511 /usr/src/sys/dev/e1000]# dmesg | grep em0 em0: Intel(R) PRO/1000 Network Connection 6.9.14 port 0x2000-0x203f mem 0xd894-0xd895,0xd890-0xd890 irq 18 at device 0.0 on pci2 em0: Memory Access and/or Bus Master bits were not set! em0: [FILTER] em0: Ethernet address: 00:0c:29:57:d7:7f ---paste--- So I don't think the clue is hiding in dmesg. --- Ricky Charlet Adara Networks USA 408-433-4942 -Original Message- From: owner-freebsd-...@freebsd.orgmailto:owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.orgmailto:owner-freebsd-...@freebsd.org] On Behalf Of Ricky Charlet Sent: Friday, October 29, 2010 5:07 PM To: freebsd-net@freebsd.orgmailto:freebsd-net@freebsd.org Subject: em driver problem on vmware Howdy, I have freebsd80-release with an upgraded em0 driver from freebsd8.1 (and an appropriate touch of if_var.h). I'm running an amd64 on a vmware vm. And I see this in dmesg: cut- em0: Intel(R) PRO/1000 Network Connection 6.9.14 port 0x2000-203f mem 0xd894-0xd895, 0xd890-0xd890 irq 18 at device 0.0 on pci2 em0: Memory Access and/or Bus Master bits were not set em0: [FILTER] em0: Ethernet address: 00:0c:29:57:d7:7f paste Now, I certainly may have done something wrong with my code switch (just copied over the sys/dev/e1000 directory from 8.1 and defined drbr_needs_enqueue in if_var.h). I'll start double checking. But, on the other hand, has anyone seen the new em driver working/failing on a vmware vm? Thanks --- Ricky Charlet Adara Networks USA 408-433-4942 ___ freebsd-net@freebsd.orgmailto:freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.orgmailto:freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.orgmailto:freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.orgmailto:freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
RE: em driver problem on vmware
Hi Jack, My pciconf output is attached. I'm afraid I don't grok it and will need a hand to even let me know if this is good/not-good. Ricky From: Jack Vogel [mailto:jfvo...@gmail.com] Sent: Friday, October 29, 2010 10:07 PM To: Ricky Charlet Cc: Juli Mallett; freebsd-net@freebsd.org Subject: Re: em driver problem on vmware pciconf -l If you got a printf from the driver its VERY odd that it says the interface does not exist :) Jack On Fri, Oct 29, 2010 at 7:03 PM, Ricky Charlet rchar...@adaranet.commailto:rchar...@adaranet.com wrote: -Original Message- From: j...@clockworksquid.commailto:j...@clockworksquid.com [mailto:j...@clockworksquid.commailto:j...@clockworksquid.com] On Behalf Of Juli Mallett Sent: Friday, October 29, 2010 6:55 PM To: Ricky Charlet Cc: freebsd-net@freebsd.orgmailto:freebsd-net@freebsd.org Subject: Re: em driver problem on vmware On Fri, Oct 29, 2010 at 17:07, Ricky Charlet rchar...@adaranet.commailto:rchar...@adaranet.com wrote: Howdy, I have freebsd80-release with an upgraded em0 driver from freebsd8.1 (and an appropriate touch of if_var.h). I'm running an amd64 on a vmware vm. And I see this in dmesg: cut- em0: Intel(R) PRO/1000 Network Connection 6.9.14 port 0x2000-203f mem 0xd894-0xd895, 0xd890-0xd890 irq 18 at device 0.0 on pci2 em0: Memory Access and/or Bus Master bits were not set em0: [FILTER] em0: Ethernet address: 00:0c:29:57:d7:7f paste But, on the other hand, has anyone seen the new em driver working/failing on a vmware vm? Memory Access and/or Bus Master bits were not set is not a fatal error, it is correctable, indeed that is printed out when it is corrected; that is not something to worry about in and of itself as such, are you actually having a problem or just concerned because you saw that in dmesg? It is truly not working. I agree those lines in dmesg are good and indicate em0 is ready. but `ifconfig` does not see em0. --- Ricky Charlet Adara Networks USA 408-433-4942 ___ freebsd-net@freebsd.orgmailto:freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.orgmailto:freebsd-net-unsubscr...@freebsd.org hos...@pci0:0:0:0: class=0x06 card=0x197615ad chip=0x71908086 rev=0x01 hdr=0x00 pc...@pci0:0:1:0: class=0x060400 card=0x chip=0x71918086 rev=0x01 hdr=0x01 is...@pci0:0:7:0: class=0x060100 card=0x197615ad chip=0x71108086 rev=0x08 hdr=0x00 atap...@pci0:0:7:1: class=0x01018a card=0x197615ad chip=0x71118086 rev=0x01 hdr=0x00 no...@pci0:0:7:3: class=0x068000 card=0x197615ad chip=0x71138086 rev=0x08 hdr=0x00 no...@pci0:0:7:7: class=0x088000 card=0x074015ad chip=0x074015ad rev=0x10 hdr=0x00 vgap...@pci0:0:15:0:class=0x03 card=0x040515ad chip=0x040515ad rev=0x00 hdr=0x00 m...@pci0:0:16:0: class=0x01 card=0x197615ad chip=0x00301000 rev=0x01 hdr=0x00 pc...@pci0:0:17:0: class=0x060401 card=0x079015ad chip=0x079015ad rev=0x02 hdr=0x01 pc...@pci0:0:21:0: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 pc...@pci0:0:21:1: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 pc...@pci0:0:21:2: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 pc...@pci0:0:21:3: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 pc...@pci0:0:21:4: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 pc...@pci0:0:21:5: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 pc...@pci0:0:21:6: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 pci...@pci0:0:21:7: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 pci...@pci0:0:22:0: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 pci...@pci0:0:22:1: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 pci...@pci0:0:22:2: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 pci...@pci0:0:22:3: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 pci...@pci0:0:22:4: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 pci...@pci0:0:22:5: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 pci...@pci0:0:22:6: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 pci...@pci0:0:22:7: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 pci...@pci0:0:23:0: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 pci...@pci0:0:23:1: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 pci...@pci0:0:23:2: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 pci...@pci0:0:23:3: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01
Re: em driver problem on vmware
Uh, the emulated device in vmware is an OLD 82543 or something like that right? So, the e1000 driver in 8.1 is split into two parts, em and lem, its lem that has all the old pci support, so if you only pulled if_em then you dont have that code. Sounds like maybe you should just install 8.1 on your guest and avoid these kinds of problems. Regards, Jack On Fri, Oct 29, 2010 at 11:26 PM, Juli Mallett jmall...@freebsd.org wrote: dmesg is not cleared at boot; your devices are not being detected, they merely showed up in a previous boot. On Fri, Oct 29, 2010 at 23:13, Ricky Charlet rchar...@adaranet.com wrote: Hi Julie, My entire dmesg output is attached. With much appreciation Ricky -Original Message- From: j...@clockworksquid.com [mailto:j...@clockworksquid.com] On Behalf Of Juli Mallett Sent: Friday, October 29, 2010 8:01 PM To: Ricky Charlet Subject: Re: em driver problem on vmware Can you send me your full dmesg? You must be missing some relevant message, because the only circumstances under which you'd see the device attaching but then it wouldn't be present would also generate some error messages. On Fri, Oct 29, 2010 at 19:22, Ricky Charlet rchar...@adaranet.com wrote: Thanks Jack, The failure is that ifconfig is unaware of em0. My em0 is not configured, so link partners are also unaware of it. ifconfig em0 ifconfig: interface em0 does not exist and you already have my dmes stuff on em0 (which I am now up to agreeing looks positive and would not indicate a problem) My amalgamated file is a private combination of some 8.1, some 9.0, some stuff a cohort did. We have been motivated to 'upgrade' from e1000 in 8.0 to a newer/modified e1000 because of our desire to incorporate the altq patches. For the curious and the diligent, the e1000/if_em.c file I am using is attached. Ricky From: Jack Vogel [mailto:jfvo...@gmail.com] Sent: Friday, October 29, 2010 7:13 PM To: Ricky Charlet Cc: freebsd-net@freebsd.org Subject: Re: em driver problem on vmware I remember seeing the same thing when running a FreeBSD guest on Linux/KVM, its informational, the code will enable said bits right after it says that. So, the focus should be on the data, you are saying the delivered driver in 8.0 out of the box works and which driver exactly are you trying to use, my last checked in? More on the failure, does it ping, does its link partner see anything, etc, etc.. Jack On Fri, Oct 29, 2010 at 6:27 PM, Ricky Charlet rchar...@adaranet.commailto:rchar...@adaranet.com wrote: FYI, That dmesg output I get from my franken-driver on vmware is exactly the same output I get from the *working* bsd80Release on vmware: cut [r...@npx7511 /usr/src/sys/dev/e1000]# dmesg | grep em0 em0: Intel(R) PRO/1000 Network Connection 6.9.14 port 0x2000-0x203f mem 0xd894-0xd895,0xd890-0xd890 irq 18 at device 0.0 on pci2 em0: Memory Access and/or Bus Master bits were not set! em0: [FILTER] em0: Ethernet address: 00:0c:29:57:d7:7f ---paste--- So I don't think the clue is hiding in dmesg. --- Ricky Charlet Adara Networks USA 408-433-4942 -Original Message- From: owner-freebsd-...@freebsd.orgmailto:owner-freebsd- n...@freebsd.org [mailto:owner-freebsd-...@freebsd.orgmailto:owner- freebsd-net@freebsd.org] On Behalf Of Ricky Charlet Sent: Friday, October 29, 2010 5:07 PM To: freebsd-net@freebsd.orgmailto:freebsd-net@freebsd.org Subject: em driver problem on vmware Howdy, I have freebsd80-release with an upgraded em0 driver from freebsd8.1 (and an appropriate touch of if_var.h). I'm running an amd64 on a vmware vm. And I see this in dmesg: cut- em0: Intel(R) PRO/1000 Network Connection 6.9.14 port 0x2000-203f mem 0xd894-0xd895, 0xd890-0xd890 irq 18 at device 0.0 on pci2 em0: Memory Access and/or Bus Master bits were not set em0: [FILTER] em0: Ethernet address: 00:0c:29:57:d7:7f paste Now, I certainly may have done something wrong with my code switch (just copied over the sys/dev/e1000 directory from 8.1 and defined drbr_needs_enqueue in if_var.h). I'll start double checking. But, on the other hand, has anyone seen the new em driver working/failing on a vmware vm? Thanks --- Ricky Charlet Adara Networks USA 408-433-4942 ___ freebsd-net@freebsd.orgmailto:freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net- unsubscr...@freebsd.orgmailto:freebsd-net-unsubscr...@freebsd.org
Re: Polling slows down bandwidth
Hi, On 29/10/2010 18:23, Chuck Swiger wrote: On Oct 28, 2010, at 11:39 PM, Коньков Евгений wrote: so using polling on gigabit NICs is a bottle neck? and is cause of low performance, is not? Simple answer is yes. It should be possible that you could tune polling to get similar performance, or at least better performance than you see now, but the additional hardware capabilities of gigabit NICs are likely to outperform polling mode, just as polling mode can generally outperform old 100MBs ethernet NICs. I have been using polling for a long time with em and fxp interfaces on 6.2 and 4.9 boxes that are working as routers. I've been doing testing with FreeBSD 8 and em interfaces recently, and my experience agrees with Chuck's statement - that polling makes things worse when you use new (anything in the last 2 or 3 years) hardware with good quality gigabit ethernet interfaces. I've only really worked with bge and em but they have good high performance without polling in 8.0 and 8.1 Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
How to enable/disable flow control on em(4)?
Hellow, How do I enable/disable flow control on em driver just like I do on with igb hw.igb.fc_setting? If it can't be done via settings, is there any change I can on driver code to get this flag off? -- === Eduardo Meyer pessoal: dudu.me...@gmail.com profissional: ddm.farmac...@saude.gov.br ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
RE: em driver problem on vmware
Ah, Thanks for the direction. I'll take it as a self project from here. And I'll update this thread with my results hopefully by mid next week. Ricky From: Jack Vogel [mailto:jfvo...@gmail.com] Sent: Saturday, October 30, 2010 1:41 AM To: Juli Mallett Cc: Ricky Charlet; FreeBSD Net Subject: Re: em driver problem on vmware Uh, the emulated device in vmware is an OLD 82543 or something like that right? So, the e1000 driver in 8.1 is split into two parts, em and lem, its lem that has all the old pci support, so if you only pulled if_em then you dont have that code. Sounds like maybe you should just install 8.1 on your guest and avoid these kinds of problems. Regards, Jack On Fri, Oct 29, 2010 at 11:26 PM, Juli Mallett jmall...@freebsd.orgmailto:jmall...@freebsd.org wrote: dmesg is not cleared at boot; your devices are not being detected, they merely showed up in a previous boot. On Fri, Oct 29, 2010 at 23:13, Ricky Charlet rchar...@adaranet.commailto:rchar...@adaranet.com wrote: Hi Julie, My entire dmesg output is attached. With much appreciation Ricky -Original Message- From: j...@clockworksquid.commailto:j...@clockworksquid.com [mailto:j...@clockworksquid.commailto:j...@clockworksquid.com] On Behalf Of Juli Mallett Sent: Friday, October 29, 2010 8:01 PM To: Ricky Charlet Subject: Re: em driver problem on vmware Can you send me your full dmesg? You must be missing some relevant message, because the only circumstances under which you'd see the device attaching but then it wouldn't be present would also generate some error messages. On Fri, Oct 29, 2010 at 19:22, Ricky Charlet rchar...@adaranet.commailto:rchar...@adaranet.com wrote: Thanks Jack, The failure is that ifconfig is unaware of em0. My em0 is not configured, so link partners are also unaware of it. ifconfig em0 ifconfig: interface em0 does not exist and you already have my dmes stuff on em0 (which I am now up to agreeing looks positive and would not indicate a problem) My amalgamated file is a private combination of some 8.1, some 9.0, some stuff a cohort did. We have been motivated to 'upgrade' from e1000 in 8.0 to a newer/modified e1000 because of our desire to incorporate the altq patches. For the curious and the diligent, the e1000/if_em.c file I am using is attached. Ricky From: Jack Vogel [mailto:jfvo...@gmail.commailto:jfvo...@gmail.com] Sent: Friday, October 29, 2010 7:13 PM To: Ricky Charlet Cc: freebsd-net@freebsd.orgmailto:freebsd-net@freebsd.org Subject: Re: em driver problem on vmware I remember seeing the same thing when running a FreeBSD guest on Linux/KVM, its informational, the code will enable said bits right after it says that. So, the focus should be on the data, you are saying the delivered driver in 8.0 out of the box works and which driver exactly are you trying to use, my last checked in? More on the failure, does it ping, does its link partner see anything, etc, etc.. Jack On Fri, Oct 29, 2010 at 6:27 PM, Ricky Charlet rchar...@adaranet.commailto:rchar...@adaranet.commailto:rchar...@adaranet.commailto:rchar...@adaranet.com wrote: FYI, That dmesg output I get from my franken-driver on vmware is exactly the same output I get from the *working* bsd80Release on vmware: cut [r...@npx7511 /usr/src/sys/dev/e1000]# dmesg | grep em0 em0: Intel(R) PRO/1000 Network Connection 6.9.14 port 0x2000-0x203f mem 0xd894-0xd895,0xd890-0xd890 irq 18 at device 0.0 on pci2 em0: Memory Access and/or Bus Master bits were not set! em0: [FILTER] em0: Ethernet address: 00:0c:29:57:d7:7f ---paste--- So I don't think the clue is hiding in dmesg. --- Ricky Charlet Adara Networks USA 408-433-4942 -Original Message- From: owner-freebsd-...@freebsd.orgmailto:owner-freebsd-...@freebsd.orgmailto:owner-freebsd-mailto:owner-freebsd- n...@freebsd.orgmailto:n...@freebsd.org [mailto:owner-freebsd-...@freebsd.orgmailto:owner-freebsd-...@freebsd.orgmailto:owner-mailto:owner- freebsd-net@freebsd.orgmailto:freebsd-net@freebsd.org] On Behalf Of Ricky Charlet Sent: Friday, October 29, 2010 5:07 PM To: freebsd-net@freebsd.orgmailto:freebsd-net@freebsd.orgmailto:freebsd-net@freebsd.orgmailto:freebsd-net@freebsd.org Subject: em driver problem on vmware Howdy, I have freebsd80-release with an upgraded em0 driver from freebsd8.1 (and an appropriate touch of if_var.h). I'm running an amd64 on a vmware vm. And I see this in dmesg: cut- em0: Intel(R) PRO/1000 Network Connection 6.9.14 port 0x2000-203f mem 0xd894-0xd895, 0xd890-0xd890 irq 18 at device 0.0 on pci2 em0: Memory Access and/or Bus Master bits were not set em0: [FILTER] em0: Ethernet address: 00:0c:29:57:d7:7f paste
Re[2]: How to obtain place of low perfomance?
Hello, Pyun. Вы писали 29 октября 2010 г., 21:17:45: PY On Fri, Oct 29, 2010 at 10:20:10AM +0300, ?? ?? wrote: Hi, Freebsd-net. serv1# ifocnfig nfe0 nfe0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=10bRXCSUM,TXCSUM,VLAN_MTU,TSO4 ether 00:13:d4:ce:82:16 inet 10.11.8.17 netmask 0xfc00 broadcast 10.11.11.255 inet 10.11.8.15 netmask 0xfc00 broadcast 10.11.11.255 media: Ethernet autoselect (1000baseTX full-duplex) status: active serv1# ifconfig igb0 igb0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=19bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4 ether 00:1b:21:45:da:b8 media: Ethernet autoselect (1000baseTX full-duplex) status: active serv1# ifconfig vlan7 vlan7: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=3RXCSUM,TXCSUM ether 00:1b:21:45:da:b8 inet 10.11.15.15 netmask 0xff00 broadcast 10.11.15.255 inet 10.11.7.1 netmask 0xff00 broadcast 10.11.7.255 media: Ethernet autoselect (1000baseTX full-duplex) status: active vlan: 7 parent interface: igb0 doing bw test with iperf it show low performance on nfe0. # iperf -c 10.11.8.17 Client connecting to 10.11.8.17, TCP port 5001 TCP window size: 32.5 KByte (default) [ 3] local 10.11.8.16 port 63911 connected with 10.11.8.17 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.5 sec124 MBytes 98.8 Mbits/sec # iperf -c 10.11.7.1 Client connecting to 10.11.7.1, TCP port 5001 TCP window size: 32.5 KByte (default) [ 3] local 10.11.7.2 port 61422 connected with 10.11.7.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.3 sec800 MBytes653 Mbits/sec despite on it is integrated I expect about 300-400Mbit throughput does nfe0 really so poor NIC? PY nfe(4) controllers would not be one of best controllers targeted PY for server environments but generally it's not poor for desktop PY users. I mean you should be able to saturate link when you use bulk PY TCP/UDP transfers. PY Last time I tried iperf it was not reliable. Did you disable PY threading of iperf? Also note, both sender/receiver of iperf should PY be built with same configuration option. igb and nfe on same machine. --\igb 10.11.7.1 CLIENT/ SERVER \--/nfe 10.11.8.17 -- С уважением, Коньков mailto:kes-...@yandex.ru ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re[2]: Polling slows down bandwidth
Hi, Larry. LB Also make sure kern.polling.idle_poll is enabled. By default it is LB disabled. This makes a big difference in polling throughput. enabling that take all CPU time. last pid: 38722; load averages: 1.88, 1.18, 0.85up 1+18:43:28 20:04:54 101 processes: 5 running, 74 sleeping, 22 waiting CPU: 1.4% user, 0.0% nice, 61.7% system, 36.8% interrupt, 0.0% idle Mem: 395M Active, 898M Inact, 288M Wired, 5636K Cache, 213M Buf, 388M Free Swap: 4063M Total, 4063M Free PID USERNAME PRI NICE SIZERES STATETIME WCPU COMMAND 51 root 171 ki31 0K16K RUN 0:56 39.89% idlepoll 14 root -44- 0K16K WAIT 3:50 30.47% swi1: net 2 root -68- 0K16K sleep 253:55 25.20% ng_queue0 17358 bind440 223M 184M RUN 14:30 0.39% named 1324 root440 31828K 9192K select 9:35 0.29% mpd5 55 root20- 0K16K syncer 5:18 0.29% syncer How that affect other processes? Will they be slowed down by idlepoll? -- С уважением, Коньков mailto:kes-...@yandex.ru ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Polling slows down bandwidth
On Sat, Oct 30, 2010 at 12:32:19PM +0100, Paul Thornton wrote: I've been doing testing with FreeBSD 8 and em interfaces recently, and my experience agrees with Chuck's statement - that polling makes things worse when you use new (anything in the last 2 or 3 years) hardware with good quality gigabit ethernet interfaces. There are some deficiencies in the current polling algorithm that will cause it to perform less than optimally (it will temporarily stop processing packets even though it is consuming less CPU than requested). I have some changes that I plan to bring into the tree to improve this situation. For recent high quality hardware though I expect you'll get roughly equivalent performance from polling and standard opteration. -Ed ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/121257: [tcp] TSO + natd -gt; slow outgoing tcp traffic
The following reply was made to PR kern/121257; it has been noted by GNATS. From: Nick Christenson n...@gangofone.com To: bug-follo...@freebsd.org, vn...@vnovy.net Cc: Subject: Re: kern/121257: [tcp] TSO + natd -gt; slow outgoing tcp traffic Date: Sat, 30 Oct 2010 14:03:13 -0700 (PDT) I notice that not much has been done on this bug in the last couple of years, so here's a bump. I have reproduced this bug on an amd64 machine running FreeBSD 7.3-RELEASE-p3 with network cards using the msk driver. I'm running natd and pf. I'm not the only one who has encountered this. Other references to what looks like the same problem: http://lists.freebsd.org/pipermail/freebsd-net/2010-July/025731.html http://forums.freebsd.org/showthread.php?t=13900 http://osdir.com/ml/freebsd.bugs/2002-03/msg00051.html http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2010-01/msg00674.html http://comments.gmane.org/gmane.os.freebsd.current/127669 (subject significantly slow IPFW + NATD + amd64) Many of these don't include resolutions, so if this can't be fixed, at least publicizing the work around would seem to be well advised. It sounds from the bug like the developers have a good handle on the problem, but if I can do anything to help test, let me know. -- Nick Christenson n...@gangofone.com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
