Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 85 replies
  • Subscribers 2 subscribers
  • Views 98461 views
  • Users 0 members are here
Options
Suggested
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

Slow Throughput with Fast Cable

Asteroid
I was hoping some users who are far more experienced than I, could provide recommendations for improved throughput for a home license with 3concurrent users maximum and a cable modem connection of 180 down/30 up Mb/sec. 

Speed was measured with a computer directly connected to the cable modem for a baseline. A variety of speed test sites were used, as well as uploading and downloading large files to servers with timed comparisons and performance monitoring in Windows.

I tried the current software UTM version 9 on a Core 2 Duo at 1.8 GHz with 2GB RAM and a 7200 rpm HD and found that with everything off (but the firewall/NAT) that throughput was good. However, after activating IPS for Windows system/Office/Malware, download speed dropped to the 50s. Adding Web filtering and single AV, dropped it to the 40s. The latency of speed tests jumped from the 10-20 msec range to 160-170 msec range as well.

I then repeated the test on different hardware with an i7 Ivy Bridge 3770K with 32 GB RAM and a 7200 rpm HD and found a good baseline with everything off, a drop to the 90s with IPS (as above), and further drop to the 80s with Web filtering and single AV. On this system, CPU utilization peaked at 


This thread was automatically locked due to age.
Parents
  • 0
    I agree that the CPU can be controlled with regard to idle states/multipliers via power settings or software such as Asus AI Suite. However, the question is how this is handled in SUSE Linux Enterprise Server on which the Sophos software UTM is running.
  • 0 in reply to Asteroid
    I agree that the CPU can be controlled with regard to idle states/multipliers via power settings or software such as Asus AI Suite. However, the question is how this is handled in SUSE Linux Enterprise Server on which the Sophos software UTM is running.


    Hi, the UTM doesn't have the full suite of Linux Power Management tools configured, but some bits are there, e.g. the 'acpi_cpufreq' module is loaded on my 9.005 firewall.

    The 'handles' to tweak the speed settings for EACH CPU CORE are in
    /sys/devices/system/cpu/cpuX/cpufreq
    (replace X with CPU core #, starting from 0)


    cd /sys/devices/system/cpu/cpu0/cpufreq
    cat scaling_available_governors
    cat scaling_available_frequencies

    shows 
    that the possible frequencies for my Atom CPU are 
    1600000 1333000 1067000 800000 (Hz)

    and the possible governors are 
    ondemand performance 

    and the current frequency is 800000 (800MHz)
    and the current governor is 'ondemand'.

    I would suggest to first try changing the current governor to 'performance':

    as root (sudo won't work with the echo command),
    cd /sys/devices/system/cpu/cpu0/cpufreq
    echo 'performance' > scaling_governor

    repeat for each CPU.

    to see if it did anything:
    cat scaling_cur_freq

    to revert:
    echo 'ondemand' > scaling_governor


    I tested all of this on my Atom, and changing the governor to 'performance' did raise the CPU clock to full speed (1.6GHZ on my Atom).

    Of course, this will consume more power and create more heat, so make sure you have sufficient airflow.

    None of the above changes will survive a reboot, you'd need to add the commands to the end of /etc/init.d/boot.local, and do it again if up2date replaces that file.
    Note that changing files on the console may void your support, and always make a configuration backup first.


    Actually, a good test would be to check the cpufreq during a bandwidth test; e.g. start the test, and run:
    cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
    cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq
    cat /sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq
    cat /sys/devices/system/cpu/cpu4/cpufreq/scaling_cur_freq
    ... for each CPU/hyperthread (probably 0-7 on an i7 CPU)

    and see if any of them are running above idle speed.

    Barry
Reply
  • 0 in reply to Asteroid
    I agree that the CPU can be controlled with regard to idle states/multipliers via power settings or software such as Asus AI Suite. However, the question is how this is handled in SUSE Linux Enterprise Server on which the Sophos software UTM is running.


    Hi, the UTM doesn't have the full suite of Linux Power Management tools configured, but some bits are there, e.g. the 'acpi_cpufreq' module is loaded on my 9.005 firewall.

    The 'handles' to tweak the speed settings for EACH CPU CORE are in
    /sys/devices/system/cpu/cpuX/cpufreq
    (replace X with CPU core #, starting from 0)


    cd /sys/devices/system/cpu/cpu0/cpufreq
    cat scaling_available_governors
    cat scaling_available_frequencies

    shows 
    that the possible frequencies for my Atom CPU are 
    1600000 1333000 1067000 800000 (Hz)

    and the possible governors are 
    ondemand performance 

    and the current frequency is 800000 (800MHz)
    and the current governor is 'ondemand'.

    I would suggest to first try changing the current governor to 'performance':

    as root (sudo won't work with the echo command),
    cd /sys/devices/system/cpu/cpu0/cpufreq
    echo 'performance' > scaling_governor

    repeat for each CPU.

    to see if it did anything:
    cat scaling_cur_freq

    to revert:
    echo 'ondemand' > scaling_governor


    I tested all of this on my Atom, and changing the governor to 'performance' did raise the CPU clock to full speed (1.6GHZ on my Atom).

    Of course, this will consume more power and create more heat, so make sure you have sufficient airflow.

    None of the above changes will survive a reboot, you'd need to add the commands to the end of /etc/init.d/boot.local, and do it again if up2date replaces that file.
    Note that changing files on the console may void your support, and always make a configuration backup first.


    Actually, a good test would be to check the cpufreq during a bandwidth test; e.g. start the test, and run:
    cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
    cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq
    cat /sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq
    cat /sys/devices/system/cpu/cpu4/cpufreq/scaling_cur_freq
    ... for each CPU/hyperthread (probably 0-7 on an i7 CPU)

    and see if any of them are running above idle speed.

    Barry
Children
No Data