Re: Net::Ping with threads

Without threads. Class C(254 hosts) - less than a second. Perl v5.8.4; nt 5.1.2600(winxp):

use strict;
use Net::Ping;

$|++;

my $net   = '194.153.145.';
my @hosts = 1..254;

$_ = $net.$_ for @hosts;

my $p = Net::Ping->new("icmp");

$p->{'timeout'} = 0.003;

for (@hosts)
{
    print "$_ is ";
    print "NOT " unless $p->ping($_);
    print "reachable.\n";
}


print time - $^T
[download]

Comment on Re: Net::Ping with threads Download Code

Replies are listed 'Best First'.
Re^2: Net::Ping with threads by Spesh00 (Initiate) on Mar 15, 2005 at 20:59 UTC
The only real difference I'm seeing between that script that the original from the perldoc is the fact that your timeout is 0.003.. However when I run it with even with a .1 timeout value it dramatically increases the speed. I'm guessing my speed loss is directly proportional to the number of hosts that currently aren't pinging. I'm going to talk to the powers that be and see if having a subsecond timeout value is acceptable considering this is going to be more or less on the same subnet (within 4 switches or so).. The real aim of threading this system out is to prevent a host from stalling the rest of the scan. While a ping of 3 seconds would be outrageous, if the box responds it's not technically down.. However the cumulative effect of a number of boxes with a 3+ second delay causes a huge effect to the overall scan. I want to be able to catch those delays, but not when the rest of the scan could continue on merrily.	[reply]

Replies are listed 'Best First'.

Re^2: Net::Ping with threads
by Spesh00 (Initiate) on Mar 15, 2005 at 20:59 UTC

The only real difference I'm seeing between that script that the original from the perldoc is the fact that your timeout is 0.003.. However when I run it with even with a .1 timeout value it dramatically increases the speed. I'm guessing my speed loss is directly proportional to the number of hosts that currently aren't pinging. I'm going to talk to the powers that be and see if having a subsecond timeout value is acceptable considering this is going to be more or less on the same subnet (within 4 switches or so).. The real aim of threading this system out is to prevent a host from stalling the rest of the scan. While a ping of 3 seconds would be outrageous, if the box responds it's not technically down.. However the cumulative effect of a number of boxes with a 3+ second delay causes a huge effect to the overall scan. I want to be able to catch those delays, but not when the rest of the scan could continue on merrily.

[reply]