This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Limited Speed on good Hardware

Version: ASL 6.301
Hardware:
Celeron 2.4ghz
Mem: 768mb DDR 266
80gig ATA HD
Onboard DFI 8139 10/100 (ASL defaults this to FD 100mb)
Add-in 8139 Ovsilink Nic 10/100 (ASL Defaults this to FD & 100mb)

External service is through a Charter Cable Modem that provides Ethernet to my Firewall.  I have the 5mb service down and 512k Up.  When I connect a computer (Win XP) directly, I get 4.5mb down and 498k up.  However, through the ASL Firewall, the best i can get is 2.5mb Down and 310k Up.  

Because of this problem and my ability to have some spare hardware, I started over from scratch.  The prior hardware was a 2.0ghz Celeron.  The one I just built tonight is a 2.4ghz celeron.  The results are the same for both... both firewalls got just barely 2.5mb.  I know that these boxes can push WAY more bandwidth than this.  

So to further try things, I turned off ALL logging, turned off intrusion detection.  The speed only slightly increases when I use the HTTP Proxy rather than NAT.

HELP!
Thanks


This thread was automatically locked due to age.
Parents Reply Children
  • Version: ASG 6.301
    Hardware:
      Dual Xeon 1.8GHz
      Mem: 2GB RAMBUS 400MHz
      72GB SCSI HD (LSi Logic Controller)
      Onboard Intel Pro/100 (ASG defaults this to FD 100mb)
      Add-in Intel Pro/100 (ASG Defaults this to FD 100mb)

    I've been evaluating ASG for about a month on the above hardware and have also noticed a comparatively slow throughput from some pretty beefy hardware.  I'm connected to Comcast Premium CM Service (8Mbit down / 768kbit up).  If I connect my test PC directly to the cable modem, I get a consistent 7.8Mbit down / 712kbit up).  With ASG 6.301 on the above listed hardware, the most I can get through it is 5.7Mbit down / 548kbit up.  I, too, have gone through and disabled everything possible to see if there's any effect on overall throughput and found no noticeable difference.

    On the other hand, I can replace the Astaro box with a LinkSys WRT54GS router with custom firmware and get 7.8Mbit down / 700kbit up.  The responsiveness through the WRT is also much better.  The WRT54GS has a 200MHz MIPS processor and 16MB RAM comparatively.

    ...there's got to be something fundamentally wrong somewhere with the configuration or possibly device drivers.  I haven't submitted a ticket for support yet.  I didn't want to bother them if this was something simple to fix.
  • 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.
  • Don't user Celeron. Celeron prozessors are not very good for Firewalling because of the limited cache.

    This is a bunch of BS... if you look at the bandwidth calculator, a 2.0ghz Cel is more than enough horsepower for 50 user, let along the 6 or 7 in my house.  See my next post for proof.
  • 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

    Astaro user since 2001 - Astaro/Sophos Partner since 2008

  • 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.