Re: The tale of a TCP bug
On Monday, March 28, 2011 2:38:10 pm Stefan `Sec` Zehl wrote:
> Hi,
>
> On Mon, Mar 28, 2011 at 14:23 -0400, John Baldwin wrote:
> >
> > No, this is not really right. Your patch from your blog is the best
> > fix actually. The reason we want to let 'win' be larger than
> > TCP_MAXWIN is that if the remote end sends more data than we've
> > advertised but we have room in the socket buffer, we want to go ahead
> > and accept the data as valid and ACK it rather than dropping the data
> > that is beyond rcv_adv. My change above to rcv_wnd would break this.
> > Also, for the TCPS_SYN_SENT case we don't know what 'rcv_scale' is
> > until just before we update 'rcv_adv'. This should be the same
> > as your patch:
> >
> > Index: tcp_input.c
> > ===
> > --- tcp_input.c (revision 220098)
> > +++ tcp_input.c (working copy)
> > @@ -1756,7 +1756,8 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th,
> > (TF_RCVD_SCALE|TF_REQ_SCALE)) {
> > tp->rcv_scale = tp->request_r_scale;
> > }
> > - tp->rcv_adv += tp->rcv_wnd;
> > + tp->rcv_adv += imin(tp->rcv_wnd,
> > + TCP_MAXWIN << tp->rcv_scale);
> > tp->snd_una++; /* SYN is acked */
> > /*
> > * If there's data, delay ACK; if there's also a FIN
> >
>
> I've applied this to my test-VM, and as expected it now passes my two
> testcases. As far as I'm concerned this fixes it for me.
>
> I'm interested to see if my adv_neg counting hack together with this
> patch still registers any hits. -- If nobody beats me to it, I'll try it
> out on my webserver tomorrow.
There is at least one case I know of related to a bug I reported earlier
where a window probe from a remote connection can cause rcv_nxt to advance
past rcv_adv by one. However, I think we want to know about those cases,
and we should probably be treating rcv_adv - rcv_nxt as if it is zero in
that case, not -1 (my patch in my original e-mail does just that in a
different place in tcp_output() when we calculate the window "for real").
--
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: kern/154006: [tcp] [patch] tcp "window probe" bug on 64bit
Synopsis: [tcp] [patch] tcp "window probe" bug on 64bit State-Changed-From-To: open->patched State-Changed-By: jhb State-Changed-When: Wed Mar 30 12:38:33 UTC 2011 State-Changed-Why: Fix committed to HEAD. Responsible-Changed-From-To: freebsd-net->jhb Responsible-Changed-By: jhb Responsible-Changed-When: Wed Mar 30 12:38:33 UTC 2011 Responsible-Changed-Why: Fix committed to HEAD. http://www.freebsd.org/cgi/query-pr.cgi?pr=154006 ___ 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: igb(4) won't start with "igb0: Could not setup receive structures"
Hi, On Wed, Mar 30, 2011 at 1:11 AM, Doug Barton wrote: > On 03/29/2011 22:07, Arnaud Lacombe wrote: >> >> ... or maintain internal changes to the driver to make it not that memory >> hungry/behave well under memory pressure, especially on system where >> memory_is_ a constraint. > > If you come up with patches, I'm sure everyone would like to see them. > No, I came with a patch, Jack sent it explicitly to /dev/null, telling me that what I was checking was not available in the mode the driver was in. Then I took the chip documentation, quoted all the chapters which lead me to believe that what I was checking _was_ available in the mode the driver was. I never got an answer. Unfortunately, all these discussion are not publicly available because Jack like doing things off the list. The only things I've been able to get from Jack is "We, at Intel, test em(4) at 256k nmbclusters. We do not have problem. If you have problem, raise nmbcluster.". 256k nmbcluster in my environment is not acceptable. > Meanwhile, there are times where memory IS a constraint, and there are some > things you can't do without more of it. > yes, but the driver should not need a manual reset between the time resource are (heavily) scarce and the time it became available again. - Arnaud ___ 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"
Kernel memory corruption(?) with age(4)
Hi, I recently got four about two years old Asus M3A-H/HDMI mainboards with an integrated Attansic L2 ethernet controller. This NIC is supported by age(4) and recognized by freebsd: age0: mem 0xfeac-0xfeaf irq 18 at device 0.0 on pci2 age0: 1280 Tx FIFO, 2364 Rx FIFO age0: Using 1 MSI messages. age0: 4GB boundary crossed, switching to 32bit DMA addressing mode. miibus0: on age0 atphy0: PHY 0 on miibus0 atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto age0: Ethernet address: 00:23:54:31:a0:12 age0: [FILTER] age0: flags=8843 metric 0 mtu 1500 options=c319b ether 00:23:54:31:a0:12 inet6 fe80::223:54ff:fe31:a012%age0 prefixlen 64 scopeid 0x1 nd6 options=3 media: Ethernet autoselect (none) status: no carrier All for boxes are unstable if the Attansic NIC is in use, no one of them survived more than 60 minutes of ~20mb/s network traffic. I managed to get some coredumps and extracted the backtraces. Since everytime one of the boxes paniced I got different panic message and a different backtrace with a different subsystem involved I suspected broken hardware. I plugged a em(4) NIC into the PCI slot and wasn't able to reproduce the problem, in fact the boxes run rock solid for several days. Next I set up a Windows 7, installed the Attansic vendor driver and did another run. All went smooth, no crash for nearly 24 hours. My guess is kernel memory corruption by age(4), which would explain all the different backtraces and the different panic messages. This problem is reproducible in at least FreeBSD 7.4 and 8.2 and with TSO4 enabled and disabled. I'm willing to debug this, but I really don't know how. So any help or a pointer into the right direction would be appreciated. Three backtraces, all of them occurred while receiving and sending data via NFS over the age(4) NIC: panic: initiate_write_filepage: dir inum 50001080 != new 0 cpuid = 2 #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:251 #1 0x8018604c in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/src/sys/ddb/db_command.c:548 #2 0x80186381 in db_command (last_cmdp=0x806178c0, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0x801865d0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0x80188619 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0x8024d7fe in kdb_trap (type=3, code=0, tf=0xff8243513720) at /usr/src/sys/kern/subr_kdb.c:546 #6 0x80424366 in trap (frame=0xff8243513720) at /usr/src/sys/amd64/amd64/trap.c:566 #7 0x8040c234 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #8 0x8024d99d in kdb_enter (why=0x80479419 "panic", msg=0xa ) at cpufunc.h:63 #9 0x8021c4f0 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #10 0x80c5925e in softdep_fsync_mountdev () from /boot/kernel/ufs.ko #11 0xff00067a0460 in ?? () #12 0x in ?? () #13 0xff0167d49988 in ?? () #14 0xff000694000e in ?? () #15 0xff0006b32800 in ?? () #16 0xff81ef201bd0 in ?? () #17 0xff81ef201bd0 in ?? () #18 0xff0006b613b0 in ?? () #19 0xff0006b614c8 in ?? () #20 0xff0156024878 in ?? () #21 0xff8243513980 in ?? () #22 0x80c5c174 in ffs_flushfiles () from /boot/kernel/ufs.ko #23 0xff81ef201bd0 in ?? () #24 0xff013c210a80 in ?? () #25 0x0004 in ?? () #26 0x in ?? () #27 0xff82435139b0 in ?? () #28 0x80c3ea25 in ufs_do_nfs4_acl_inheritance () from /boot/kernel/ufs.ko #29 0xff82435139b0 in ?? () #30 0x80459fb5 in VOP_STRATEGY_APV (vop=0xff00067a0460, a=0xff0167d49980) at vnode_if.c:2169 Previous frame inner to this frame (corrupt stack?) Fatal trap 9: general protection fault while in kernel mode cpuid = 2; apic id = 02 instruction pointer = 0x20:0x8020ca0e stack pointer = 0x28:0xff82435139e0 frame pointer = 0x28:0xff8243513a00 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 21 (syncer) #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:251 #1 0x8018604c in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/src/sys/ddb/db_command.c:548 #2 0x80186381 in db_command (last_cmdp=0x806178c0, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0x801865d0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0x80188619 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0x8024d7fe in kd
Re: igb(4) won't start with "igb0: Could not setup receive structures"
Hi, On Wed, Mar 30, 2011 at 1:58 AM, Andrey Zonov wrote: > My point is if you're using machine with 8 CPUs than maxusers/clusters/9k > mbufs should have been increased by system, because on this machine minimum > 2Gb memory is available. > I am doubtful that the number of CPU[0] or number of users (yes, I know `maxusers' is currently used to compute the default `nmbcluster'...) can be linked to any network load pattern at all. You can have a 24 CPU machine made for 4096 users with a single NIC, not requiring much memory, while a 1 CPU machine with only 1 users can have +8 NIC and require a huge quantity of memory. Available KVM space should also be taken into account, as it is rather limited on i386. - Arnaud [0]: even more today where you can have a huge number of virtual CPU. ___ 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: bge(4) on RELENG_8 mbuf cluster starvation
On Sun, Mar 13, 2011 at 2:16 AM, YongHyeon PYUN wrote: > On Sat, Mar 12, 2011 at 09:17:28PM +0100, Vlad Galu wrote: > > On Sat, Mar 12, 2011 at 8:53 PM, Arnaud Lacombe > wrote: > > > > > Hi, > > > > > > On Sat, Mar 12, 2011 at 4:03 AM, Vlad Galu wrote: > > > > Hi folks, > > > > > > > > On a fairly busy recent (r219010) RELENG_8 machine I keep getting > > > > -- cut here -- > > > > 1096/1454/2550 mbufs in use (current/cache/total) > > > > 1035/731/1766/262144 mbuf clusters in use (current/cache/total/max) > > > > 1035/202 mbuf+clusters out of packet secondary zone in use > > > (current/cache) > > > > 0/117/117/12800 4k (page size) jumbo clusters in use > > > > (current/cache/total/max) > > > > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > > > > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > > > > 2344K/2293K/4637K bytes allocated to network (current/cache/total) > > > > 0/70128196/37726935 requests for mbufs denied > > > (mbufs/clusters/mbuf+clusters) > > > > ^ > > > > -- and here -- > > > > > > > > kern.ipc.nmbclusters is set to 131072. Other settings: > > > no, netstat(8) says 262144. > > > > > > > > Heh, you're right, I forgot I'd doubled it a while ago. Wrote that from > the > > top of my head. > > > > > > > Maybe can you include $(sysctl dev.bge) ? Might be useful. > > > > > > - Arnaud > > > > > > > Sure: > > [...] > > > dev.bge.1.%desc: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC > rev. > > 0x004101 > > dev.bge.1.%driver: bge > > dev.bge.1.%location: slot=0 function=0 > > dev.bge.1.%pnpinfo: vendor=0x14e4 device=0x1659 subvendor=0x1014 > > subdevice=0x02c6 class=0x02 > > dev.bge.1.%parent: pci5 > > dev.bge.1.forced_collapse: 2 > > dev.bge.1.forced_udpcsum: 0 > > dev.bge.1.stats.FramesDroppedDueToFilters: 0 > > dev.bge.1.stats.DmaWriteQueueFull: 0 > > dev.bge.1.stats.DmaWriteHighPriQueueFull: 0 > > dev.bge.1.stats.NoMoreRxBDs: 680050 > ^^^ > This indicates bge(4) encountered RX buffer shortage. Perhaps > bge(4) couldn't fill new RX buffers for incoming frames due to > other system activities. > > > dev.bge.1.stats.InputDiscards: 228755931 > > This counter indicates number of frames discarded due to RX buffer > shortage. bge(4) discards received frame if it failed to allocate > new RX buffer such that InputDiscards is normally higher than > NoMoreRxBDs. > > > dev.bge.1.stats.InputErrors: 49080818 > ^ > Something is wrong here. Too many frames were classified as error > frames. You may see poor RX performance. > > > dev.bge.1.stats.RecvThresholdHit: 0 > > dev.bge.1.stats.rx.ifHCInOctets: 2095148839247 > > dev.bge.1.stats.rx.Fragments: 47887706 > > dev.bge.1.stats.rx.UnicastPkts: 32672557601 > > dev.bge.1.stats.rx.MulticastPkts: 1218 > > dev.bge.1.stats.rx.BroadcastPkts: 2 > > dev.bge.1.stats.rx.FCSErrors: 2822217 > ^ > FCS errors are too high. Please check cabling again(I'm assuming > the controller is not broken here). I think you can use vendor's > diagnostic tools to verify this. > > > dev.bge.1.stats.rx.AlignmentErrors: 0 > > dev.bge.1.stats.rx.xonPauseFramesReceived: 0 > > dev.bge.1.stats.rx.xoffPauseFramesReceived: 0 > > dev.bge.1.stats.rx.ControlFramesReceived: 0 > > dev.bge.1.stats.rx.xoffStateEntered: 0 > > dev.bge.1.stats.rx.FramesTooLong: 0 > > dev.bge.1.stats.rx.Jabbers: 0 > > dev.bge.1.stats.rx.UndersizePkts: 0 > > dev.bge.1.stats.tx.ifHCOutOctets: 48751515826 > > dev.bge.1.stats.tx.Collisions: 0 > > dev.bge.1.stats.tx.XonSent: 0 > > dev.bge.1.stats.tx.XoffSent: 0 > > dev.bge.1.stats.tx.InternalMacTransmitErrors: 0 > > dev.bge.1.stats.tx.SingleCollisionFrames: 0 > > dev.bge.1.stats.tx.MultipleCollisionFrames: 0 > > dev.bge.1.stats.tx.DeferredTransmissions: 0 > > dev.bge.1.stats.tx.ExcessiveCollisions: 0 > > dev.bge.1.stats.tx.LateCollisions: 0 > > dev.bge.1.stats.tx.UnicastPkts: 281039183 > > dev.bge.1.stats.tx.MulticastPkts: 0 > > dev.bge.1.stats.tx.BroadcastPkts: 1153 > > -- and here -- > > > > And now, that I remembered about this as well: > > -- cut here -- > > NameMtu Network Address Ipkts Ierrs IdropOpkts > > Oerrs Coll > > bge1 1500 00:11:25:22:0d:ed 32321767025 278517070 > 37726837 > > 281068216 0 0 > > -- and here -- > > The colo provider changed my cable a couple of times so I'd not blame it > on > > that. Unfortunately, I don't have access to the port statistics on the > > switch. Running netstat with -w1 yields between 0 and 4 errors/second. > > > > Hardware MAC counters still show high number of FCS errors. The > service provider should have to check possible cabling issues on > the port of the switch. > After swapping cables and moving the NIC into another switch, there are some improvements. However: -- cut here -- dev.bge.1.%desc: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x004101 dev.bge.1.%driver: bge dev.bge.1.%location: slot=0 func
Re: igb(4) won't start with "igb0: Could not setup receive structures"
On 3/30/2011 7:19 AM, Arnaud Lacombe wrote: Hi, On Wed, Mar 30, 2011 at 1:11 AM, Doug Barton wrote: The only things I've been able to get from Jack is "We, at Intel, test em(4) at 256k nmbclusters. We do not have problem. If you have problem, raise nmbcluster.". 256k nmbcluster in my environment is not acceptable. Meanwhile, there are times where memory IS a constraint, and there are some things you can't do without more of it. yes, but the driver should not need a manual reset between the time resource are (heavily) scarce and the time it became available again. If you're facing that situation then obviously your system is constrained by hardware. It sounds like you have 3 choices: 1. Add more RAM 2. Use a different NIC 3. Set MTU lower I'm sorry to say that just because the software is free doesn't mean that we can guarantee that it will work on all hardware. Sometimes the physical limits of the hardware are what need to be changed. Good luck, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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"
Re: igb(4) won't start with "igb0: Could not setup receive structures"
Hi, On Wed, Mar 30, 2011 at 12:44 PM, Doug Barton wrote: > On 3/30/2011 7:19 AM, Arnaud Lacombe wrote: >> >> Hi, >> >> On Wed, Mar 30, 2011 at 1:11 AM, Doug Barton wrote: > >> The only things I've been able to get from Jack is "We, at Intel, test >> em(4) at 256k nmbclusters. We do not have problem. If you have >> problem, raise nmbcluster.". 256k nmbcluster in my environment is not >> acceptable. >> >>> Meanwhile, there are times where memory IS a constraint, and there are >>> some >>> things you can't do without more of it. >>> >> yes, but the driver should not need a manual reset between the time >> resource are (heavily) scarce and the time it became available again. > > If you're facing that situation then obviously your system is constrained by > hardware. No. We are taking about exceptional recoverable situation not handled by the software, it should not bring the complete system down. If you're swapping code has defect, you do not tell one to buy more RAM not to trigger the defective code, you fix the code. The situation is similar here. - Arnaud ___ 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: igb(4) won't start with "igb0: Could not setup receive structures"
On 3/30/2011 10:06 AM, Arnaud Lacombe wrote: No. We are taking about exceptional recoverable situation not handled by the software, it should not bring the complete system down. If you're swapping code has defect, you do not tell one to buy more RAM not to trigger the defective code, you fix the code. The situation is similar here. I understand that you believe the situations to be similar, however you may make your point more clearly if you share the patches you've developed with the list so that others can review/comment/etc. There is no need to cc me on further related messages. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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"
Re: bge(4) on RELENG_8 mbuf cluster starvation
On Wed, Mar 30, 2011 at 05:55:47PM +0200, Vlad Galu wrote: > On Sun, Mar 13, 2011 at 2:16 AM, YongHyeon PYUN wrote: > > > On Sat, Mar 12, 2011 at 09:17:28PM +0100, Vlad Galu wrote: > > > On Sat, Mar 12, 2011 at 8:53 PM, Arnaud Lacombe > > wrote: > > > > > > > Hi, > > > > > > > > On Sat, Mar 12, 2011 at 4:03 AM, Vlad Galu wrote: > > > > > Hi folks, > > > > > > > > > > On a fairly busy recent (r219010) RELENG_8 machine I keep getting > > > > > -- cut here -- > > > > > 1096/1454/2550 mbufs in use (current/cache/total) > > > > > 1035/731/1766/262144 mbuf clusters in use (current/cache/total/max) > > > > > 1035/202 mbuf+clusters out of packet secondary zone in use > > > > (current/cache) > > > > > 0/117/117/12800 4k (page size) jumbo clusters in use > > > > > (current/cache/total/max) > > > > > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > > > > > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > > > > > 2344K/2293K/4637K bytes allocated to network (current/cache/total) > > > > > 0/70128196/37726935 requests for mbufs denied > > > > (mbufs/clusters/mbuf+clusters) > > > > > ^ > > > > > -- and here -- > > > > > > > > > > kern.ipc.nmbclusters is set to 131072. Other settings: > > > > no, netstat(8) says 262144. > > > > > > > > > > > Heh, you're right, I forgot I'd doubled it a while ago. Wrote that from > > the > > > top of my head. > > > > > > > > > > Maybe can you include $(sysctl dev.bge) ? Might be useful. > > > > > > > > - Arnaud > > > > > > > > > > Sure: > > > > [...] > > > > > dev.bge.1.%desc: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC > > rev. > > > 0x004101 > > > dev.bge.1.%driver: bge > > > dev.bge.1.%location: slot=0 function=0 > > > dev.bge.1.%pnpinfo: vendor=0x14e4 device=0x1659 subvendor=0x1014 > > > subdevice=0x02c6 class=0x02 > > > dev.bge.1.%parent: pci5 > > > dev.bge.1.forced_collapse: 2 > > > dev.bge.1.forced_udpcsum: 0 > > > dev.bge.1.stats.FramesDroppedDueToFilters: 0 > > > dev.bge.1.stats.DmaWriteQueueFull: 0 > > > dev.bge.1.stats.DmaWriteHighPriQueueFull: 0 > > > dev.bge.1.stats.NoMoreRxBDs: 680050 > > ^^^ > > This indicates bge(4) encountered RX buffer shortage. Perhaps > > bge(4) couldn't fill new RX buffers for incoming frames due to > > other system activities. > > > > > dev.bge.1.stats.InputDiscards: 228755931 > > > > This counter indicates number of frames discarded due to RX buffer > > shortage. bge(4) discards received frame if it failed to allocate > > new RX buffer such that InputDiscards is normally higher than > > NoMoreRxBDs. > > > > > dev.bge.1.stats.InputErrors: 49080818 > > ^ > > Something is wrong here. Too many frames were classified as error > > frames. You may see poor RX performance. > > > > > dev.bge.1.stats.RecvThresholdHit: 0 > > > dev.bge.1.stats.rx.ifHCInOctets: 2095148839247 > > > dev.bge.1.stats.rx.Fragments: 47887706 > > > dev.bge.1.stats.rx.UnicastPkts: 32672557601 > > > dev.bge.1.stats.rx.MulticastPkts: 1218 > > > dev.bge.1.stats.rx.BroadcastPkts: 2 > > > dev.bge.1.stats.rx.FCSErrors: 2822217 > > ^ > > FCS errors are too high. Please check cabling again(I'm assuming > > the controller is not broken here). I think you can use vendor's > > diagnostic tools to verify this. > > > > > dev.bge.1.stats.rx.AlignmentErrors: 0 > > > dev.bge.1.stats.rx.xonPauseFramesReceived: 0 > > > dev.bge.1.stats.rx.xoffPauseFramesReceived: 0 > > > dev.bge.1.stats.rx.ControlFramesReceived: 0 > > > dev.bge.1.stats.rx.xoffStateEntered: 0 > > > dev.bge.1.stats.rx.FramesTooLong: 0 > > > dev.bge.1.stats.rx.Jabbers: 0 > > > dev.bge.1.stats.rx.UndersizePkts: 0 > > > dev.bge.1.stats.tx.ifHCOutOctets: 48751515826 > > > dev.bge.1.stats.tx.Collisions: 0 > > > dev.bge.1.stats.tx.XonSent: 0 > > > dev.bge.1.stats.tx.XoffSent: 0 > > > dev.bge.1.stats.tx.InternalMacTransmitErrors: 0 > > > dev.bge.1.stats.tx.SingleCollisionFrames: 0 > > > dev.bge.1.stats.tx.MultipleCollisionFrames: 0 > > > dev.bge.1.stats.tx.DeferredTransmissions: 0 > > > dev.bge.1.stats.tx.ExcessiveCollisions: 0 > > > dev.bge.1.stats.tx.LateCollisions: 0 > > > dev.bge.1.stats.tx.UnicastPkts: 281039183 > > > dev.bge.1.stats.tx.MulticastPkts: 0 > > > dev.bge.1.stats.tx.BroadcastPkts: 1153 > > > -- and here -- > > > > > > And now, that I remembered about this as well: > > > -- cut here -- > > > NameMtu Network Address Ipkts Ierrs IdropOpkts > > > Oerrs Coll > > > bge1 1500 00:11:25:22:0d:ed 32321767025 278517070 > > 37726837 > > > 281068216 0 0 > > > -- and here -- > > > The colo provider changed my cable a couple of times so I'd not blame it > > on > > > that. Unfortunately, I don't have access to the port statistics on the > > > switch. Running netstat with -w1 yields between 0 and 4 errors/second. > > > > > > > Hardware MAC counters still show high number of FCS errors. The > > service provider should have to che
Re: igb(4) won't start with "igb0: Could not setup receive structures"
On Wed, Mar 30, 2011 at 10:06 AM, Arnaud Lacombe wrote: > Hi, > > On Wed, Mar 30, 2011 at 12:44 PM, Doug Barton wrote: > > On 3/30/2011 7:19 AM, Arnaud Lacombe wrote: > >> > >> Hi, > >> > >> On Wed, Mar 30, 2011 at 1:11 AM, Doug Barton wrote: > > > >> The only things I've been able to get from Jack is "We, at Intel, test > >> em(4) at 256k nmbclusters. We do not have problem. If you have > >> problem, raise nmbcluster.". 256k nmbcluster in my environment is not > >> acceptable. > >> > >>> Meanwhile, there are times where memory IS a constraint, and there are > >>> some > >>> things you can't do without more of it. > >>> > >> yes, but the driver should not need a manual reset between the time > >> resource are (heavily) scarce and the time it became available again. > > > > If you're facing that situation then obviously your system is constrained > by > > hardware. > No. We are taking about exceptional recoverable situation not handled > by the software, it should not bring the complete system down. If > you're swapping code has defect, you do not tell one to buy more RAM > not to trigger the defective code, you fix the code. The situation is > similar here. > > The code that got put in the driver has a response to this "unrecoverable situation", you've flamed me and the code, but you've not demonstrated it does not work. Both Beezar and myself have tried to have a civil discussion over the matter and you just have gotten rude. As demonstrated in this email thread. I don't know about you, but I have feelings, and you've been insensitive to them. So quote chapters and verses all you like, I'm DONE with this. Jack ___ 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: bge(4) on RELENG_8 mbuf cluster starvation
On Wed, Mar 30, 2011 at 7:10 PM, YongHyeon PYUN wrote: > On Wed, Mar 30, 2011 at 05:55:47PM +0200, Vlad Galu wrote: > > On Sun, Mar 13, 2011 at 2:16 AM, YongHyeon PYUN > wrote: > > > > > On Sat, Mar 12, 2011 at 09:17:28PM +0100, Vlad Galu wrote: > > > > On Sat, Mar 12, 2011 at 8:53 PM, Arnaud Lacombe > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > On Sat, Mar 12, 2011 at 4:03 AM, Vlad Galu wrote: > > > > > > Hi folks, > > > > > > > > > > > > On a fairly busy recent (r219010) RELENG_8 machine I keep getting > > > > > > -- cut here -- > > > > > > 1096/1454/2550 mbufs in use (current/cache/total) > > > > > > 1035/731/1766/262144 mbuf clusters in use > (current/cache/total/max) > > > > > > 1035/202 mbuf+clusters out of packet secondary zone in use > > > > > (current/cache) > > > > > > 0/117/117/12800 4k (page size) jumbo clusters in use > > > > > > (current/cache/total/max) > > > > > > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > > > > > > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > > > > > > 2344K/2293K/4637K bytes allocated to network > (current/cache/total) > > > > > > 0/70128196/37726935 requests for mbufs denied > > > > > (mbufs/clusters/mbuf+clusters) > > > > > > ^ > > > > > > -- and here -- > > > > > > > > > > > > kern.ipc.nmbclusters is set to 131072. Other settings: > > > > > no, netstat(8) says 262144. > > > > > > > > > > > > > > Heh, you're right, I forgot I'd doubled it a while ago. Wrote that > from > > > the > > > > top of my head. > > > > > > > > > > > > > Maybe can you include $(sysctl dev.bge) ? Might be useful. > > > > > > > > > > - Arnaud > > > > > > > > > > > > > Sure: > > > > > > [...] > > > > > > > dev.bge.1.%desc: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC > > > rev. > > > > 0x004101 > > > > dev.bge.1.%driver: bge > > > > dev.bge.1.%location: slot=0 function=0 > > > > dev.bge.1.%pnpinfo: vendor=0x14e4 device=0x1659 subvendor=0x1014 > > > > subdevice=0x02c6 class=0x02 > > > > dev.bge.1.%parent: pci5 > > > > dev.bge.1.forced_collapse: 2 > > > > dev.bge.1.forced_udpcsum: 0 > > > > dev.bge.1.stats.FramesDroppedDueToFilters: 0 > > > > dev.bge.1.stats.DmaWriteQueueFull: 0 > > > > dev.bge.1.stats.DmaWriteHighPriQueueFull: 0 > > > > dev.bge.1.stats.NoMoreRxBDs: 680050 > > > ^^^ > > > This indicates bge(4) encountered RX buffer shortage. Perhaps > > > bge(4) couldn't fill new RX buffers for incoming frames due to > > > other system activities. > > > > > > > dev.bge.1.stats.InputDiscards: 228755931 > > > > > > This counter indicates number of frames discarded due to RX buffer > > > shortage. bge(4) discards received frame if it failed to allocate > > > new RX buffer such that InputDiscards is normally higher than > > > NoMoreRxBDs. > > > > > > > dev.bge.1.stats.InputErrors: 49080818 > > > ^ > > > Something is wrong here. Too many frames were classified as error > > > frames. You may see poor RX performance. > > > > > > > dev.bge.1.stats.RecvThresholdHit: 0 > > > > dev.bge.1.stats.rx.ifHCInOctets: 2095148839247 > > > > dev.bge.1.stats.rx.Fragments: 47887706 > > > > dev.bge.1.stats.rx.UnicastPkts: 32672557601 > > > > dev.bge.1.stats.rx.MulticastPkts: 1218 > > > > dev.bge.1.stats.rx.BroadcastPkts: 2 > > > > dev.bge.1.stats.rx.FCSErrors: 2822217 > > > ^ > > > FCS errors are too high. Please check cabling again(I'm assuming > > > the controller is not broken here). I think you can use vendor's > > > diagnostic tools to verify this. > > > > > > > dev.bge.1.stats.rx.AlignmentErrors: 0 > > > > dev.bge.1.stats.rx.xonPauseFramesReceived: 0 > > > > dev.bge.1.stats.rx.xoffPauseFramesReceived: 0 > > > > dev.bge.1.stats.rx.ControlFramesReceived: 0 > > > > dev.bge.1.stats.rx.xoffStateEntered: 0 > > > > dev.bge.1.stats.rx.FramesTooLong: 0 > > > > dev.bge.1.stats.rx.Jabbers: 0 > > > > dev.bge.1.stats.rx.UndersizePkts: 0 > > > > dev.bge.1.stats.tx.ifHCOutOctets: 48751515826 > > > > dev.bge.1.stats.tx.Collisions: 0 > > > > dev.bge.1.stats.tx.XonSent: 0 > > > > dev.bge.1.stats.tx.XoffSent: 0 > > > > dev.bge.1.stats.tx.InternalMacTransmitErrors: 0 > > > > dev.bge.1.stats.tx.SingleCollisionFrames: 0 > > > > dev.bge.1.stats.tx.MultipleCollisionFrames: 0 > > > > dev.bge.1.stats.tx.DeferredTransmissions: 0 > > > > dev.bge.1.stats.tx.ExcessiveCollisions: 0 > > > > dev.bge.1.stats.tx.LateCollisions: 0 > > > > dev.bge.1.stats.tx.UnicastPkts: 281039183 > > > > dev.bge.1.stats.tx.MulticastPkts: 0 > > > > dev.bge.1.stats.tx.BroadcastPkts: 1153 > > > > -- and here -- > > > > > > > > And now, that I remembered about this as well: > > > > -- cut here -- > > > > NameMtu Network Address Ipkts Ierrs Idrop > Opkts > > > > Oerrs Coll > > > > bge1 1500 00:11:25:22:0d:ed 32321767025 278517070 > > > 37726837 > > > > 281068216 0 0 > > > > -- and here -- > > > > The colo provider changed my cable a couple o
Re: Kernel memory corruption(?) with age(4)
On Wed, Mar 30, 2011 at 04:22:23PM +0200, Yamagi Burmeister wrote: > Hi, > I recently got four about two years old Asus M3A-H/HDMI mainboards with > an integrated Attansic L2 ethernet controller. This NIC is supported by > age(4) and recognized by freebsd: > > > > age0: >mem 0xfeac-0xfeaf irq 18 at device 0.0 on pci2 > age0: 1280 Tx FIFO, 2364 Rx FIFO > age0: Using 1 MSI messages. > age0: 4GB boundary crossed, switching to 32bit DMA addressing mode. > miibus0: on age0 > atphy0: PHY 0 on miibus0 > atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, > 1000baseT-FDX-master, auto > age0: Ethernet address: 00:23:54:31:a0:12 > age0: [FILTER] > > > > age0: flags=8843 metric 0 mtu 1500 > options=c319b WOL_MCAST,WOL_MAGIC,VLAN_HWTSO,LINKSTATE> > ether 00:23:54:31:a0:12 > inet6 fe80::223:54ff:fe31:a012%age0 prefixlen 64 scopeid 0x1 > nd6 options=3 > media: Ethernet autoselect (none) > status: no carrier > > > > All for boxes are unstable if the Attansic NIC is in use, no one of them > survived more than 60 minutes of ~20mb/s network traffic. I managed to > get some coredumps and extracted the backtraces. Since everytime one of > the boxes paniced I got different panic message and a different backtrace > with a different subsystem involved I suspected broken hardware. I > plugged a em(4) NIC into the PCI slot and wasn't able to reproduce the > problem, in fact the boxes run rock solid for several days. Next I set > up a Windows 7, installed the Attansic vendor driver and did another > run. All went smooth, no crash for nearly 24 hours. > > My guess is kernel memory corruption by age(4), which would explain all > the different backtraces and the different panic messages. This problem > is reproducible in at least FreeBSD 7.4 and 8.2 and with TSO4 enabled > and disabled. I'm willing to debug this, but I really don't know how. So > any help or a pointer into the right direction would be appreciated. > AFAIK this is the first report for possible memory corruption triggered by age(4). I'm still not sure whether it's caused by age(4) but you can disable RX checksum offloading and see whether that makes any difference. Since I have no longer access to the hardware it would be even better if you can tell me which traffic pattern triggered 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"
Re: igb(4) won't start with "igb0: Could not setup receive structures"
On Wed, Mar 30, 2011 at 1:10 PM, Doug Barton wrote: > On 3/30/2011 10:06 AM, Arnaud Lacombe wrote: >> >> No. We are taking about exceptional recoverable situation not handled >> by the software, it should not bring the complete system down. If >> you're swapping code has defect, you do not tell one to buy more RAM >> not to trigger the defective code, you fix the code. The situation is >> similar here. > > I understand that you believe the situations to be similar, however you may > make your point more clearly if you share the patches you've developed with > the list so that others can review/comment/etc. > The patch has been posted on the list, please search in the archives. - Arnaud ___ 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: igb(4) won't start with "igb0: Could not setup receive structures"
Hi, On Wed, Mar 30, 2011 at 1:12 PM, Jack Vogel wrote: > The code that got put in the driver has a response to this "unrecoverable > situation", you've flamed me and the code, but you've not demonstrated it > does not work. > I did, in "Message-ID: ". If you want to talk code, please tell me where I was wrong. To sum up, the current code relies on em_rxeof() to refresh mbufs. This path is triggered on RX interrupt which never happen if the RX ring is empty. Now the question I ask you is technical, no criticize at all of any kind: how do you refresh the mbufs' ring if no RX interrupt is ever triggered because the card has no descriptor left at all in its ring ? Regards, - Arnaud ___ 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: igb(4) won't start with "igb0: Could not setup receive structures"
Hi, Maybe you're right. OK, let's return default hw.igb.rxd to 256. It seems to be enough for stable work and driver is used less memory. BTW, on the man page igb(4) still written that hw.igb.rxd equals to 256 by default. -- Andrey Zonov 30.03.2011 18:33, Arnaud Lacombe пишет: Hi, On Wed, Mar 30, 2011 at 1:58 AM, Andrey Zonov wrote: My point is if you're using machine with 8 CPUs than maxusers/clusters/9k mbufs should have been increased by system, because on this machine minimum 2Gb memory is available. I am doubtful that the number of CPU[0] or number of users (yes, I know `maxusers' is currently used to compute the default `nmbcluster'...) can be linked to any network load pattern at all. You can have a 24 CPU machine made for 4096 users with a single NIC, not requiring much memory, while a 1 CPU machine with only 1 users can have +8 NIC and require a huge quantity of memory. Available KVM space should also be taken into account, as it is rather limited on i386. - Arnaud [0]: even more today where you can have a huge number of virtual CPU. ___ 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: igb(4) won't start with "igb0: Could not setup receive structures"
Read the code in HEAD, em_local_timer() has a test of ALL the rx queues and will schedule a task that refreshes mbufs if they are empty. This has exactly the same effect as checking for some interrupt cause, a cause that is not available when using MSIX on 82574, but this approach works for everything. Jack On Wed, Mar 30, 2011 at 10:55 AM, Arnaud Lacombe wrote: > Hi, > > On Wed, Mar 30, 2011 at 1:12 PM, Jack Vogel wrote: > > The code that got put in the driver has a response to this "unrecoverable > > situation", you've flamed me and the code, but you've not demonstrated it > > does not work. > > > I did, in "Message-ID: > ". If > you want to talk code, please tell me where I was wrong. > > To sum up, the current code relies on em_rxeof() to refresh mbufs. > This path is triggered on RX interrupt which never happen if the RX > ring is empty. Now the question I ask you is technical, no criticize > at all of any kind: how do you refresh the mbufs' ring if no RX > interrupt is ever triggered because the card has no descriptor left at > all in its ring ? > > Regards, > - Arnaud > ___ 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"
UDP on FreeBSD
Hi All, I want to check UDP on FreeBSD. I am using IPERF on FreeBSD for wireless testing with Proxim 8470 FC PCMCIA card on IBM T42 and T61. When I'm transmitting data from FreeBSD to FreeBSD or CentOS using Iperf with -u -b 100M on iperf, they had lost lots of packets. Sniffer near the two nodes shows the sender could not send all packets. Iperf sender said that they try to send 85469 packets but they lost 68824 packets. I think that the UDP buffer on the sender could not handle all packets. But if I'm trying to send data from CentOS to FreeBSD using Iperf with -u -b 100M option on iperf, the sender tries 18636 packets so they lost few packets like 1 or 2 packets.As a result, they have similar bandwidth result on the report. I think that it happens from different implement between FreeBSD and Linux. But I want to double check that this is normal for FreeBSD or not. If I have some missing points, let me know please. Thank you! ___ 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: Kernel memory corruption(?) with age(4)
On Wed, 30 Mar 2011, YongHyeon PYUN wrote: On Wed, Mar 30, 2011 at 04:22:23PM +0200, Yamagi Burmeister wrote: All for boxes are unstable if the Attansic NIC is in use, no one of them survived more than 60 minutes of ~20mb/s network traffic. I managed to get some coredumps and extracted the backtraces. Since everytime one of the boxes paniced I got different panic message and a different backtrace with a different subsystem involved I suspected broken hardware. I plugged a em(4) NIC into the PCI slot and wasn't able to reproduce the problem, in fact the boxes run rock solid for several days. Next I set up a Windows 7, installed the Attansic vendor driver and did another run. All went smooth, no crash for nearly 24 hours. My guess is kernel memory corruption by age(4), which would explain all the different backtraces and the different panic messages. This problem is reproducible in at least FreeBSD 7.4 and 8.2 and with TSO4 enabled and disabled. I'm willing to debug this, but I really don't know how. So any help or a pointer into the right direction would be appreciated. AFAIK this is the first report for possible memory corruption triggered by age(4). I'm still not sure whether it's caused by age(4) but you can disable RX checksum offloading and see whether that makes any difference. Since I have no longer access to the hardware it would be even better if you can tell me which traffic pattern triggered the issue. Okay, I did a test run with RX checksum, TX checksum and both disabled. In all three cases the crash occurs within about 20 minutes. I'm either not sure that age(4) is the problem but it has definedly something to do with the problem, since with another nic driver the same scenario is rock solid... The workload: It's a NFS3 server (FreeBSDs non-experimental implementation), serving and receiving file with about 250 to 500 megabytes at about 20mb/s. The clients are FreeBSD 7 and 8 systems and are mounting the shares via TCP. The connection is 1000mbit/s via a "dumb" gigabit switch. -- Homepage: www.yamagi.org Jabber: yam...@yamagi.org GnuPG/GPG:0xEFBCCBCB ___ 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: Kernel memory corruption(?) with age(4)
On Wed, Mar 30, 2011 at 09:50:12PM +0200, Yamagi Burmeister wrote: > On Wed, 30 Mar 2011, YongHyeon PYUN wrote: > > >On Wed, Mar 30, 2011 at 04:22:23PM +0200, Yamagi Burmeister wrote: > > > >>All for boxes are unstable if the Attansic NIC is in use, no one of them > >>survived more than 60 minutes of ~20mb/s network traffic. I managed to > >>get some coredumps and extracted the backtraces. Since everytime one of > >>the boxes paniced I got different panic message and a different backtrace > >>with a different subsystem involved I suspected broken hardware. I > >>plugged a em(4) NIC into the PCI slot and wasn't able to reproduce the > >>problem, in fact the boxes run rock solid for several days. Next I set > >>up a Windows 7, installed the Attansic vendor driver and did another > >>run. All went smooth, no crash for nearly 24 hours. > >> > >>My guess is kernel memory corruption by age(4), which would explain all > >>the different backtraces and the different panic messages. This problem > >>is reproducible in at least FreeBSD 7.4 and 8.2 and with TSO4 enabled > >>and disabled. I'm willing to debug this, but I really don't know how. So > >>any help or a pointer into the right direction would be appreciated. > >> > > > >AFAIK this is the first report for possible memory corruption > >triggered by age(4). I'm still not sure whether it's caused by > >age(4) but you can disable RX checksum offloading and see whether > >that makes any difference. > >Since I have no longer access to the hardware it would be even > >better if you can tell me which traffic pattern triggered the > >issue. > > Okay, I did a test run with RX checksum, TX checksum and both disabled. > In all three cases the crash occurs within about 20 minutes. I'm either > not sure that age(4) is the problem but it has definedly something to do > with the problem, since with another nic driver the same scenario is > rock solid... > OK. > The workload: It's a NFS3 server (FreeBSDs non-experimental > implementation), serving and receiving file with about 250 to 500 > megabytes at about 20mb/s. The clients are FreeBSD 7 and 8 systems and > are mounting the shares via TCP. The connection is 1000mbit/s via a > "dumb" gigabit switch. > That's too broad to narrow down the issue. :-( I'm not sure but your box seem to have more than 4GB memory. Could you limit the available memory to 3GB via loader.conf and test it again? ___ 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"
net80211 and interface requests
Hello, This list has helped me before so I'll email again with the hopes that somebody has an answer. All is working well with my project, however for the life of me I cannot get the interface to inject the raw frames faster than 11mbps. I'm following the example given in /usr/src/tools/tools/net80211/wlaninject.c, and manually specifying parameters such as ucastrate, mcastrate, and mgmtrate within ifconfig. I'm putting the card into pureg mode, and yet I still can't inject any faster. I've even gone so far as to specify an ieee802211_txparam struct giving values of 255 both mcast and ucast rates within the struct (and of course anding them by 0xff). I then used the ioctl call to set the flags within the interface request. Any help would be greatly appreciated. I am doing nanosleeps in between transmissions as if I don't the bpf clone can't inject due to the buffer being too full. There's probably a better way of doing this, but I doubt the nanosleeps are the issue (afterall, I get almost exactly 11mbps). I should probably note I'm not doing any ACKs, this is pure transmits. If anybody cares enough to look at my unpolished code to get a better idea, look here: http://projhinternet.svn.sourceforge.net/ The idea is to allow unidirectional traffic so that with an FCC amateur license (yes I know I'm not currently broadcasting the call sign as of yet) you can broadcast unencrypted transmissions for miles (with a linear amplifier spec'd to 2.4ghz). With the license FCC part15 no longer applies and you can operate just like in any other amateur band. ___ 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: UDP on FreeBSD
On Wed, Mar 30, 2011 at 3:43 PM, Kyungsoo Lee wrote: > Hi All, > > I want to check UDP on FreeBSD. > > I am using IPERF on FreeBSD for wireless testing with Proxim 8470 FC PCMCIA > card on IBM T42 and T61. > > When I'm transmitting data from FreeBSD to FreeBSD or CentOS using Iperf > with -u -b 100M on iperf, they had lost lots of packets. Sniffer near the > two nodes shows the sender could not send all packets. Iperf sender said > that they try to send 85469 packets but they lost 68824 packets. I think > that the UDP buffer on the sender could not handle all packets. > > But if I'm trying to send data from CentOS to FreeBSD using Iperf with -u -b > 100M option on iperf, the sender tries 18636 packets so they lost few > packets like 1 or 2 packets.As a result, they have similar bandwidth result > on the report. I think that it happens from different implement between > FreeBSD and Linux. > > But I want to double check that this is normal for FreeBSD or not. If I have > some missing points, let me know please. > > Thank you! > ___ > 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" > Just a guess, but have you tried adjusting the net.inet.udp.maxdgram sysctl? I believe the default is somewhat low for UDP transmit. I don't know what size packets iperf is using but increasing the maxdgram value might help your testing. -Proto ___ 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"
