[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 <magawake@gmail.com> wrote:
> Stan,
> 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
> me?
> 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 <stan@hardwarefreak.com> wrote:
>> Mag Gam put forth on 11/27/2010 11:06 AM:
>>> Stan,
>>> 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:
>> http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide//tmp/en-US/html/ch04s09.html
>> 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.
>> --
>> Stan
>> --
>> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>> Archive: 4CF1DF5B.6030309@hardwarefreak.com">http://lists.debian.org/4CF1DF5B.6030309@hardwarefreak.com

Reply to: