etocalini
02-24-2008, 02:09 PM
Will Nanostation5 work with Mikrotik Nstreme ?
View Full Version : Mikrotik Nstreme
vincefer
03-12-2008, 12:42 AM
I think nstreme is a propietary extension made by Mtik. So the only way to support it on NS2 is installing ROS on it. And this is not posible.
May be I'm wrong because nstreme requires some features on the radio card chipset.
Please, correct me if I'm wrong.
May be I'm wrong because nstreme requires some features on the radio card chipset.
Please, correct me if I'm wrong.
sarpkaya
10-27-2008, 01:28 PM
Nstreme needs 2 radio cards and 2 antennas. NS2 doesn't have 2 Radio cards, that's why it cannot use.
InoX
10-27-2008, 01:34 PM
Nstreme needs 2 radio cards and 2 antennas. NS2 doesn't have 2 Radio cards, that's why it cannot use.
nstreme needs only one card....nstreme 2 (or dual) needs 2 cards...RTFM
May be I'm wrong because nstreme requires some features on the radio card chipset.
you're wrong...it's a pooling method that is only OS related.
nstreme needs only one card....nstreme 2 (or dual) needs 2 cards...RTFM
May be I'm wrong because nstreme requires some features on the radio card chipset.
you're wrong...it's a pooling method that is only OS related.
corky
11-20-2008, 09:37 PM
NStreme was originally designed for p2p links, and can sometimes produce spectaular results. I have some backhauls that run almost 2x faster with nstreme on. But it's traditionally been junk on p2mp links.
About 2 weeks ago MT finally got around to designing a good algorithm for p2mp nstreme. I have found especially on struggling towers (typically 900mhz) this can yield HUGE improvements in latency and jitter. The change was to the AP side only. Clients don't have to be upgraded. It's so good, it's made me hesitant to move all my clients to nano-stations, which I was starting to do.
I'd say based on the breathtaking results I'm seeing, that it would be worth while to reverse-engineer client side nstream and build it into the ubnt products.
Corky
About 2 weeks ago MT finally got around to designing a good algorithm for p2mp nstreme. I have found especially on struggling towers (typically 900mhz) this can yield HUGE improvements in latency and jitter. The change was to the AP side only. Clients don't have to be upgraded. It's so good, it's made me hesitant to move all my clients to nano-stations, which I was starting to do.
I'd say based on the breathtaking results I'm seeing, that it would be worth while to reverse-engineer client side nstream and build it into the ubnt products.
Corky
kijoma
11-22-2008, 11:01 AM
heh, reverse engineer :o, of course i am sure MT obey the GPL with their use of the linux kernel / system and therefore release source code etc..
*cough* :roll:
think we need to form a polling protocol working party and produce an open implementation that would work on many open platforms such as Air OS and dd-wrt etc.. (expect MT routerOS which by its nature is a closed platform).
*cough* :roll:
think we need to form a polling protocol working party and produce an open implementation that would work on many open platforms such as Air OS and dd-wrt etc.. (expect MT routerOS which by its nature is a closed platform).
altaphon
12-17-2008, 08:01 PM
There are a few Nstreme-like polling systems, starting with whatever became Karlnet, and I think Valemount had something in StarOS. I would volunteer to join this working group but I'm an RF guy, not a coder. It's badly needed -- along with a duplex mode like Nstreme2. Don't need any fancy routing, just the ability to pipe bits in each direction and let some other layet do the corrections.
kijoma
12-19-2008, 03:04 AM
hi,
agree on the duplex / twin card setup. the routerstation should handle this nicely. again there is no use for polling algorithms in a duplex link! so this should be implementable with low overhead.
Its a case of getting the code to direct the respective TX/RX paths to each card so one can transmit, the other receive. implement half duplex fallback in case a card dies..
Another neat idea would be to implement a parallel card mode, so both transmit equal data and receive it akin to bonding but with the requirement that the transmit cycles are synchronised so there can be no local tx into a local rx blocking issues. This would be good for high throughput "half duplex" backhauls.. again have a mechanism for detecting card/link failure so it will fall back to a single link.
I am also an RF guy but have done quite a bit of coding in the past on Bluetooth stacks, RF products etc..
agree on the duplex / twin card setup. the routerstation should handle this nicely. again there is no use for polling algorithms in a duplex link! so this should be implementable with low overhead.
Its a case of getting the code to direct the respective TX/RX paths to each card so one can transmit, the other receive. implement half duplex fallback in case a card dies..
Another neat idea would be to implement a parallel card mode, so both transmit equal data and receive it akin to bonding but with the requirement that the transmit cycles are synchronised so there can be no local tx into a local rx blocking issues. This would be good for high throughput "half duplex" backhauls.. again have a mechanism for detecting card/link failure so it will fall back to a single link.
I am also an RF guy but have done quite a bit of coding in the past on Bluetooth stacks, RF products etc..
hguy
12-19-2008, 07:03 AM
I think what it comes down to is we simply need a polling or time slot implementation to better address hidden nodes. It should also address packing packets to more efficiently use air time.
What would be great is a GPS sync option as well. That would be a much bigger step then the polling but it would really help with scale.
What would be great is a GPS sync option as well. That would be a much bigger step then the polling but it would really help with scale.
Commnet-Matt
02-02-2009, 06:52 PM
This thread might be quite relevant
http://ubnt.com/forum/viewtopic.php?t=846
We have a custom kernel module that we had paid a good sum to be developed for us specifically to use as a polling solution similar to NSTREME (but with vastly reduced overhead) on the Ubiquiti _S5 gear. We ran into so many problems with OpenWRT though that we abandoned implementation - but early tests looked very promising. We had used OpenWRT as this was well before AirOS was released, and we had no other options for an OS to use with our custom kernel module.
I explained a bit more depth of the polling system we had developed in the other therad - but it does exactly what hguy suggested, efficiently packs the packets (actually omits a great deal of pointless wait intervals that are normally necessary for collision avoidance), and uses a fair polling system.
In our research - it is a limitation of the Atheros chipset that you cannot implement true timeslot based GPS-synched, because the Atheros chip does not offer quite enough of it's HAL to be able to mess with the PHY layer enough. It's a challenge enough to disable CSMA, let alone rewrite how it handles frame timing. To implement it at a higher level would require an extremely precise realtime clock, which the devices to not have (and you would still be waiting for interrupts from the atheros chip).
Instead, we use a small control frame sent from the AP to indicate the poll interval ( a CTS frame to be exact, as it has the side-effect of causing other stations to refrain from talking even if they are not part of the polling arrangement ) - and the client firmware is set to not send any traffic whatsoever unless it receives this frame. Downstream traffic continues as it would otherwise, though - as there is no contention on the downstream obviously. Polling is only necessary for upstream.
A control frame to indicate the poll interval (like a token), is certainly less efficient than purely timeslot based polling - but given the hardware limitations is the best that can be done. And it is miles better than NSTREME in our research, as it appears that NSTREME uses an application level polling implementation that does not take advantage of any of the underlying features of the atheros chipset.
That said - getting rid of the ACK frames, the DIFS intervals, and all sorts of other overhead necessary for contention-based communications means that the latencies involved are very consistant (almost no jitter) - and near/far and hidden node issues are almost eliminated. The total available throughput on the channel is also increased.
We have given Ubiquiti the option of using the code if they like - but if they would prefer not to, I would have no qualms about making it open source, if the community as a whole would like to integrate and run with it. I would like to make sure Ubiquiti does not want to use it for their own purposes first, as we had extended the offer to them.
http://ubnt.com/forum/viewtopic.php?t=846
We have a custom kernel module that we had paid a good sum to be developed for us specifically to use as a polling solution similar to NSTREME (but with vastly reduced overhead) on the Ubiquiti _S5 gear. We ran into so many problems with OpenWRT though that we abandoned implementation - but early tests looked very promising. We had used OpenWRT as this was well before AirOS was released, and we had no other options for an OS to use with our custom kernel module.
I explained a bit more depth of the polling system we had developed in the other therad - but it does exactly what hguy suggested, efficiently packs the packets (actually omits a great deal of pointless wait intervals that are normally necessary for collision avoidance), and uses a fair polling system.
In our research - it is a limitation of the Atheros chipset that you cannot implement true timeslot based GPS-synched, because the Atheros chip does not offer quite enough of it's HAL to be able to mess with the PHY layer enough. It's a challenge enough to disable CSMA, let alone rewrite how it handles frame timing. To implement it at a higher level would require an extremely precise realtime clock, which the devices to not have (and you would still be waiting for interrupts from the atheros chip).
Instead, we use a small control frame sent from the AP to indicate the poll interval ( a CTS frame to be exact, as it has the side-effect of causing other stations to refrain from talking even if they are not part of the polling arrangement ) - and the client firmware is set to not send any traffic whatsoever unless it receives this frame. Downstream traffic continues as it would otherwise, though - as there is no contention on the downstream obviously. Polling is only necessary for upstream.
A control frame to indicate the poll interval (like a token), is certainly less efficient than purely timeslot based polling - but given the hardware limitations is the best that can be done. And it is miles better than NSTREME in our research, as it appears that NSTREME uses an application level polling implementation that does not take advantage of any of the underlying features of the atheros chipset.
That said - getting rid of the ACK frames, the DIFS intervals, and all sorts of other overhead necessary for contention-based communications means that the latencies involved are very consistant (almost no jitter) - and near/far and hidden node issues are almost eliminated. The total available throughput on the channel is also increased.
We have given Ubiquiti the option of using the code if they like - but if they would prefer not to, I would have no qualms about making it open source, if the community as a whole would like to integrate and run with it. I would like to make sure Ubiquiti does not want to use it for their own purposes first, as we had extended the offer to them.
jp498
02-03-2009, 10:19 AM
I'm curious how this works with NS5s running the skypilot firmware. Skypilot claims to be a polling and GPS sync'd system and charge good money for that claimed advantage.
MaximumISP
02-03-2009, 06:19 PM
Glad to see you made it back ok Matt
I would really like to continue our discussions on this
and hope UBNT jumps on this like white on rice
either way Im on board ready and willing to dedicate
whatever I can to see this come to be
I am desperate for some type of polling and have tested
OsWave on ubnt devices trying to achieve this for
quite sometime now which has resulted in many bricked units
I need this badly
I would really like to continue our discussions on this
and hope UBNT jumps on this like white on rice
either way Im on board ready and willing to dedicate
whatever I can to see this come to be
I am desperate for some type of polling and have tested
OsWave on ubnt devices trying to achieve this for
quite sometime now which has resulted in many bricked units
I need this badly
