You're seeing different items!
STATS: is reporting thus:
for(i=0; i<myGlobals.numDevices; i++) {
int j;
traceEvent(CONST_TRACE_INFO, "CLEANUP: Freeing device %s (idx=%d)",
myGlobals.device[i].name, i);
if(myGlobals.device[i].pcapPtr && (!myGlobals.device[i].virtualDevice))
{
if (pcap_stats(myGlobals.device[i].pcapPtr, &pcapStat) >= 0) {
traceEvent(CONST_TRACE_INFO, "STATS: %s packets received by filter
on %s",
formatPkts((Counter)pcapStat.ps_recv),
myGlobals.device[i].name);
traceEvent(CONST_TRACE_INFO, "STATS: %s packets dropped by kernel",
formatPkts((Counter)pcapStat.ps_drop));
#ifdef CFG_MULTITHREADED
traceEvent(CONST_TRACE_INFO, "STATS: %s packets dropped by ntop",
formatPkts(myGlobals.device[i].droppedPkts.value));
#endif
}
}
while the web interface is:
myGlobals.device[myGlobals.actualReportDeviceId].droppedPkts.value
Two differences
#1. Web is reporting only for the reporting device (set through Admin |
Switch NIC), while shutdown stats are per NIC.
#2. You're miscomparing - the right comparision is the libpcap count,
i.e. "packets dropped by ntop" - the value in droppedPkts (packets dropped
by kernel) is copied from libpcap only in returnHTTPPage() in http.c ... so
it's probably not a valid #.
And, since there is at least a few seconds difference in time, that's why
the #s differ even for the same device 58,939 vs. 66,033.
Yeah, the output could be cleaner, but that's what the code is doing... The
best fix would be to eliminate droppedPkts and just grab the libpcap counter
each time:
$ grep -i --line-number droppedPkts *.c | grep device
emitter.c:1268: wrtLlongItm(fDescr, lang, "\t",
"droppedPkts",myGlobals.device[i].droppedPkts, ',', numEntries);
http.c:1437:
myGlobals.device[myGlobals.actualReportDeviceId].droppedPkts.value =
pcapStats.ps_drop;
http.c:1439:
incrementTrafficCounter(&myGlobals.device[myGlobals.actualReportDeviceId].dr
oppedPkts, pcapStats.ps_drop);
initialize.c:342:
resetTrafficCounter(&myGlobals.device[devIdx].droppedPkts);
ntop.c:922:
formatPkts(myGlobals.device[i].droppedPkts.value));
pbuf.c:1656:
incrementTrafficCounter(&myGlobals.device[getActualInterface(deviceId)].drop
pedPkts, 1);
report.c:312:
if(myGlobals.device[myGlobals.actualReportDeviceId].droppedPkts.value > 0) {
report.c:316: getRowColor(),
formatPkts(myGlobals.device[myGlobals.actualReportDeviceId].droppedPkts.valu
e),
report.c:317:
(float)(myGlobals.device[myGlobals.actualReportDeviceId].droppedPkts.value*1
00)
webInterface.c:4526: if(myGlobals.device[0].droppedPkts.value > 0) {
webInterface.c:4527: snprintf(buf, sizeof(buf), " Dropped:
%10u\n", myGlobals.device[0].droppedPkts.value);
webInterface.c:4580: if(myGlobals.device[i].droppedPkts.value > 0) {
webInterface.c:4581: snprintf(buf, sizeof(buf), " Dropped: %10u\n",
myGlobals.device[i].droppedPkts.value);
HOWEVER, part of the 'problem' could also be that ntop appears to be
assuming that the ps_drop count is reset each time it is being queried as
part of the update, i.e. this code in http.c:
/* Update number of dropped packets */
if(myGlobals.device[myGlobals.actualReportDeviceId].pcapPtr
&& (!myGlobals.device[myGlobals.actualReportDeviceId].virtualDevice)) {
struct pcap_stat pcapStats;
if(pcap_stats(myGlobals.device[myGlobals.actualReportDeviceId].pcapPtr,
&pcapStats) >= 0) {
#ifdef WIN32
myGlobals.device[myGlobals.actualReportDeviceId].droppedPkts.value =
pcapStats.ps_drop;
#else
incrementTrafficCounter(&myGlobals.device[myGlobals.actualReportDeviceId].dr
oppedPkts, pcapStats.ps_drop);
#endif
}
}
(the non WIN32 leg), but that may not be true in ALL OSes... Still, if
there's even ONE that DOES reset it (Solaris??), then we're in trouble...
-----Burton
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David
Touitou
Sent: Monday, October 20, 2003 8:16 PM
To: [EMAIL PROTECTED]
Subject: Re: [Ntop] Dropped by the kernel
Mike Hunter wrote:
>>But ntop traffic stats are more and more funny...
>>2500% lost packets just after launch.
>>And after 2 minutes :
>> Total 321,377
>> Dropped by the kernel 770,577 [239.77 %]
>
>
> That's extremely lame. I wonder if there's a problem with 4.9...do you
> have any way of testing this on 4.8? You may want to write to a freebsd
> mailing list....
I'll try it on another server tomorrow (have to change the cable).
I just made a little and fast test.
Stop ntop and then relaunch it for a few seconds (less than one minute)
then stop it again.
As usual, very strange threads number at launch, but the most funny is
the difference between web interface and logfile.
Web interface says :
Total 8,243
Dropped by the kernel 58,939 [715.02 %]
while ntop logs file says (stopped a bit after the cut/paste from the
web interface) :
21/Oct/2003 02:55:55 STATS: 52,173 packets received by filter on fxp1
21/Oct/2003 02:55:55 STATS: 3,672 packets dropped by kernel
21/Oct/2003 02:55:55 STATS: 66,033 packets dropped by ntop
There's definitively something broken.
Web stats and logfile stats do not agree at all and I still don't
understand how there can be more dropped packets than received packets
(either on the web interface or logfile stats).
>>I've just noticed ntop only shows ONE thread doing "ps aux" or "top", is
>>that normal (build with ./configure on FreeBSD 4.9-RC).
>
> I think that ntop is single-threaded.
It is multi-threaded (compiled as MT) but, as someone else mentionned,
there might be an issue with FreeBSD pthread.
Getting it to compile with linuxthread (as mysql does) might be the
answer to this issue (but not to the stats inconsistancy).
David.
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop
