Re: Intel 82550 Pro/100 Ethernet and TSO troubles
On 12/14/11 22:32, YongHyeon PYUN wrote: Wireshark showed some wrong checksums (I believe on the ICMP packet, but I might remember wrong). You can check whether you received bad checksummed frames with netstat(1). I tried netstat -ind, but it shows no Ierrs/Idrop/Oerrs/Odrop. Is simple downloading from client to server is enough to trigger the issue? Yes and no. Depending on where the client is located (on the Internet) and/or the protocol used, I get either failures or ridicuolous performance (i.e. 58-60kB/s without TSO vs. 1-2kB/s with TSO). Packet capture that shows the problem would be great to know what's going on here. I'll send them to you privately. You'll see tso.dump and notso.dump: they are both from the same client downloading the same (random) file (the file name was changed only to prevent possible caching). See notso.dump is perfect, while tso.dump shows a lot of potential problems. Would you try attached patch and let me know it goes? Sorry, it seems extra pull up for TCP payload may not be required here. Try this instead. I see a little increase in performance (2-3kB/s instead of 1-2kB/s); this might however well depend on external factors. Still it is very different from what I'm get without TSO. bye Thanks av. P.S. I can live well without TSO; I'm just doing this to let the software improve. Go ahead only if *you* are interested. ___ 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: stable/7 bce(4) out of buffers
On Tuesday, December 13, 2011 2:00:14 pm Sean Bruno wrote: Looks like we're pushing the BCM5716 really hard. Is there any way to give the net adapter a bit more space? e.g. dev.bce.0.com_no_buffers: 130228 Hmm, in HEAD there looks to be a hw.bce.rx_pages that can be set to 1, 2, 4, or 8. It defaults to 2. In the 7 driver it looks like this is a #define in sys/dev/bce/if_bcereg.h (RX_PAGES on line 6710). Try changing RX_PAGES from 2 to 4 (or 8) and recompiling your kernel (or bce driver) and see if that helps. -- John Baldwin ___ 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: stable/7 bce(4) out of buffers
On Thu, 2011-12-15 at 07:00 -0800, John Baldwin wrote: On Tuesday, December 13, 2011 2:00:14 pm Sean Bruno wrote: Looks like we're pushing the BCM5716 really hard. Is there any way to give the net adapter a bit more space? e.g. dev.bce.0.com_no_buffers: 130228 Hmm, in HEAD there looks to be a hw.bce.rx_pages that can be set to 1, 2, 4, or 8. It defaults to 2. In the 7 driver it looks like this is a #define in sys/dev/bce/if_bcereg.h (RX_PAGES on line 6710). Try changing RX_PAGES from 2 to 4 (or 8) and recompiling your kernel (or bce driver) and see if that helps. Indeed, I was eyeballing that just now. I'll post back with results. Sean ___ 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
ng_mppc_decompress: too many (4094) packets dropped, disabling node
Hi, I've searched the net andfound basicly 2 threads talking about the message: ng_mppc_decompress: too many (4094) packets dropped, disabling node in FBSD 6.3 http://lists.freebsd.org/pipermail/freebsd-bugs/2008-April/030183.html its a pr 123045 and 5.4. http://markmail.org/message/lptpp4qmiwksazxc basicly suggested to set define MPPE_MAX_REKEY to a higher values and found somewhere a patch that changes it to variable rather than using it as macro i saw no answer indicating this really solves the problem. did anyone have a solution tothe problem? i'm suffering from it even i have about 200 concurrent connections, as i read MPD+FREEBSD usually can utilize thousands of sessions. Thanks in advance, -- Sami Halabi Information Systems Engineer NMS Projects Expert ___ 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: LOR in FreeBSD 8.1 w/ IPv6
This was fixed on HEAD in r207337. I believe that it was MFC'ed some time ago. http://svnweb.freebsd.org/base?view=revisionrevision=207337 ___ 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: Intel 82550 Pro/100 Ethernet and TSO troubles
On Thu, Dec 15, 2011 at 03:16:51PM +0100, Andrea Venturoli wrote: On 12/14/11 22:32, YongHyeon PYUN wrote: Wireshark showed some wrong checksums (I believe on the ICMP packet, but I might remember wrong). You can check whether you received bad checksummed frames with netstat(1). I tried netstat -ind, but it shows no Ierrs/Idrop/Oerrs/Odrop. Use -s option which will show statistics for each network protocols. Search 'discarded for bad checksums' from the output. Is simple downloading from client to server is enough to trigger the issue? Yes and no. Depending on where the client is located (on the Internet) and/or the protocol used, I get either failures or ridicuolous performance (i.e. 58-60kB/s without TSO vs. 1-2kB/s with TSO). Packet capture that shows the problem would be great to know what's going on here. I'll send them to you privately. You'll see tso.dump and notso.dump: they are both from the same client downloading the same (random) file (the file name was changed only to prevent possible caching). See notso.dump is perfect, while tso.dump shows a lot of potential problems. Thanks. Would you try attached patch and let me know it goes? Sorry, it seems extra pull up for TCP payload may not be required here. Try this instead. I see a little increase in performance (2-3kB/s instead of 1-2kB/s); this might however well depend on external factors. Still it is very different from what I'm get without TSO. Thanks for testing. Based on dump file, I tried various MTU configuration and I was not able to reproduce it. By chance, are you using firewall(pf/ipfw/ipf) or bridge(4)? If I remember correctly some firewall rules are not compatible with TSO. For bridge, if one member of bridge does not support TSO, TSO should be disabled. bye Thanks av. P.S. I can live well without TSO; I'm just doing this to let the software improve. Go ahead only if *you* are interested. I do care driver stability so it would be great if I manage to address the issue. :-) ___ 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
