[HPADM] Summary: nettl trace drops pkts on GIG eth

From: David R Antoch (dantoch@csc.com)
Date: Thu Mar 20 2003 - 12:05:00 EST


All,

I received 2 responses....Thx to Bill Hassell and Rick Jones for their
responses.

Basically, it looks like my max'd out K580 cant keep up with the fast
input.

"the K-580 is pretty slow compared to today's servers and the
Gigabit link speed is severely limited by the architecture of the K-series
and overhead
in the driver. HP markets the GB LAN card as a 'connectivity solution'
which means
that it isn't going to perform nearly as well as a similar card in a
modern server.
 GB LAN speed is similar to disks but with a lot higher overhead."

Even though I'm dumping the output file to my fastest (15K) disk with the
filesystem fstab options:

nodatainlog,mincache=direct,convosync=direct (to bypass the Buffer
Cache because it is an Oracle data disk)

 it still cant keep up. Some good thoughts from Rick:

"you want to make sure that it is possible to write data to the
filesystem where the logs reside at a rate greater than the Gige card
provides data. You miht also try to limit the quantity of data from
each packet nettl tries to write - say by just looking at headers.

You might make sure that the trace files go to a filesystem with
journaling disabled or "tmpwrite" or what not set, and the disc(s)
supporting that filesystem have immediate report enabled (scsictl).

Another option might be to try tcpdump and use a filter to minimize the
data written to the trace file."

Thx again,
Dave

=======================================================

My Original Post:

I'm trying to use nettl to trace a Gigabit Eth interface on a production
 K580 6-way,
but it keeps dropping packets:

" netfmt (217) warning: Dropped 8 events containing 0 bytes while
capturing
this data. To prevent dropping data in the future you may need to choose
a larger input
buffer size when capturing data with nettl"

Now, my original nettl line used -size 1024 (the documented
MAX is 1024)
and -tracemax 25000 which I then Max'd out to -tracemax 99999
(the documented
MAX is 99999), but still recieved the Dropped events....

For example:

# nettl -tn all -e all -size 1024 -tracemax 99999 -f
/path/to/mytrace.raw0 #(the /path/to is a filesystem with lots
of free space)
.....Wait some time..... .....Now turn off tracing

# nettl -tf -e al
nktl_daemon [21554]: Failed to write loggin/tracing data. ntl_write
returned
status=1141047318 nktl_daemon [21554]: Failed to write loggin/tracing
data.
ntl_write returned status=1141243926 nktl_daemon [21554]: Failed to
write
loggin/tracing data. ntl_write returned status=1141440534 nktl_daemon
[21554]:
Failed to write loggin/tracing data. ntl_write returned
status=1141243926 nktl_daemon
[21554]: Failed to write loggin/tracing data. ntl_write returned
status=1141440534
nktl_daemon [21554]: Failed to write loggin/tracing data. ntl_write
returned
status=1141243926 nktl_daemon [21554]: Failed to write loggin/tracing
data.
ntl_write returned status=1141440534

....repeats the last 2 lines many times
....

(Notice that I get those daemon warnings when I turn off the tracing)

 Now when I format using netfmt and a filterfile, I see the Dropped
 events (217)
warning as listed above.

I've also tried to use the -card /dev/gelan0 to get only the
GIG eth
Interface, but no difference. I'm using a sniffer at the client end, but
would like to
completely trace the server interface also.
My questions:

Is this (-size 1024 and -tracemax 99999) the largest buffer and
file space I
can use?

What else can I do (host based) to get a complete trace on that busy
production
system?

--
             ---> Please post QUESTIONS and SUMMARIES only!! <---
        To subscribe/unsubscribe to this list, contact majordomo@dutchworks.nl
       Name: hpux-admin@dutchworks.nl     Owner: owner-hpux-admin@dutchworks.nl
 
 Archives:  ftp.dutchworks.nl:/pub/digests/hpux-admin       (FTP, browse only)
            http://www.dutchworks.nl/htbin/hpsysadmin   (Web, browse & search)


This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 11:02:27 EDT