Virtual WiFi on Linux? StarOS Vxworks IX-420 gizmo
Thu Oct 20 10:15:30 PDT 2005
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.
Qorvus Systems, Inc.
----- 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:
>> 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
>> 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
>>>> have to do is share out the PHY transmit buffer (e.g. SFQ?).
>> 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
More information about the Hostap