Virtual WiFi on Linux? StarOS Vxworks IX-420 gizmo

[Tom Sharples]

Somewhat relatedly, has anyone out here tested the new StarOS Vxworks 
implementation which they supply embedded on a 2 or 4 Atheros radio IX-420? 
Lonnie has made some fairly remarkable claims as to throughout & adjacent 
channel performance: 11 non-overlapping channels in 2.4 each running 6 mb/s 
net throughput, and even more outstanding performance claims in 5 Ghz. 
Unclear what channel-coding stuff is going on.

I just received this kit from StarOS and it's sitting in my shop with no-one 
here having time to test it at present.

Tom Sharples
President
Qorvus Systems, Inc.
www.qorvus.net
360.243.7371

----- Original Message ----- 
From: "Jim Thompson" <jim at netgate.com>
To: "Dan Searle" <dan.searle at adelix.com>
Cc: "Matthias Lemke" <m at box.li>; <hostap at shmoo.com>
Sent: Thursday, October 20, 2005 5:24 AM
Subject: Re: Virtual WiFi on Linux?


>
> On Oct 20, 2005, at 2:20 AM, Dan Searle wrote:
>
>> Hi,
>>
>> Sorry if I'm using the wrong terms here, please correct me....
>>
>> Thursday, October 20, 2005, 1:06:16 PM, you wrote:
>>
>>
>>>> Then, run 16 separate MAC layers with some kind of modification
>>>> to the
>>>> HAL to share (schedule) the PHY layer between the 16 MAC layers.
>>>>
>>
>>
>>> No, you 'multiplex' 16 instances of the "upper MAC" over a single
>>> instance of the "lower MAC".
>>>
>>
>> But if you just use simple multiplexing, would you not end up with
>> contention between the different upper MAC instances? I'm thinking a
>> more intelligent scheduling scheme would be needed to ensure the 16
>> upper MAC stacks share the lower MAC in a "fair" manner?
>
> Sure, you probably want something like this, so the set of clients on
> one VAP don't dominate the
> transmit queues.
>
>> I.e. if we are the lower MAC and have basically 16 incoming queues of
>> transmit traffic from the 16 upper MACs, how do we decide which frames
>> to transmit first? Do we simply round robin the 16 queue's
> its an approach!
>
>> or would some kind of intelligent scheduling achieve better
>> throughput/sharing
>> of the lower MAC and ultimately the PHY??
>
> now factor in 802.11e (EDCF) and wonder 'why?'  Or perhaps "when?" as
> in "when will the linux 802.11 stack
> have support for 802.11e?
>>
>>>> Received frames are not under our control, so all the scheduler
>>>> would
>>>> have to do is share out the PHY transmit buffer (e.g. SFQ?).
>>>>
>>
>>
>>> Huh?
>>>
>>
>> Sorry, was just trying to point out that we would only have to
>> multiplex/schedule the transmit buffers as the radio can't control
>> what frames arrive on the PHY, and hence in what order/priority the
>> upper MAC layers get on the receive side of things.
>
> If I'm reading you correctly, this is true even for one MAC instance.
>>
>>>> I think this would require either modifying any existing lower MAC
>>>> (HAL), or perhaps writing a completely new lower MAC (HAL).
>>>>
>>
>>
>>> The HAL (in madwifi anyway) is not the "lower MAC".
>>>
>>
>> Sorry, I'm getting my HAL and lower MAC boundries confused here.
>>
>> Regards, Dan...
>>
>>
>
> _______________________________________________
> HostAP mailing list
> HostAP at shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap