this is an interesting observation. We might have a problem on the rx
handling of short preambles. I believe tx should be fine, because it
is pretty straight forward. This is something we have to look into.
Am 29.12.2006 um 00:11 schrieb Jon Smirl:
> On 12/28/06, Daniel Drake <[EMAIL PROTECTED]> wrote:
>> Jon Smirl wrote:
>> > First thing I need to figure out is why I can't finish a 250MB copy
>> > over pure 802.11g without dropping the connection. I am getting
>> > hundreds of these in the logs:
>> > kernel: usb 5-1.3: handle_retry_failed_int() retry failed interrupt
>> This interrupt occurs when the device failed to transmit a unicast
>> frame. It retries several times (and gives us an interrupt for each
>> retry) and then sends a final interrupt saying that it's given up.
>> definition of "failed to transmit" is "did not receive an ACK
>> within a
>> predefined timeframe".
>> It has nothing to do with software or protocol retry. Lowering the
>> would be a sensible experiment.
> If the 802.11 MAC fails to transmit the frame or signals an error
> because of a missing MAC level ack, then TCP will do the retry at
> layer 4. That's part of the sliding window code in the TCP/IP
> protocol. Retries at the TCP layer can be pretty slow.
> I tried all rates from 18M to 54M and couldn't get a 250MB copy
> without dropping the link. That was with the router set to 802.11g
> only. If I turn on 802.11bg the copy works every time. Dropping the
> link means that there were so many retries that TCP closed the socket
> and caused the layer 7 SMB copy to fail.
> So why am I dropping so many packets with the router at 802.11g and
> not with the router at 802.11bg? I'll record a session with Ethereal
> and see if it gives me any clues.
> I just noticed my Nokia 770 sitting on my desk in sleep mode. It may
> be waking up and causing interference I'll turn it off and do some
> more experiments. Nokia 770 is 802.11bg so it's not likely causing
>> > The nodes in my test are 5ft apart with 100% strength, 99%
>> quality at
>> > 54M on a clear channel. I would hope that they can exchange packets
>> > without dropping them.
>> Pay little attention to the strength/quality values, they are very
> Jon Smirl
> [EMAIL PROTECTED]
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
Zd1211-devs mailing list - http://zd1211.ath.cx/