Oh, OK. Well I guess its pointless to buy a switch from netonix then :-\ ubiquiti has more experience with wisps and more resources to devote to their toughswitch line.
All the big players are selling appliances that sit on the head end and shape via traditional mechanisms. A fresh company working on a different model can make big waves...ubiquiti back in the day for example.
I argue that big companies are much MUCH less able to innovate and they can be easy to compete against for that reason.
Link Speed Aware QOS
-
rebelwireless - Experienced Member
- Posts: 607
- Joined: Mon Sep 01, 2014 1:46 pm
- Has thanked: 31 times
- Been thanked: 136 times
-
Dave - Employee
- Posts: 726
- Joined: Tue Apr 08, 2014 6:28 pm
- Has thanked: 1 time
- Been thanked: 158 times
Re: Link Speed Aware QOS
yup, we want to be innovative for sure...thats why we came out with this product line, and other cool ones to follow...this is what I want to hear, people with ideas...
-
josh - Associate
- Posts: 109
- Joined: Thu Apr 17, 2014 9:29 pm
- Location: USA
- Has thanked: 69 times
- Been thanked: 31 times
Re: Link Speed Aware QOS
rebelwireless wrote:Oh, OK. Well I guess its pointless to buy a switch from netonix then :-\ ubiquiti has more experience with wisps and more resources to devote to their toughswitch line.
All the big players are selling appliances that sit on the head end and shape via traditional mechanisms. A fresh company working on a different model can make big waves...ubiquiti back in the day for example.
I argue that big companies are much MUCH less able to innovate and they can be easy to compete against for that reason.
I disagree, mainly because Ubiquiti didn't build either of their switches :)
-
josh - Associate
- Posts: 109
- Joined: Thu Apr 17, 2014 9:29 pm
- Location: USA
- Has thanked: 69 times
- Been thanked: 31 times
Re: Link Speed Aware QOS
Side note: Sometimes I really *hate* having NDAs from multiple vedors :/
- Rory
Re: Link Speed Aware QOS
Sometimes you need the most experienced and capable player in a market behind you, sometimes you need a feature or capability that only the smallest and nimblest player has at that time, and sometimes you need something, but not enough to pay for it =D
We use a mixture of products from various vendors / manufacturers, depending on the situation, as do you all. Sometimes its the big boys, other times it is not. Even Cisco doesn't hit a home run every time, so spending the cash on all Cisco gear would be ill advised. I'm sure we can agree that the determination of a products viability is more than a simple binary question on one aspect of the company who's name is on the box.
We use a mixture of products from various vendors / manufacturers, depending on the situation, as do you all. Sometimes its the big boys, other times it is not. Even Cisco doesn't hit a home run every time, so spending the cash on all Cisco gear would be ill advised. I'm sure we can agree that the determination of a products viability is more than a simple binary question on one aspect of the company who's name is on the box.
-
mike99 - Associate
- Posts: 837
- Joined: Tue Nov 25, 2014 10:53 am
- Location: Quebec, Canada
- Has thanked: 95 times
- Been thanked: 245 times
Re: Link Speed Aware QOS
We were also planning to work on something similar but our idea was to use stat with IGP hello paquet, those set at network control priority, and have a algorithm that shape the ethernet or vlan with the wireless link to get maximum bandwidth vs lowest possible paquet lost the last one being more important.
Our goal was to have a more reliable VoIP and still have the freedom to use any wireless brand so we think stats must not be taken from a antenna but from the router. After, DPI could be really interessting.
Our goal was to have a more reliable VoIP and still have the freedom to use any wireless brand so we think stats must not be taken from a antenna but from the router. After, DPI could be really interessting.
-
rebelwireless - Experienced Member
- Posts: 607
- Joined: Mon Sep 01, 2014 1:46 pm
- Has thanked: 31 times
- Been thanked: 136 times
Re: Link Speed Aware QOS
so, lets use some CPU and do a hard core statistical analysis. No information except bits rx, bits tx, and latency for that measured window.
Like this, when tx was X and rx was Y and latency varied more than 5ms over 5 seconds, reducing the queue from 60Mbps to 58Mbps moved latency to a 2ms variance without packetloss <.25% . Do additional and separate analytics for tx and rx and set the queue based on best latency conclusion. obviously its more complicated because packet loss and throwing out anomalies needs to be accounted for but that's the gist.
It's a bit like the process to determine link quality in BATMAN-ADV, though BATMAN-ADV doesn't try to determine available throughput, just latency and packet loss characteristics.
If you think about it, it's a natural path to a full 'tree topology' routing suite. know which direction is the primary uplink and the secondary, put primary path, latency, avial throughput, and a link quality rating in the broadcast packet so downstream routers can make an informed decision. Don't try to solve a fully meshed network, wISPs are very very typically a ring or a quasi-ring so only 2 paths really matter and those paths are known in advance.
Did I go off on a tangent there?
Like this, when tx was X and rx was Y and latency varied more than 5ms over 5 seconds, reducing the queue from 60Mbps to 58Mbps moved latency to a 2ms variance without packetloss <.25% . Do additional and separate analytics for tx and rx and set the queue based on best latency conclusion. obviously its more complicated because packet loss and throwing out anomalies needs to be accounted for but that's the gist.
It's a bit like the process to determine link quality in BATMAN-ADV, though BATMAN-ADV doesn't try to determine available throughput, just latency and packet loss characteristics.
If you think about it, it's a natural path to a full 'tree topology' routing suite. know which direction is the primary uplink and the secondary, put primary path, latency, avial throughput, and a link quality rating in the broadcast packet so downstream routers can make an informed decision. Don't try to solve a fully meshed network, wISPs are very very typically a ring or a quasi-ring so only 2 paths really matter and those paths are known in advance.
Did I go off on a tangent there?
- keefe007
- Experienced Member
- Posts: 169
- Joined: Tue Aug 05, 2014 3:56 pm
- Has thanked: 0 time
- Been thanked: 21 times
Re: Link Speed Aware QOS
Can't you determine link capacity by calculating serialization delay like Performant used to do?
Who is online
Users browsing this forum: Google [Bot] and 18 guests