Re: wi problem with message > 7400 bytes

From: Daniel Eischen (eischen_at_vigrid.com)
Date: 10/31/03

  • Next message: YONETANI Tomokazu: "Re: lots of "exclusive sleep mutex"" 
    Date: Fri, 31 Oct 2003 02:44:31 -0500 (EST)
To: Lars Eggert <larse@ISI.EDU>

    On Thu, 30 Oct 2003, Lars Eggert wrote:

    > Daniel Eischen wrote:
    > >>
    > >>Could you post a tcpdump for each case? I wonder if this is related to a
    > >>fragmentation issue I've seen in the past.
    > >
    > > 22:46:43.513038 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52198:1480@0+)
    > > 22:46:48.522475 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52199:1480@0+)
    > > 22:46:53.532018 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52200:1480@0+)
    > > 22:46:58.541178 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52201:1480@0+)
    > > 22:47:03.553048 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52202:1480@0+)
    > > 22:47:08.568862 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52203:1480@0+)
    > > 22:47:13.583328 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52204:1480@0+)
    > > 22:47:18.578512 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52205:1480@0+)
    > > 22:47:23.609098 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52206:1480@0+)
    > > 22:47:28.597680 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52207:1480@0+)
    > > 22:47:33.607059 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52208:1480@0+)
    >
    > It's not what I've seen in the past - but also pretty strange! Only the
    > first fragment seems to be received. Wonder what happened to the other
    > fragments...
    >
    > If you tcpdump on gpz, does the output look the same? Also, you may want

    I'll try that tomorrow. gpz is a Sun Solaris 9 box at work, but
    before you say "try another BSD box", I already did. I tried
    2 other FreeBSD boxes in place of gpz and I had the same results.

    > to run the tcpdump without a filter (if you don't do this already) to
    > see if the other fragments show up as corrputed frames or something.
    >
    > (As an aside, fragmentation on a lossy link compounds throughput issues,
    > but of course you know that already.)

    Everything is behind Cisco 10/100 switches and doing 10/100
    full duplex except for the laptop (vespa) which is through
    a Dell TrueMobile wireless access point. The access point
    is connected to a switch and is about 10 feet away from the
    laptop.

    I tried this test at home with a different setup:

      orion - laptop with D-Link DWL-650H PC-Card (wi)
      sirius - FreeBSD current box with em interface
      Linksys WRT-54g router/access point with builtin 10/100 switch

    There is no other traffic on this network; orion and sirius
    are standalone. sirius is wired to a 10/100 port in the
    router/access point and is at 100 full-duplex.

    Repeating the same test lets me send messages up to 25152
    bytes in length, much better than 7400. This seems to be
    about the same limit I hit in VxWorks (which supposedly
    has the BSD 4.4 IP stack).

    I'll see if I can get my hands on a different access point
    at work to see if that makes a difference. Here's the
    tcpdump from the above setup with message size 25153:

    05:27:59.632708 sirius.49245 > orion-home.12345: udp 25153 (frag 19970:1480@0+)
    05:27:59.815829 sirius > orion-home: udp (frag 19970:1480@1480+)
    05:28:00.023248 sirius > orion-home: udp (frag 19970:1480@2960+)
    05:28:00.216317 sirius > orion-home: udp (frag 19970:1480@4440+)
    05:28:00.404066 sirius > orion-home: udp (frag 19970:1480@5920+)
    05:28:00.583116 sirius > orion-home: udp (frag 19970:1480@7400+)
    05:28:00.777315 sirius > orion-home: udp (frag 19970:1480@8880+)
    05:28:00.950056 sirius > orion-home: udp (frag 19970:1480@10360+)
    05:28:01.129616 sirius > orion-home: udp (frag 19970:1480@11840+)
    05:28:01.327645 sirius > orion-home: udp (frag 19970:1480@13320+)
    05:28:01.560564 sirius > orion-home: udp (frag 19970:1480@14800+)
    05:28:01.769612 sirius > orion-home: udp (frag 19970:1480@16280+)
    05:28:01.945923 sirius > orion-home: udp (frag 19970:1480@17760+)
    05:28:02.128897 sirius > orion-home: udp (frag 19970:1480@19240+)
    05:28:02.309202 sirius > orion-home: udp (frag 19970:1480@20720+)
    05:28:02.514941 sirius > orion-home: udp (frag 19970:1480@22200+)
    05:28:02.731612 sirius > orion-home: udp (frag 19970:1480@23680+)
    05:28:02.907988 sirius > orion-home: udp (frag 19970:1@25160)
    05:28:07.982121 sirius.49245 > orion-home.12345: udp 25153 (frag 20226:1480@0+)
    05:28:08.150171 sirius > orion-home: udp (frag 20226:1480@1480+)
    05:28:08.357960 sirius > orion-home: udp (frag 20226:1480@2960+)
    05:28:08.551270 sirius > orion-home: udp (frag 20226:1480@4440+)
    05:28:08.754906 sirius > orion-home: udp (frag 20226:1480@5920+)
    05:28:08.953891 sirius > orion-home: udp (frag 20226:1480@7400+)
    05:28:09.145286 sirius > orion-home: udp (frag 20226:1480@8880+)
    05:28:09.365111 sirius > orion-home: udp (frag 20226:1480@10360+)
    05:28:09.577964 sirius > orion-home: udp (frag 20226:1480@11840+)
    05:28:09.795675 sirius > orion-home: udp (frag 20226:1480@13320+)
    05:28:09.973760 sirius > orion-home: udp (frag 20226:1480@14800+)
    05:28:10.167432 sirius > orion-home: udp (frag 20226:1480@16280+)
    05:28:10.362543 sirius > orion-home: udp (frag 20226:1480@17760+)
    05:28:10.559922 sirius > orion-home: udp (frag 20226:1480@19240+)
    05:28:10.775048 sirius > orion-home: udp (frag 20226:1480@20720+)
    05:28:10.937800 sirius > orion-home: udp (frag 20226:1480@22200+)
    05:28:11.115078 sirius > orion-home: udp (frag 20226:1480@23680+)
    05:28:11.300522 sirius > orion-home: udp (frag 20226:1@25160) 

    -- 
Dan Eischen
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
  • Next message: YONETANI Tomokazu: "Re: lots of "exclusive sleep mutex""

    Relevant Pages

    • Re: Bad performance of 7.0 nfs client with Solaris nfs server
      ... this is expected and things will work but there is extra latency ... Or, if your switch and NICs support it, see whether you can get Gb ... Ethernet jumbo frames working so that you don't have to fragment for ... But there is a bit more overhead with TCP transport than UDP-- for local networks, UDP generally seems to be a win...TCP seems to be a better choice over a VPN or some similar kind of WAN. ...
      (freebsd-performance)
    • Re: optimizing an expression
      ... Switch to TRUE style; you can save 3 lines just ... by placing the braces correctly in your fragment. ... personal code, please watch your C language here: ... As you will since you're not using True Style. ...
      (comp.lang.c)