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
Could be due to StopWatch object not resetting properly in final clause (Ping.cs: line 404), could use StartNew (maybe not...) or Reset (maybe not either..) instead of restart.- Alternatively could use Timer class for some more low level control, utilizing its .interval method. HOWEVER there could be concerns here about accuracy
Could be how we are using timespan in display.cs? (Spoilers I think Display uses DateTime not timespan)- Could possibly use raw StopWatch data to get more accurate readings, rather than using methods as shown here and also here
Todo
-
Add feature to specifiy level of detail with time (decimal 1.23 or just 1 ms) -
Implement more accurate and safe time management or look into way of isolating PowerPings properties or resources being used in other instances. Good article on good .NET practices, mentions app domains and how the code is structured on a low level and Another good one relating more to performance
Links
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
@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.