Your example on my system also produced similar results. But, using "alarm" function in my packet count program as shown below, had similar random results.

#!/usr/bin/perl -w

use strict;
use English;
use Net::Pcap;
use Time::HiRes qw (alarm time );

my($dev, $pcap_t, $err);

$dev = Net::Pcap::lookupdev(\$err);
$pcap_t = Net::Pcap::open_live($dev, 1500, 1, 0, \$err);

my $count = 0;
sub process_pkt {
    my ( $user_data, $hdr, $pkt ) = @_;
    $count++;
    $SIG{ALRM} = sub { printf ("%16.5f %d\n", time, $count); $count = 
+0 };
#    setitimer(ITIMER_REAL, 0.5, 0.5);
    alarm(0.5);
}

Net::Pcap::loop( $pcap_t, 0, \&process_pkt, "argument");
Net::Pcap::close($pcap_t);
[download]

1069653942.70856 6
1069653948.50819 69
1069653949.46479 2
1069653952.55703 4
1069654021.47634 6
1069654026.47576 4
1069654147.79127 2
1069654173.53735 6
1069654174.43908 2

probably, both packet capturing and alarming are too much for perl, to do it precisely the way we want.

Can you please elaborate on "printing packets/second". Net::Pcap doesn't seem to have any function that would capture packets in regular intervals of time. Any help about how I can get "no of packets/second" will be very helpful.

Thanks,
prakash.

$now=time;
$packets_sec = $packets / ($now - $lasttime);
$lasttime=$now;
[download]

is what I was thinking of. It just helps make up for an irregular timer a little bit, as if the timer took longer, there will be more packets and the elapsed time will be longer, balancing things out somewhat.

Those are really irregular. I wonder if the timer is only going off when packets are received?

If there's some kind of bad interaction between the alarms and the packet capturing (for example, Net::Pcap; is setting its own alarms), one approach would be to split up the packet code and the monitoring code into two processes. The packet sniffing code would just listen for packets, and whenever it found one print something to its standard out. Meanwhile, the monitoring code would count the number of times the packets sniffer printed, and when the alarm went off would print the result. That would split the alarm code and packet code into two seperate processes, so they can't interfere with each other.

Still, that sounds a bit elaborate. Perhaps somebody who knows Net::Pcap better than I do can give you better advice.

sgifford, I don't think the problem is Time::HiRes.

The real issue here is that, Tk affects how events get handled. In a similar context, I noticed in the past that, when you use sleep function inside Tk program, sleep just functions as a drunk person.

The benefit to utilize Tk after is to give Tk the centralized control of periodical events.