Re: Atheros, hardware access layer, collisions

From: Sam Pierson (samuel.pierson_at_gmail.com)
Date: 07/21/05

  • Next message: P.ArulChandran: "IPv4 Link Local support in FreeBSD" 
    Date: Thu, 21 Jul 2005 08:21:37 -0500
To: David Malone <dwmalone@maths.tcd.ie>

    On 7/21/05, David Malone <dwmalone@maths.tcd.ie> wrote:
    > On Wed, Jul 20, 2005 at 10:03:49PM -0500, Sam Pierson wrote:
    > > I think there is still collision detection happening on the hardware
    > > level. I think I have to disable the retransmission of frames
    > > which are lost due to collisions. Here's my reasoning: In the lab, two
    > > hosts are sending packets to the middle guy at the same time.
    > > After examining the traffic on the middle guy, one packet will
    > > arrive before the other one (sometimes in different order) and
    > > the second packet comes 500-1200us after the first. From this,
    > > I think some retransmission is happening because of collision,
    > > since the results are seemingly random.
    >
    > Since introducing random delays before transmission and using carrier
    > sensing are basic features of the 802.11 MAC, I'd be suprised if
    > you can stop the hardware doing it. To reduce the effects as much
    > as possible, you could try trying to reduce the number of retransmission
    > attempts and changing the cwmin parameter to be small. Even if you
    > do this, you'll still need to transmit the packets quite close to
    > one another (probably within 20us) to avoid the carrier sense stuff
    > kicking in.
    >
    > What effect are you trying to achieve?
    I've got two computers synchronized to send one packet each to this
    machine sitting between them. This machine responds with a packet
    to each that it receives (on the application level, not in the control frame
    space), so if there is a collision, I don't want the middle machine to
    respond and I don't want the senders to retransmit when they don't
    receive an ACK control frame after they send their data packet (again,
    this packet is up on the transport layer, so more control frames might
    be sent). Normal operation (regular connectivity) is not needed on the
    two senders, so screwing up their retransmission scheme isn't a problem.

    -Sam
    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

  • Next message: P.ArulChandran: "IPv4 Link Local support in FreeBSD"

    Relevant Pages

    • Atheros, hardware access layer, collisions
      ... I'm working on a project that requires creating a single packet ... packets, creating a collision. ... hosts are sending packets to the middle guy at the same time. ... I think some retransmission is happening because of collision, ...
      (freebsd-hackers)
    • Re: Very rapid polling
      ... Authorised Server every 300ms on our LAN. ... sending this same packet every 300-500ms. ... you usually get retransmission on collision from the hardware. ... Remember that NTP uses UDP. ...
      (comp.protocols.time.ntp)
    • slow tps on NetWare
      ... databases. ... C Clear Physical Record[Unreassembled Packet] ... [TCP ... Retransmission] R OK ...
      (comp.lang.clarion)
    • Re: Very rapid polling
      ... Authorised Server every 300ms on our LAN. ... sending this same packet every 300-500ms. ... this might help (look for collision .. ... Remember that NTP uses UDP. ...
      (comp.protocols.time.ntp)
    • Re: Telnet over WAN latency troubleshooting
      ... > we've also tried the old culprit SET PROTO TCP/NODELAY with no ... > with 1200 byte packets I see zero packet loss except for peak time ... was at least one retransmission. ... > I need to find out if there's any way to get telnet to work more ...
      (comp.os.vms)
    Loading