Re: _ping_more / dropping pings

i played around with BufferSize, increasing it from 65536 to 1048576 by powers 
of two; i didn't see an effect on the number of dropped pings (my test 
'mass-ping' session was pinging 510 addresses, of which ~360 were responding)

i wanted 'netstat -s' output to show me dropped ICMP messages, i.e. messages 
overwritten in a buffer ... but 'wanting' and 'happening' are too different 
things ... i don't see a counter tracking such an event:

Icmp:
     588970 ICMP messages received
     285250 input ICMP message failed.
     ICMP input histogram:
         destination unreachable: 362369
         timeout in transit: 21028
         echo requests: 11771
         echo replies: 193799
     2375973 ICMP messages sent
     0 ICMP messages failed
     ICMP output histogram:
         destination unreachable: 29077
         echo request: 2335125
         echo replies: 11771
IcmpMsg:
         InType0: 237002
         InType3: 363685
         InType8: 11812
         InType11: 21028
         OutType0: 11812
         OutType3: 29098
         OutType8: 2396328

i tried assigning '100' to $POE::Component::Client::Ping::PKTSIZE 
($POE::Component::Client::Ping::PKTSIZE = 100); i didn't notice a change in behavior

setting Parallelism makes a difference though; i'm at 120 at the moment, which 
is larger, and simpler, than the ~30+ i can reach using my home-built throttling 
scheme


i'm trying to think of additional ways in which i can explore this issue.

-printing the value of BufferSize, as a way of uncovering what the OS default 
is?    what i really want is to find some counter which tracks how many buffer 
slots get overwritten ... and of course, that counter may not exist

-i've poked through /proc/sys/net/ipv4/icmp* -- i see ways to throttle 
*outbound* ICMP replies ... but nothing related to how the box accepts inbound 
frames

-dig up copies of Stevens' and Comer's books, see if they discuss how this is 
typically handled

additional suggestions?

--sk

Tony Cook wrote:
[...]
>>
>> or perhaps somewhere in between:  perhaps there is an OS buffer which
>> holds the ICMP Echo Reply frames and unless POE pulls them out of the
>> buffer fast enough, the buffer will overflow and POE won't see those
>> responses
> 
> I'd be inclined to think it was this.
> 
> POE::Component::Client::Ping->spawn has a BufferSize parameter you
> could use to check - try setting it fairly large, like 65536, and see
> if that reduces the number of lost ping responses.
> 
> Tony