Re^8: Unexpected Timing spikes using Time::HiRes

[desemondo]

At present, i'm using it in a pair of simple 'ping' scripts.

Now, before you say, I should just use Net::Ping or another varient, the reason I'm rolling my own is that I need to a 'ping' tool that goes to the top of the tcp stack, and not only halfway. (I have seen many issues where a server is hung but still responds to icmp pings.) Plus, I wanted to learn a bit more about how sockets and InterProcess communication work, by making my own.

In troubleshooting a timing issue in another application, these scripts will hopefully rule out our network and point the finger at the application (or maybe the server...).

(OT)
Due to this apparent timeslot priority issue, is there any way to read from a non-blocking socket without sleeping? I've found that unless I sleep inside the socket-read loop, the CPU bleeds like crazy...

[BrowserUk]

is there any way to read from a non-blocking socket without sleeping?

Yes. (Kinda:). See select or easier, IO::Select::can_read([TIMEOUT]). can_read() will block until there is some data available to be read, or the timeout elapses (if you suppy one). In reality, it is just doing the sleep for you.

As for timing your ping tool. I think you are being way optimistic if you are expecting to detect server errors within less than 100th of a second. That's effectively what you are saying when you are concerned about a 15ms delay.

Even on a modern Gb/s LANs taking action on the basis of a delay of much less than 1/10th of a second would be wildly premature.