Actually, from the above tests, QoS in the Astaro ASG product is either broken or not implemented correctly. QoS shouldn't be a bandwidth throttler, but rather a packet prioritizer. The most efficient way to do QoS is through tags, but this is really only effective when all the routers between endpoints also support QoS... which most ISP's don't honor on the public routers.

But, for a home user or any company with asynchronous bandwidths, the uplink is usually the slower link. So, the critical QoS in this case is simply to ensure the uplink doesn't get saturated, which will slow down outbound requests therefore creating the appearance of a slowdown on the inbound traffic (responses). The proper way to do this is to prioritize outbound packets, rather than the old hack 'em slash 'em way of dropping low priority packets during heavy traffic. You certainly don't want to throttle the uplink per session-- that's a HUGE waste of bandwidth. As demonstrated from the test by StlScott, proper QoS should not cut a single session back to 2.4 megabit for an 80 megabit available bandwidth. This looks like the old WonderShaper way of QoS'ing for linux.

Astaro might want to look at the Sveasoft Talisman linux firmware for the LinkSys WRT routers. This small custom embedded linux device far outperforms the fastest Astaro box in terms of throughput and QoS... this as compared on a 70-user office network. They use two Talisman WRT's in a failover configuration, but wanted to look into Astaro ASG for the other management and reporting functions. So far, the reliability and throughput has been the showstopper.

Anyway, in summary... Astaro has a great product, don't get me wrong. I really like the web admin interface and configurability options. The throughput, and especially the QoS methodology, needs to really be worked on for future releases. With the total horsepower available to ASG platforms, this should be an easy task... the Talisman WRT's are doing it better with only 200MHz processors and 16-32MB RAM.

What are your QoS settings on your external interface? Perhaps it's simply configured incorrectly?

I certainly haven't noticed any problems with QoS in my use, it does a good job of throttling bandwidth for me when the interface limits are set appropriately.

For example, on a T1, I found that setting the uplink/downlink bandwidth to 1425 kbps (or a bit more than 90% theoretical T1 speeds) allows me to do multiple downloads/uploads while still maintaining very good latency across the link.

The settings themselves don't appear to have much bearing on the actual throughput. The simple fact is that QoS is enabled, which immediately causes a hit in throughput because of arbitrarily dropped packets-- this is very symptomatic of WonderShaper, so I'm thinking more and more that is what ASG uses internally for QoS. Just for comparison's sake, here are three sets of numbers from the benchmark testing that was performed, all three tests are averaged over 30-minute test span. Traffic generation tests:

Vonage VoIP call (set to highest QoS priority, throughout test duration)
Azureus BitTorrent Client (set to lowest priority, 300-400 concurrent sessions, no software throttling)

Standard (Control Test) - Linux 2.6.15 Kernel on PC connected directly to cablemodem (no firewall):

8034 kbps measured downlink (8mbit service)
748 kbps measured uplink (768kbit service)

Sveasoft Talisman 1.0.5 Firmware running on WRT54GSv1.0 Hardware
QoS parameters
Downlink QoS: Disabled
Uplink QoS: 768kbit
Azureus transfer rate without Vonage call:
7985 kbps sustained downlink
708 kbps sustained uplink
Azureus transfer rate with Vonage call:
7714 kbps sustained downlink
594 kbps sustained uplink
Vonage voice quality flawless

Astaro ASG 6.301 on Dual Proc Xeon hardware (see post #3 in this thread)
QoS parameters (external interface only)
Downlink QoS: 8500 (can't disable)
Uplink QoS: 768kbit
Azureus transfer rate without Vonage call:
6234 kbps sustained downlink
588 kbps sustained uplink
Azureus transfer rate with Vonage call:
5104 kbps sustained downlink
339 kbps sustained uplink
Vonage voice quality choppy with multiple audio drops

My point is that enabling QoS without setting actual bandwidth limits is more likely to hurt performance that help. Have you tried setting some actual bandwidth limits as I suggested?

ASL uses standard Linux iptables QoS. You can see the actual rules enabled by looking at the Packet Filter -> Advanced -> Current System QoS Rules if you want to compare them to the ones generated by the Linux based Sveasoft software.

I should have also mentioned in the test results above that the numbers posted were the best we could squeeze out of both devices with QoS enabled. With QoS limits set lower than those posted above for ASG, the results dropped even further. With some manual manipulation of the rules in the ASG, it may be able to match the Talisman rules, but that's defeating the purpose since these changes aren't supported by Astaro.

It would be nice if the ASG web interface provided more granular control of the QoS configuration. It would also be VERY handy if it could base QoS rules on other parameters such as MAC address and L7 packet signatures rather then simply network and port rules. It would be nice to have more prioritization levels as well. All of these features should be easy to add to the ASG's abilities. Hopefully we'll see these in later versions!

Just a quick note. I have QOS turned on on our 5Mb/5Mb fiber connection and see no differences from actual pipe speed. I have traffic split into the three different categories High/Normal/Low. I recall a post from 4-6 months ago by someone doing bandwidth testing during the debate about QOS working or not. I "believe" his tests concluded you need traffic in all three priorities for it to work correctly.

Again this is what I recall...and am to lazy to go search the forum at the moment. ;-). The reason I bring this up is it looks as though you mention your traffic as being either set High or Low.

-Scott

You don't need to prioritize packets for QoS to work properly. I have found on my relatively puny T1 that simply turning on QoS and setting the interface speed properly maintains good interactivity over the link as Astaro by default prioritizes small packets. Without QoS and heavy traffic, connection latency goes _way_ up. With QoS, I get 100ms pings worst case, without it pings go up to over 1 second. And peak traffic stays very close to the same.

Without properly setting the interface speed to some value below the max speed of the link, interactivity goes up as max bandwidth is reached as the router is not doing any QoS, so the trick it to keep from hitting the max of the link which keeps the ASL box prioritizing packets.

With asymetric circuits such as those with most DSL and cable services where the downlink speed is far greater than the uplink speed, QoS simply needs to be disabled on the downlink side. You cannot do effective QoS'ing in this direction anyway since you can't control what's sent to the external interface from the internet. By setting numbers less than the actual bandwidth (measured, not advertised), you are wasting bandwidth.

After researching and comparing the QoS methods and rules between the Astaro ASG and Sveasoft Talisman firmware, they appear to be performing QoS with the same system. The ASG software is just over-simplifying the rules with no other tuning options available through the web admin interface. The bottom line is that the Talisman firmware performs far better for QoS and throughput. Maybe Astaro should pick apart the methods used in this firmware. I'm not trying to bash Astaro, just hoping to provide some insight into ways to improve the product. My customers love the web admin interface and the plethora of other features, but the side-by-side performance comparison with their existing systems has been the sticking point with actually moving forward with the deployment.

thankyou for the post on the QOS post.

We have supieriour hardware and I was getting bad speeds for months. Tried everything and it got worse with version 6.

Things are much better now, thanks.

You chat about the QOS has been very informative as well.

Michael.

I'd be more than happy to take a look at the Sveasoft firmware if you can get me a binary along with the GPL source. Good luck with getting the source for the binary you paid for. I personally refuse to support Sveasoft as they work so hard to work around GPL licensing. By constantly delaying source releases to binaries and terminating your subscription if you are found to distribute a release.

Which version are you using? Is there a freely available Talisman binary with good QoS? I have a WRT54G here that's waiting.

Unfortunately I don't have Astaro deployed on any asymmetrical links, otherwise I could do more testing.