Limited Speed on good Hardware

Don't user Celeron. Celeron prozessors are not very good for Firewalling because of the limited cache.

Don't user Celeron. Celeron prozessors are not very good for Firewalling because of the limited cache.

Wait, don't the ASG devices use Via processors? Those are even more cache limited than Celerons.

Something else is wrong if the firewall is limiting bandwidth to 2.5Mbps.

Can you log into the firewall directly and use wget to test some downloads?

If you log into the console and use top, does that show high CPU utilization?

On my machine running ASG... both Xeon procs in top are showing 98% idle.  Speeds are still agonizingly slow and inconsistent compared to what they should be.

With the dual xeons it almost sounds like their is a bottle neck somewhere else. What are you using for network cards? What is the chipset of the motherboard?

all my specs are in post #3 above... the actual model of the system is an HP x4000 Workstation.

Since my last post, however, I think I've narrowed down the probable cause of the slowness.  I disabled QoS on the external interface and the speeds are all where they're supposed to be... 8Mbit down / 768kbit up, or just under.  If I enable QoS with ANY settings, the total speed drops back down.  On the WRT with custom firmware, you can disable the inbound QoS.  I don't see any way to do this within Astaro.  Any ideas on this?

EDIT:  I also noticed something else interesting with QoS disabled... I'm currently downloading two very large torrents (Ubuntu and Kubuntu DVD's) with several hundred peers connected.  It's downloading at a solid 8Mbit rate without problems.  But I noticed even after 3.5GBytes of data, there's been NO errors or dropped packets on the external interface.  I was seeing around 400-500 dropped packets when QoS was enabled.  Is QoS broken?  I'd be curious to know which QoS method Astaro uses.  It feels like the old WonderShaper.

all my specs are in post #3 above... the actual model of the system is an HP x4000 Workstation.

Since my last post, however, I think I've narrowed down the probable cause of the slowness.  I disabled QoS on the external interface and the speeds are all where they're supposed to be... 8Mbit down / 768kbit up, or just under.  If I enable QoS with ANY settings, the total speed drops back down.  On the WRT with custom firmware, you can disable the inbound QoS.  I don't see any way to do this within Astaro.  Any ideas on this?

EDIT:  I also noticed something else interesting with QoS disabled... I'm currently downloading two very large torrents (Ubuntu and Kubuntu DVD's) with several hundred peers connected.  It's downloading at a solid 8Mbit rate without problems.  But I noticed even after 3.5GBytes of data, there's been NO errors or dropped packets on the external interface.  I was seeing around 400-500 dropped packets when QoS was enabled.  Is QoS broken?  I'd be curious to know which QoS method Astaro uses.  It feels like the old WonderShaper.

Thanks for the info about QOS... this too was my problem.  I removed the QOS setting and was able to get the SAME performance through the firewall as I was getting on a WinXP PC.  Because I'm a "Myth Busters Fan"... I decided to step it up a notch, now that my issue was fixed I had to see if the celeron CPU was an issue.  Using an external server (on the same network as my External NIC), I ran some speed tests. I'm sure these tests were limited because my external network is a 100mb hub, not a switch.  However, I was able to sustain 75 megabit of throughput on file sizes over 100mb through the firewall.  This is full PROOF that a Celeron 2.0ghz is more than enough horsepower to be a firewall.

However, I ran MORE tests because I'm a tech and I just have to.  So, I hooked up a new hard drive to my 3.0ghz P4 DUEL CORE box.. and put an extra Realtec 8139 in it (there was an onboard realtec gig already), installed 6.3.0 from cd, upgraded it to 6.3.1.  I then ran the same tests... QOS on resulted in 2.4mb throughput.. QOS off, FULL throughput.. .and this firewall was able to sqeeze 80megabit on my local speed test using the same external network (hub) (with QOS off).

Therefore, perhaps someone at ASTARO needs to look into a problem with QOS as this has caused SERIOUS bandwidth limiting issues.

Hi,

I don't think QOS is broken.
You are running a firewall to support hundreds of users, so the firewall should be able to handle all this. 
Cause of this QOS is used, to make sure everyone is able to use the service the astaro is providing. Please repeat your test with hundreds of users downloading at the same time. 

I think it is good that Astaro QOS safes bandwith so your smtp is working your proxy is able to talk to the content filter server your DNS is able to get his answers and so on.

Sven

Hi,

I don't think QOS is broken.
You are running a firewall to support hundreds of users, so the firewall should be able to handle all this. 
Cause of this QOS is used, to make sure everyone is able to use the service the astaro is providing. Please repeat your test with hundreds of users downloading at the same time. 

I think it is good that Astaro QOS safes bandwith so your smtp is working your proxy is able to talk to the content filter server your DNS is able to get his answers and so on.

Sven

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.