Re: Experiencing very slow browsing at times (atheros wireless)

["Sepherosa Ziehau" <sepherosa@xxxxxxxxx>]

On 5/26/07, Sten Daniel Soersdal <netslists@gmail.com> wrote:
> Petr Janda wrote:
> > Sepherosa Ziehau wrote:
> >>
> >> Haha, the AP is broken.  Its does not use single TX seq (as required
> >> by 802.11-1999 R2003, same as 802.11e for non-Qos data and bcast mgt)
> >> for data and mgt packets.  Your AP seems to use one TX seq for beacon
> >> (99% of mgt packets) and another TX seq for data.  That also explains
> >> why using lower rate will have better result: number of retries is
> >> reduced and duplication detection is performed only on retried
> >> packets.
> >>
> >> Please test following patch and see whether it makes the situation
> >> better in 11g mode:
> >> http://leaf.dragonflybsd.org/~sephe/skip_beacon.diff
> >>
> >>
> > Testing now, will let you know of success or failure within the next day
> > or two. If this worked out to be the fix, I shall call you Sir Genius
> > from now on :D
> >
> > Thanks!!!
> > Petr
> >
>
> Hopefully that will fix it. I'm a little puzzled by the tcp
> conversations here. The remote server advertises an mss of 1420 (which
> indicates an MTU of 1440) but the packets you receive is of size 1452

Mmm, I think the MTU advertised by the remote server is 1460 (mss +
ip_hdr + tcp_hdr)

> (which translates to mss 1432) indicating that mss is adjusted along the

mss indicates that advertiser wants to receive in that size.  It is
used to limit the segment size of other side.  The mss advertised by
us is larger than server's mss, then I think whether the server want
to contraint the segment size to its own mss depends on server's TCP
implementation.

Best Regards,
sephe

--
Live Free or Die