i use POE::Component::Client::Ping to emit lots of pings and i find that i have to throttle the number of pings i have outstanding; otherwise, POE::Component::Client::Ping doesn't see the responses
using a sniffer (tshark running on the box hosting my script), i can see that the ICMP Echo Reply frames arrive just fine (as far as tshark is concerned) i suppose that i could be seeing an effect somewhere in the OS, such that if the flow of returning ICMP Echoes exceeds some threshold, the NIC sees them, tshark sees them ... but somewhere higher up, a buffer overflows and Perl never gets them or, i suppose that the flood of responses overwhelms some buffer inside POE::Component::Client::Ping 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 notice that sometimes i can get away with several hundred outstanding pings at once; sometimes, not much more than thirty. i generally run with a ceiling of twenty (20). the variability depends on load on my box? i don't know this isn't a problem -- the total time it takes to ping the ~350 addresses i'm using as my test bed right now doesn't change, regardless of the size of my 'ping heap' but i'm curious. would anyone know where the overflowing buffer lives? if in the OS, how would i look to see its size? of inside POE, again, how would i identify its size? i'm running Perl 5.8.8, POE 1.03, POE::Component::Client::Ping 1.14 under CentOS 5.2 my code is visible at https://vishnu.fhcrc.org/ping/mass-ping the 'ping_nodes' subroutine is the master pinger ... with 'sub _client_start', 'sub _ping_more', and 'sub _client_got_pong' playing the usual roles --sk stuart kendrick fhcrc seattle, wa
