> If I read your post correctly you have just restated the Heisenberg uncertainly principle.
I guess you read the first line; which is about the Algorithm in the article. And yes it reminded me of the Heisenberg principle as well (perhaps they have a Heisenberg compensator?)
> but note a network has busy times and slack times an algorithm to predict the ebb and flow of network traffic should be possible.
You, as are they, are makeing a very dangerous assumption; namely that previous behavior is a good indicator of future behaviour.Most LAN traffic displays self-similar behavior, ie its a bit fractal. Which means that it is hard to predict the behavior over short and long time scales.
I suspect that they do most of their maths on averages (to avoid sticky problems). With averages you cant see as much detail (as you throw it away when you average something) - so predictions are easier. However, I am still not convinced about how well it will work...
Anyway! The point of my post was about why optimizing throughput (which is what they say they do, however they do it) gives you QoS...
It optimizes throughput, not latency. Bulk TCP (which I assume is their metric) hides latency, so you can get high throughput even if your latency sucks. So if you want low latency, this is probably not for you...
Right so the upshot of the article is that they adjust the packet sizes to maximize the throughput. Not exactly hard with a bit of queuing theory (which is much easier on fixed sized packets).
The real question is does maximizing the throughput give you Quality of Service? Does maximizing the throughput make short TCP transactions quicker, no because the cost is in the latency of the initial handshake. Does maximizing the throughput fix VoIP, no because the jitter and distribution of losses are more important.
So maximizing your throughput is useful if you want to... err get more throughput; which would be even better with bigger packets. Doesn't sound like good QoS to me.
I have never understood why people insist on optimizing packet scheduling in one dimension; its a two dimensional problem. There is a relationship between throughput, loss and delay; fix on and the other two have a relationship you can't manage. i.e. fix the throughput and you don't know what the loss and delay will be. Quality and Quantity are Different!
Having said that, acording to this, your version have a Prism2/2.5/3 chipset. In which case you will want to look at The Linux WLAN Project.
You may also like to know that there is a debian package for this "apt-get install linux-wlan-ng" should do the trick. Note that some kernel fiddeling may be required, in which case have a look at the The Linux Kernel HOWTO.
"According to http://www.trolltech.com/newsroom/investors.html the Canopy Group only has 5.7% shares of Trolltech while 64.7% are in posession of Trolltech employees with an additional 5% controlled by the Trolltech founders. One can hardly say that the Canopy Group owns or controls Trolltech." (Text from here)
Slashdot Mirror
> If I read your post correctly you have just restated the Heisenberg uncertainly principle.
I guess you read the first line; which is about the Algorithm in the article. And yes it reminded me of the Heisenberg principle as well (perhaps they have a Heisenberg compensator?)
> but note a network has busy times and slack times an algorithm to predict the ebb and flow of network traffic should be possible.
You, as are they, are makeing a very dangerous assumption; namely that previous behavior is a good indicator of future behaviour.Most LAN traffic displays self-similar behavior, ie its a bit fractal. Which means that it is hard to predict the behavior over short and long time scales.
I suspect that they do most of their maths on averages (to avoid sticky problems). With averages you cant see as much detail (as you throw it away when you average something) - so predictions are easier. However, I am still not convinced about how well it will work...
Anyway! The point of my post was about why optimizing throughput (which is what they say they do, however they do it) gives you QoS...
It optimizes throughput, not latency. Bulk TCP (which I assume is their metric) hides latency, so you can get high throughput even if your latency sucks. So if you want low latency, this is probably not for you...
The real question is does maximizing the throughput give you Quality of Service? Does maximizing the throughput make short TCP transactions quicker, no because the cost is in the latency of the initial handshake. Does maximizing the throughput fix VoIP, no because the jitter and distribution of losses are more important.
So maximizing your throughput is useful if you want to ... err get more throughput; which would be even better with bigger packets. Doesn't sound like good QoS to me.
I have never understood why people insist on optimizing packet scheduling in one dimension; its a two dimensional problem. There is a relationship between throughput, loss and delay; fix on and the other two have a relationship you can't manage. i.e. fix the throughput and you don't know what the loss and delay will be. Quality and Quantity are Different!
(Disclaimer: yes I do work for pnsol)
You probably want to look at the OpenSource Linux Driver for Atmel AT76C503A-based Wireless. Although it does not cover version 2.5 it does cover versions 2.1 and 2.6; so you may have some luck.
;)
Having said that, acording to this, your version have a Prism2/2.5/3 chipset. In which case you will want to look at The Linux WLAN Project.
You may also like to know that there is a debian package for this "apt-get install linux-wlan-ng" should do the trick. Note that some kernel fiddeling may be required, in which case have a look at the The Linux Kernel HOWTO.
Hope that is some help...
(Appologies for being completly off topic
"According to http://www.trolltech.com/newsroom/investors.html the Canopy Group only has 5.7% shares of Trolltech while 64.7% are in posession of Trolltech employees with an additional 5% controlled by the Trolltech founders. One can hardly say that the Canopy Group owns or controls Trolltech." (Text from here)