Stan,
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 <s...@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-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/4cf2f5c3.5070...@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/aanlktin�ib_mc8ddz2_gx8x7aewwi=mm1=uisu7...@mail.gmail.com
