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

Re: unloading unnecessary modules


sorry for the late response.

lspci gives me this about my Ethernet adapter.

04:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit
Ethernet Controller (rev 06)
        Subsystem: Hewlett-Packard Company NC360T PCI Express Dual
Port Gigabit Server Adapter
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 154
        Region 0: Memory at fbfe0000 (32-bit, non-prefetchable) [size=128K]
        Region 1: Memory at fbfc0000 (32-bit, non-prefetchable) [size=128K]
        Region 2: I/O ports at 5000 [size=32]
        [virtual] Expansion ROM at e6200000 [disabled] [size=128K]

The target application is a OTP (online transaction processing) with
is driven by CICS. The volume maybe high but latency is important. The
application is CPU bound (80% on 1 core).  but not disk/io or memory
bound. All of our servers have 16GB of memory with 8 cores. The
application is written in C (compiled with Intel based compiler). We
are using a DNS cache solution and sometimes hardcoding /etc/hosts to
avoid any DNS. It does not do too many DNS lookups.

I am really interested in tcp/ip offloading from the kernel and have
the NIC do it. I have read,
http://fiz.stanford.edu:8081/display/ramcloud/Low+latency+RPCs and it
seems very promising.

On Sun, Nov 28, 2010 at 7:37 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:
> Mag Gam put forth on 11/28/2010 7:31 AM:
>> 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.
> Just to confirm they are correct, can we get lspci -vv output for your
> e1000 please?
>> As a replier stated, RT is a good option but I am really not sure how
>> it will affect our latency.
> Maybe if you told us more about the target application we could give you
> better advice.  Is it primarily network one way or RTT bound?  Does it
> make extensive use of DNS lookups and is latency bound there?  Compute
> latency bound?  Disk latency bound?
> There are all manner of latencies in a system.  Knowing which one(s) are
> critical to your application would allow us to better help you.  A real
> time kernel may or may not be what you need.
> I would venture to guess that an "e-commerce" system would not be
> network latency bound but database access latency bound while processing
> orders.  Are you building the database system or the web front end
> application?  If you're building a web front end app, optimizing the
> system at the kernel level is pointless, as php, perl, python, etc have
> tremendously higher execution latencies than the kernel.  We're talking
> 1000 fold difference here.  If this is the case, you should be focusing
> all of your efforts on optimizing the performance of your interpreter.
> --
> Stan
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: 4CF2F5C3.5070601@hardwarefreak.com">http://lists.debian.org/4CF2F5C3.5070601@hardwarefreak.com

Reply to: