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?

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

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!