We've experienced very high packet loss when using latest
compat-wireless witth iwlwifi driver over 2.6.24 and 2.6.25 stable
kernels. This is not happening with 2.6.26-rc3 as a target kernel (not
sure about rc1 and rc2)
The traffic is UDP TX with large tx buffers ~26000.
We are still investigating yet if someone has any idea please share with us.
Thanks
Tomas
On Fri, Jun 27, 2008 at 11:00 PM, Luis R. Rodriguez <[email protected]> wrote:
> On Thu, Jun 26, 2008 at 4:03 PM, Tomas Winkler <[email protected]> wrote:
>> We've experienced very high packet loss when using latest
>> compat-wireless witth iwlwifi driver over 2.6.24 and 2.6.25 stable
>> kernels. This is not happening with 2.6.26-rc3 as a target kernel (not
>> sure about rc1 and rc2)
>> The traffic is UDP TX with large tx buffers ~26000.
>> We are still investigating yet if someone has any idea please share with us.
>
> I can't think of anything off the top of my head, really...
This is something in the network stack. This is also happening with
ethernet USB devices. Something between 2.6.25 and 2.6.26-rc3 has
fixed it.
Have to find what otherwise all the compat-wireless will be unusable for us
Thanks for the answer anyway.
Tomas.
More info on the issue.. The problem is with TX of unrestrained UDP
stream, when the traffic generated at the application layer is larger
than the link can pass. With kernel 2.6.26-* the traffic is restrained
when the TX FIFOs gets full while in 2.6.25.* frames are dropped at
some layer. It seems that the drop happens after the IP fragmentation
step at the stack.
Thanks,
Guy.
On 6/27/08, Tomas Winkler <[email protected]> wrote:
> We've experienced very high packet loss when using latest
> compat-wireless witth iwlwifi driver over 2.6.24 and 2.6.25 stable
> kernels. This is not happening with 2.6.26-rc3 as a target kernel (not
> sure about rc1 and rc2)
> The traffic is UDP TX with large tx buffers ~26000.
> We are still investigating yet if someone has any idea please share with us.
> Thanks
> Tomas
On Thu, Jun 26, 2008 at 4:03 PM, Tomas Winkler <[email protected]> wrote:
> We've experienced very high packet loss when using latest
> compat-wireless witth iwlwifi driver over 2.6.24 and 2.6.25 stable
> kernels. This is not happening with 2.6.26-rc3 as a target kernel (not
> sure about rc1 and rc2)
> The traffic is UDP TX with large tx buffers ~26000.
> We are still investigating yet if someone has any idea please share with us.
I can't think of anything off the top of my head, really...
Luis
On Sun, 2008-06-29 at 09:23 +0300, Guy Cohen wrote:
> More info on the issue.. The problem is with TX of unrestrained UDP
> stream, when the traffic generated at the application layer is larger
> than the link can pass. With kernel 2.6.26-* the traffic is restrained
> when the TX FIFOs gets full while in 2.6.25.* frames are dropped at
> some layer. It seems that the drop happens after the IP fragmentation
> step at the stack.
does compat use multiqueue now? if not, look in the mac80211 fake mq
code.
johannes
On Mon, Jun 30, 2008 at 2:09 PM, Johannes Berg
<[email protected]> wrote:
> On Sun, 2008-06-29 at 09:23 +0300, Guy Cohen wrote:
>> More info on the issue.. The problem is with TX of unrestrained UDP
>> stream, when the traffic generated at the application layer is larger
>> than the link can pass. With kernel 2.6.26-* the traffic is restrained
>> when the TX FIFOs gets full while in 2.6.25.* frames are dropped at
>> some layer. It seems that the drop happens after the IP fragmentation
>> step at the stack.
>
> does compat use multiqueue now? if not, look in the mac80211 fake mq
> code.
2.6.25 has a real mq
Thanks
Tomas
On Fri, Jun 27, 2008 at 5:46 PM, Tomas Winkler <[email protected]> wrote:
> On Fri, Jun 27, 2008 at 11:00 PM, Luis R. Rodriguez <[email protected]> wrote:
>> On Thu, Jun 26, 2008 at 4:03 PM, Tomas Winkler <[email protected]> wrote:
>>> We've experienced very high packet loss when using latest
>>> compat-wireless witth iwlwifi driver over 2.6.24 and 2.6.25 stable
>>> kernels. This is not happening with 2.6.26-rc3 as a target kernel (not
>>> sure about rc1 and rc2)
>>> The traffic is UDP TX with large tx buffers ~26000.
>>> We are still investigating yet if someone has any idea please share with us.
>>
>> I can't think of anything off the top of my head, really...
>
> This is something in the network stack. This is also happening with
> ethernet USB devices. Something between 2.6.25 and 2.6.26-rc3 has
> fixed it.
> Have to find what otherwise all the compat-wireless will be unusable for us
> Thanks for the answer anyway.
Either way if you try to port wireless-testing drivers to 2.6.25
you'll probably end up using the same things on compat-wirelesss or
just slightly modified, so if there is an issue regardless it can be
fixed through compat-wireless. Just my $0.02 Rupees.
Luis
On Mon, Jun 30, 2008 at 4:29 AM, Tomas Winkler <[email protected]> wrote:
> On Mon, Jun 30, 2008 at 2:09 PM, Johannes Berg
> <[email protected]> wrote:
>> On Sun, 2008-06-29 at 09:23 +0300, Guy Cohen wrote:
>>> More info on the issue.. The problem is with TX of unrestrained UDP
>>> stream, when the traffic generated at the application layer is larger
>>> than the link can pass. With kernel 2.6.26-* the traffic is restrained
>>> when the TX FIFOs gets full while in 2.6.25.* frames are dropped at
>>> some layer. It seems that the drop happens after the IP fragmentation
>>> step at the stack.
>>
>> does compat use multiqueue now? if not, look in the mac80211 fake mq
>> code.
>
> 2.6.25 has a real mq
We only use fake mq support for kernels <= 2.6.22 as 2.6.23 added
support for MQ. Also if your 2.6.23 doesn't have MQ it will warn you.
Luis
On Tue, Jul 1, 2008 at 12:29 PM, Luis R. Rodriguez <[email protected]> wrote:
> On Mon, Jun 30, 2008 at 4:29 AM, Tomas Winkler <[email protected]> wrote:
>> On Mon, Jun 30, 2008 at 2:09 PM, Johannes Berg
>> <[email protected]> wrote:
>>> On Sun, 2008-06-29 at 09:23 +0300, Guy Cohen wrote:
>>>> More info on the issue.. The problem is with TX of unrestrained UDP
>>>> stream, when the traffic generated at the application layer is larger
>>>> than the link can pass. With kernel 2.6.26-* the traffic is restrained
>>>> when the TX FIFOs gets full while in 2.6.25.* frames are dropped at
>>>> some layer. It seems that the drop happens after the IP fragmentation
>>>> step at the stack.
>>>
>>> does compat use multiqueue now? if not, look in the mac80211 fake mq
>>> code.
>>
>> 2.6.25 has a real mq
>
> We only use fake mq support for kernels <= 2.6.22 as 2.6.23 added
> support for MQ. Also if your 2.6.23 doesn't have MQ it will warn you.
We did some more black box testing and this is happening only in UDP
streaming. TCP is okay.
Again this bug is not present in 2.6.26-rc3 and up.
Thanks
Tomas