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 <magaw...@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 <s...@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-requ...@lists.debian.org >> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org >> Archive: http://lists.debian.org/4cf1df5b.6030...@hardwarefreak.com >> >> > -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti�-ssx=gjyhvfuzckzhkc9ck3k2lmvxhrn...@mail.gmail.com
