Re: Atheros, hardware access layer, collisions

From: David Malone (dwmalone_at_maths.tcd.ie)
Date: 07/21/05

  • Next message: Andrey V. Elsukov: "Re: Ancient FreeBSD releases online"
    Date: Thu, 21 Jul 2005 07:36:06 +0100
    To: Sam Pierson <samuel.pierson@gmail.com>
    
    

    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?

            David.
    _______________________________________________
    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: Andrey V. Elsukov: "Re: Ancient FreeBSD releases online"

    Relevant Pages

    • Re: what the 10 year old wants on Solaris x86 .. games games games !
      ... transmitting full data packets or simply TCP acknowledgements). ... every station is supposed to listen first ... When a station detects a collision ...
      (comp.unix.solaris)
    • Re: TCP keepalive timer problem
      ... the normal retransmission takes place and no further keepalive probe will be sent. ... We tried TCP implementation on Windows XP SP3, the keepalive and retransmission don't intervene. ... I found one problem in Linux TCP keepalive timer processing, ... Keep-alive packets MUST only be sent when no data or acknowledgement packets have ...
      (Linux-Kernel)
    • patch to implement RFC3517 in linux 2.4.22
      ... This modifies how packets which fail to be sacked are marked as lost. ... The new code marks packets in sack holes as lost as ... should lead to faster retransmission and recovery when multiple drops occur. ...
      (Linux-Kernel)
    • Re: Long Range Wireless Network
      ... packet acknowledgement or retransmission. ... The automatic-retransmission timeouts in the cards are set to a fairly ... If the transmitting card's timeout value is set to less ... received packets will be forwarded to their destination, ...
      (rec.radio.amateur.homebrew)
    • Re: Ethernet Chip Suggestion
      ... These runts with bad CRC indicate the collision on LAN. ... short packets could not be captured. ...
      (comp.arch.embedded)