Hello, It sounds weird but tcp/ip traffic directed to _local_ interfaces, and only _local_ interfaces, always cause 50% of packets lost. Of course there isn't packet filters activated. I'm running -stable (the last update was this past weekend) There is another report like this: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/72022 but the suggested solution doesn't works in my case. ping to local interfaces get replies for 50% of the packets:> ping -c 512 127.0.0.1[snip] --- 127.0.0.1 ping statistics --- 512 packets transmitted, 257 packets received, 49% packet loss round-trip min/avg/max/stddev = 0.046/0.049/0.077/0.004 ms> ping -c 512 10.20.30.2[snip] --- 10.20.30.2 ping statistics --- 512 packets transmitted, 254 packets received, 50% packet loss round-trip min/avg/max/stddev = 0.017/0.049/0.071/0.004 ms Also running tcpdump on localhost shows as the kernel stop from responding to packets without an apparent motive.> tcpdump -n -i lo0tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo0, link-type NULL (BSD loopback), capture size 96 bytes [snip] 17:58:15.516451 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq 76 17:58:15.516476 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo reply seq 76 17:58:16.517321 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq 77 17:58:16.517347 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo reply seq 77 17:58:17.518158 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq 78 17:58:18.519042 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq 79 17:58:19.519853 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq 80 17:58:20.520698 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq 81 17:58:21.521548 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq 82 17:58:22.522392 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq 83 more tests, to the lan router:> ping -c 500 10.20.30.6[snip] --- 10.20.30.6 ping statistics --- 500 packets transmitted, 500 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.565/2.015/40.189/2.385 ms from the lan router: Router#ping Protocol [ip]: Target IP address: 10.20.30.2 Repeat count [5]: 500 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 500, 100-byte ICMP Echos to 10.20.30.2, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!! Success rate is 99 percent (498/500), round-trip min/avg/max = 1/2/12 ms I don't find any explanation for this, but I'd like to know if there is any solution? Thank you. I put the whole test (dmesg, make.conf, etc)in this URL so you can see all numbers. http://195.55.55.164/tests/FreeBSD/report.txt -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/IT d- s+:+() a- C+++ UBL+++$ P+ L+++ E--- W++ N+ o++ K- w--- O+ M+ V- PS+ PE+ Y++ PGP+>+++ t+ 5 X+$ R- tv-- b+++ DI D++>+++ G++ e- h+(++) !r !z ------END GEEK CODE BLOCK------
Have tested on 3 boxes. 5.3-STABLE compiled Jan 5th --- 127.0.0.1 ping statistics --- 61 packets transmitted, 61 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.062/0.073/0.146/0.013 ms 5.3-STABLE amd64 build compiled Jan 29th --- 127.0.0.1 ping statistics --- 60 packets transmitted, 60 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.024/0.030/0.048/0.005 ms 5.3-Release-P5 --- 127.0.0.1 ping statistics --- 60 packets transmitted, 60 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.057/0.089/0.167/0.017 ms On Mon, 31 Jan 2005 19:12:52 +0100, Jos? M. Fandi?o <freebsd4@fadesa.es> wrote:> Hello, > > It sounds weird but tcp/ip traffic directed to _local_ interfaces, > and only _local_ interfaces, always cause 50% of packets lost. Of > course there isn't packet filters activated. > > I'm running -stable (the last update was this past weekend) > > There is another report like this: > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/72022 > but the suggested solution doesn't works in my case. > > ping to local interfaces get replies for 50% of the packets: > > > ping -c 512 127.0.0.1 > [snip] > --- 127.0.0.1 ping statistics --- > 512 packets transmitted, 257 packets received, 49% packet loss > round-trip min/avg/max/stddev = 0.046/0.049/0.077/0.004 ms > > > ping -c 512 10.20.30.2 > [snip] > --- 10.20.30.2 ping statistics --- > 512 packets transmitted, 254 packets received, 50% packet loss > round-trip min/avg/max/stddev = 0.017/0.049/0.071/0.004 ms > > Also running tcpdump on localhost shows as the kernel stop from > responding to packets without an apparent motive. > > > tcpdump -n -i lo0 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on lo0, link-type NULL (BSD loopback), capture size 96 bytes > [snip] > 17:58:15.516451 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq 76 > 17:58:15.516476 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo reply seq 76 > 17:58:16.517321 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq 77 > 17:58:16.517347 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo reply seq 77 > 17:58:17.518158 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq 78 > 17:58:18.519042 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq 79 > 17:58:19.519853 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq 80 > 17:58:20.520698 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq 81 > 17:58:21.521548 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq 82 > 17:58:22.522392 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq 83 > > more tests, to the lan router: > > > ping -c 500 10.20.30.6 > [snip] > --- 10.20.30.6 ping statistics --- > 500 packets transmitted, 500 packets received, 0% packet loss > round-trip min/avg/max/stddev = 1.565/2.015/40.189/2.385 ms > > from the lan router: > > Router#ping > Protocol [ip]: > Target IP address: 10.20.30.2 > Repeat count [5]: 500 > Datagram size [100]: > Timeout in seconds [2]: > Extended commands [n]: > Sweep range of sizes [n]: > Type escape sequence to abort. > Sending 500, 100-byte ICMP Echos to 10.20.30.2, timeout is 2 seconds: > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!! > Success rate is 99 percent (498/500), round-trip min/avg/max = 1/2/12 ms > > I don't find any explanation for this, but I'd like to know if there is > any solution? > > Thank you. > > I put the whole test (dmesg, make.conf, etc)in this URL so you can see > all numbers. > http://195.55.55.164/tests/FreeBSD/report.txt > > -- > -----BEGIN GEEK CODE BLOCK----- > Version: 3.1 > GCS/IT d- s+:+() a- C+++ UBL+++$ P+ L+++ E--- W++ N+ o++ K- w--- > O+ M+ V- PS+ PE+ Y++ PGP+>+++ t+ 5 X+$ R- tv-- b+++ DI D++>+++ > G++ e- h+(++) !r !z > ------END GEEK CODE BLOCK------ > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >
Jos? M. Fandi?o wrote:> Jon Noack wrote: > >>>> Finally, I found the culprit: >>>>> >>>>> CFLAGS="" \ 100% of the transmited traffic is received >>>>> COPTFLAGS="" / >>>>> >>>>> CFLAGS= -pipe \ 50% of the transmited traffic is received >>>>> COPTFLAGS= -pipe / >>>> > >>> That would be exceedingly strange, because the above two options >>>> are supposed to produce *no differences at all* with the code >>>> generation. >>>> > >>> I'd believe that -O and no -O could behave differently, although >>>> I don't know why you'd want to compile without -O. >>> > >> because by the time I was compiling the system I was no interested >>> in compiler optimizations. Now I prefer a lightly optimized >>> kernel than a system with 50% of packet lost in local interfaces >>> ;-) >> > > -O is the default for -STABLE; anything else might very well cause >> problems. In fact, check out the CFLAGS section of >> /usr/share/examples/etc/make.conf: > > "Note that optimization settings other than -O and -O2 are not >> recommended or supported for compiling the world or the kernel - >> please revert any nonstandard optimization settings to "-O" before >> submitting bug reports without patches to the developers." > > I think this comment was referring to higher optimizations levels > than -O2, anyway removing "-O" shouldn't be so harmful.The explanation I've heard (I have no actual knowledge here, I'm just good at repeating others) is that gcc doesn't compile any ASM with -O0 (which is what you get with CFLAGS="-pipe"). This Breaks Things(tm): http://docs.freebsd.org/cgi/mid.cgi?20020623214947.J84322 kern/52764 is another example: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/52764 More generically it makes sense that gcc treat code differently with -O0 than with -O. With the vast majority of users using -O and different code paths being taken with -O0, it doesn't surprise me at all that there are issues. It should be assumed that nonstandard means exactly what it says: something other than -O (or more recently -O2). If it breaks, try -O. If it's still broken with -O, report away. Regards, Jon P.S. Historically, the reason to use -O0 was for easier debugging. It appears that steps have been taken to ease debugging with -O to the point that it is no longer necessary to use -O0 (with the FreeBSD kernel and world, at least); I don't recall a FreeBSD developer ever asking someone to recompile with -O0 to help solve a problem...