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: