Killeroo/PowerPing

Ping time defaults to 0.1ms

Closed this issue · 8 comments

Behavior:

  • Starts when error or other packet type is received
  • Normally occurs when when data is recieved from other address than that being actively pinged (eg hub addresses like 192.168.1.255 etc)
  • Also occurs when another PowerPing instance starts pinging same target
  • Does not occur due to timeout

Could be caused by responseTime.Restart(), MSDN page states 'resets the elapsed time to zero, and starts measuring elapsed time.' could be prematurely starting stopwatch..

Solutions

Todo

Links

Also seems to happen after an error packet is received:

image

when pinging same address from another PowerPing instance time. Only occurs if pinging same address, time never recovers to normal readings only bounces between 0.1 & 0.2ms:

image

Found a way to replicate low timer value, at this commit 52c8069 when using graph mode, the timer always gives a value lower than 1ms. Should be used to try and debug the problem

image

Timer seems to correct when response time over 100ms occurs, maybe find a way of replicating?

@Killeroo Maybe not a timing issue but rather extra packets getting queued up in the receive buffer? For example if you have 2 instances pinging the same address with different messages (use -m and -dm), the first instance displays both messages, not just its own.

@jdpurcell Yeah your right, I'm almost certain this is whats happening. The issue then is how do we tell the packets apart. I thought a possible fix was putting a timestamp and/or a sequence number inside the message part of the ICMP packet, which we can then read when we receive the packet and track the sequence and response time more accurately. Not sure if there is a simpler solution though?

@Killeroo Without being too familiar with the code it's hard to say, but I'd think something like including a unique value per instance (e.g. a random number generated on startup or Process.GetCurrentProcess().Id), or even a unique value per packet (e.g. random number, sequence number, Guid) if necessary.

@jdpurcell A unique value per packet definitely makes sense, then we could have some sort of list or map to link the unique value to a packet sequence number and timestamp. It could be inserted before any text from --messages. Yeah sounds promising, I think I'll do some experimentation with it whenever I get a chance.