Re: unloading unnecessary modules
Erp, pressed 'send' to quickly.
TCP/UDP offloading, to my understanding hardware has to support and
my hardware Intel e1000 doesn't by our engineering team.
i know we can offset the NIC to do IP checksum but it would be great
to bypass the kernel in general.
As a replier stated, RT is a good option but I am really not sure how
it will affect our latency.
On Sun, Nov 28, 2010 at 8:10 AM, Mag Gam <firstname.lastname@example.org> wrote:
> thanks for the response.
> To my understanding, CONFIG_HZ is a kernel time option. Has that
> changed? I can certainly rebuild the kernel. How can I check via /proc
> what my HZ is currently set at? Is there a tool to determine this for
> Removing tasks from cron has helped! We had some weird random tasks
> starting up at production hours which causes interrupts. This is a
> notoriously underestimated tip.
> On Sat, Nov 27, 2010 at 11:49 PM, Stan Hoeppner <email@example.com> wrote:
>> Mag Gam put forth on 11/27/2010 11:06 AM:
>>> Correct. On my severs I too have sound cards and USB. I don't really
>>> need them so I would rather unload them. I suppose I can do a macro
>>> benchmark and state if it helped or not but I would like to know on a
>>> micro level to see if it helped. I think one possibility is to do
>>> "lat_pipe" from lmbench to measure transaction latency of a UNIX pipe.
>>> My goal is to have the most optimal kernel/tuning since our
>>> application is very latency sensitive.
>> In that case modules aren't your worry--the kernel interrupt timer is,
>> along with scheduled tasks. For latency sensitive apps, you need a
>> kernel with something like CONFIG_HZ=1000 or greater, which IIRC used to
>> be the "workstation" default. The "server" default is 250Hz. Also,
>> IIRC, the current Debian kernels implement tickless timers to allow
>> better integration as virtual machine guests. For latency sensitive
>> apps, you'd don't want a tickless timer.
>> If you have a latency sensitive app:
>> 1. Use a kernel with CONFIG_HZ=1000 (or greater)
>> 2. Eliminate all possible cron jobs or schedule them to run at times
>> when it won't impact the latency of your application. I.e. make sure no
>> processes fire unexpectedly which may impact the latency of you
>> application. On today's multicore systems this is less of a problem
>> than it once was as your application can continue to run on the core
>> which is executing it while a new process will be fired up on another
>> core. When/if in doubt, minimize unexpected process execution.
>> 3. If the application is disk I/O bound, make sure you have plenty of
>> write cache, and a stripe (RAID6/10) of a sufficient number of spindles.
>> RAID10 is optimal for low latency. RAID6 can suffer read-modify-write
>> cycles which will increase latency. If you have large write cache, and
>> your app never bursts an amount of data larger than the cache, then
>> RAID6 may be fine. Testing is your friend here. Also note that the XFS
>> filesystem offers the "realtime" sub volume which can decrease latency.
>> It was originally developed for streaming media applications such as
>> digital broadcast systems that replaced teh traditional tape systems:
>> 4. If the application is sensitive to network latency, use a NIC and
>> driver that supports TCP offload processing. If the application needs
>> DNS name resolution of remote systems, consider installing a local
>> caching resolver such as pdns-recursor, which can reduce lookup latency
>> considerably for cached results.
>> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org
>> Archive: 4CF1DF5B.email@example.com">http://lists.debian.org/4CF1DF5B.firstname.lastname@example.org