Re: 50% of packets lost only on local interfaces
On Mon, 2005-Feb-07 17:05:39 -0600, Jon Noack wrote: 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 / It would be quite interesting to compare the actual commands that are generated: Capture the buildworld/kernel output and compare the same command in both cases. If the only difference is really just -pipe, then we need to do some more investigating. 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): There used to be inconsistencies in the way gcc handle asm() statements so that it could be difficult to write asm() statement constraints that worked correctly with both -O0, -O1 and -O2 but it never ignored asm() statements. (I haven't looked since about 2.95 so I'm not sure if the 3.x series fixed this problem) http://docs.freebsd.org/cgi/mid.cgi?20020623214947.J84322 The error message quoted in this article refers to the constraint problem above. The problem was not asm() was being ignored (or that incorrect code was generated) but that the compiler incorrectly reported errors (and failed to compile the code). (I recognize that function name - I spent weeks trying to come up with a constraint set that worked with both -O0 and -O1 and eventually gave up). Since you have managed to compile a kernel, I very much doubt you are running into the same problem. kern/52764 is another example: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/52764 Again, this is a fails to compile report, not a generates incorrect code report. The code in question was written on the assumption that the compiler would do dead code removal and gcc -O0 doesn't. More generically it makes sense that gcc treat code differently with -O0 than with -O. By definition, it has to - otherwise the generated code would be the same. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 50% of packets lost only on local interfaces
José M. Fandiño wrote: Chris wrote: Have tested on 3 boxes. yes, it's the intended operation and If I don't see it I don't believe it but it happens. I ever thought it would be possible. 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 / CFLAGS= -O -pipe \ 100% of the transmited traffic is received COPTFLAGS= -O -pipe / The weirdest is that it worked in 5.3-RELEASE and some time later, whilst I was tracking -stable, aplications began to fail local network conections. Simple tests with ping showed me as the kernel receive packets (tcpdump seems to see inbound packets) but ignores exacly 50% of them. This makes any sense to someone? Following the proposed solution for kern/72022 I removed /usr/obj, all possible harmful options in make.conf and compiled world and a GENERIC kernel again without any luck. grep '^[^#]' /etc/make.conf CFLAGS= -pipe COPTFLAGS= -pipe NOPROFILE= true# Avoid compiling profiled libraries X_WINDOW_SYSTEM=xorg PERL_VER=5.8.5 PERL_VERSION=5.8.5 PERL_ARCH=mach NOPERL=yo NO_PERL=yo NO_PERL_WRAPPER=yo SENDMAIL_CFLAGS=-I/usr/local/include -DSTARTTLS -DSASL=2 -DMILTER -DLDAPMAP SENDMAIL_LDFLAGS= -L/usr/local/lib SENDMAIL_LDADD=-lsasl2 -lssl -lcrypto -lldap -llber I'm lost here, any help will be welcome. Regards, 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 [EMAIL PROTECTED] 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: !! !! !!!.!! !! !!
Re: 50% of packets lost only on local interfaces
On Mon, Feb 07, 2005 at 11:15:52AM +0100, Jos? M. Fandi?o wrote: Jos? M. Fandi?o wrote: Chris wrote: Have tested on 3 boxes. yes, it's the intended operation and If I don't see it I don't believe it but it happens. I ever thought it would be possible. 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. Kris pgpt7CQHgFsCG.pgp Description: PGP signature
Re: 50% of packets lost only on local interfaces
Kris Kennaway wrote: On Mon, Feb 07, 2005 at 11:15:52AM +0100, Jos? M. Fandi?o wrote: Jos? M. Fandi?o wrote: Chris wrote: Have tested on 3 boxes. yes, it's the intended operation and If I don't see it I don't believe it but it happens. I ever thought it would be possible. 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 ;-) -- -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 [EMAIL PROTECTED]
Re: 50% of packets lost only on local interfaces
On Mon, Feb 07, 2005 at 11:30:43AM +0100, Jos? M. Fandi?o wrote: Kris Kennaway wrote: On Mon, Feb 07, 2005 at 11:15:52AM +0100, Jos? M. Fandi?o wrote: Jos? M. Fandi?o wrote: Chris wrote: Have tested on 3 boxes. yes, it's the intended operation and If I don't see it I don't believe it but it happens. I ever thought it would be possible. 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. Actually, the only way I can make sense of this is if CFLAGS= uses the default CFLAGS, which is -O -pipe. Kris pgpDmj6aR8qEu.pgp Description: PGP signature
Re: 50% of packets lost only on local interfaces
José M. Fandiño wrote: Kris Kennaway wrote: On Mon, Feb 07, 2005 at 11:15:52AM +0100, Jos? M. Fandi?o wrote: Jos? M. Fandi?o wrote: Chris wrote: Have tested on 3 boxes. yes, it's the intended operation and If I don't see it I don't believe it but it happens. I ever thought it would be possible. 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. Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 50% of packets lost only on local interfaces
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... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 50% of packets lost only on local interfaces
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 50% of packets lost only on local interfaces
Chris wrote: Have tested on 3 boxes. yes, it's the intended operation and If I don't see it I don't believe it but it happens. I ever thought it would be possible. The weirdest is that it worked in 5.3-RELEASE and some time later, whilst I was tracking -stable, aplications began to fail local network conections. Simple tests with ping showed me as the kernel receive packets (tcpdump seems to see inbound packets) but ignores exacly 50% of them. This makes any sense to someone? Following the proposed solution for kern/72022 I removed /usr/obj, all possible harmful options in make.conf and compiled world and a GENERIC kernel again without any luck. grep '^[^#]' /etc/make.conf CFLAGS= -pipe COPTFLAGS= -pipe NOPROFILE= true# Avoid compiling profiled libraries X_WINDOW_SYSTEM=xorg PERL_VER=5.8.5 PERL_VERSION=5.8.5 PERL_ARCH=mach NOPERL=yo NO_PERL=yo NO_PERL_WRAPPER=yo SENDMAIL_CFLAGS=-I/usr/local/include -DSTARTTLS -DSASL=2 -DMILTER -DLDAPMAP SENDMAIL_LDFLAGS= -L/usr/local/lib SENDMAIL_LDADD=-lsasl2 -lssl -lcrypto -lldap -llber I'm lost here, any help will be welcome. Regards, 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 [EMAIL PROTECTED] 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
50% of packets lost only on local interfaces
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 [EMAIL PROTECTED]
