#PINGPLOTTER RELIABLE UPDATE#
#PINGPLOTTER RELIABLE SOFTWARE#

Another thing we noticed is that running MTR alongside PingPlotter seems to cause both programs to have varying levels of reliability. We recommend trying anything between 3005.ī. However, we encourage you to try and play around with those to see if certain port settings work better on your machine.

We found better results by expanding the port range to 30000-40000. Change the UDP port settings on the Engine settings page. We were hoping to have some more solid answers for you about it before responding, but for now here are a couple of things you might try with UDP:Ī. We’ve been running MTR alongside PingPlotter and have noticed some interesting behavior. The issues with UDP you mentioned have been a hot topic in the (currently virtual) office the past couple of days. Once more, thank you for providing so many details, it makes getting to the bottom of these problems much simpler.Ĥ. As far as the issues with ICMP.dll and ICMP using raw sockets, we have tickets logged for these issues now and will be looking into them shortly. Again, thank you for reporting the packet delay not being able to switch off of ‘Auto’! This is definitely a bug and we have a ticket logged to address it in an upcoming release.ģ.

We appreciate the details provided regarding the memory leak, they helped us reproduce the issue in-house and we are currently working on tracking down the source.Ģ. We have tickets logged for each of these issues but I wanted to respond to each of the issues above.ġ. 'UDP mode (mtr style engine) is nowhere near MTR accuracy, 70% of all internet target have 100% loss on destination (only the destination), while the intermediary hops behave normally.' UDP packets are not received as well as they should be.

#PINGPLOTTER RELIABLE UPDATE#

'Routes changes don't update in realtime and most of the times the full trace is a mess which doesn't match reality (mixes old routes with new ones), it gets fixed by restarting PingPlotter or resetting targets'ĥ. 'ICMP.dll option is limited badly, I max at most 13-15% CPU usage and instead of getting close to 3600 samples per hour I only get ~ 1500-1600. ICMP.dll has bad performance with 300 targets at a 1-second interval This is a real bug that we need to address but in your case, it seems you need to keep this on Auto to achieve the best resultsģ. A bug prevents the user from changing packet delay from 'Auto'. 'After 1 day of running the process goes from ~500MB RAM usage to 2GB+'Ģ. Here is a list of what we took away from your post: I want to start out by apologizing that this has taken us so long to respond to but this was a pretty good list of issues for our QA team to investigate.įirst I want to make sure that we have the issues that you reported straight. #3656 - 04/27/20 06:07 PM Re: Performance, multi-threading, reliability issues

#PINGPLOTTER RELIABLE SOFTWARE#

May I ask, is there any software engineer that runs the latest build using hundred of targets and test for reliability and the spiking memory leaks?Īll of the 3 traceroute engine options has it's own design flaw which needs to be addresed, some machines have 16cores on a desktop CPU and can't make use of proper resource utilization and reliability on Windows PCs. Is there any way to get MTR behaviour implemented with Pingplotter so we can have a reliable and fast way to use Pingplotter? Does this mode need a special build of winpcap/npcap to behave normally?Īlso, a maintenance option which restarts pingplotter is needed, after 1 day of running the process goes from ~500MB RAM usage to 2GB+, it's a serious bummer, sometimes my machine with 8GB of ram goes into serious swapfile usage when pingplotter eats 6GB+ of RAM. UDP mode (mtr style engine) is nowhere near MTR accuracy, 70% of all internet target have 100% loss on destination (only the destination), while the intermediary hops behave normally. Routes changes don't update in realtime and most of times the full trace is a mess which doesn't match reality (mixes old routes with new ones), it gets fixed by restarting PingPlotter or resetting targets. raw ICMP option is fast, I get 50% cpu usage on average, 3500+ samples per hour on all targets, also stuck with packet send delay in 'auto'. Adjusting packet send delay doesn't work, stuck in 'Auto'. ICMP.dll option is limited badly, I max at most 13-15% cpu usage and instead of getting close to 3600 samples per hour I only get ~ 1500-1600. Currently tracing ~ 300 targets with auto-save enabled and 1 second interval, and found some differences between engine options, using an i7-2700 4core/8threads cpu with SSD and Windows 10:

Pingplotter reliable