Hi Poe, thanks for taking your time acknowledging my complaints
1. 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.
Glad to hear that. I see a potential downgrade from the 4.x builds where it was possible to only use memory and overwrite old samples once the samples threshold is reached. The full disk dump while tracing a lot of targets seems to take a toll on the memory usage.
2. 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.
3. 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. Once more, thank you for providing so many details, it makes getting to the bottom of these problems much simpler.
Great to hear that.
4. The issues with UDP you mentioned have been a hot topic in the (currently virtual) office the past couple of days. We’ve been running MTR alongside PingPlotter and have noticed some interesting behavior. 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:
A. Change the UDP port settings on the Engine settings page. We found better results by expanding the port range to 30000-40000. However, we encourage you to try and play around with those to see if certain port settings work better on your machine. We recommend trying anything between 30000 and 65535.
B. Another thing we noticed is that running MTR alongside PingPlotter seems to cause both programs to have varying levels of reliability. In other words, running MTR and PingPlotter simultaneously seems to cause both to report worse results at varying times than they would if run alone.
I don't run MTR alongside Pingplotter, I just want the source code of MTR inspected and make the UDP engine mirror exactly the MTR behaviour of handling ICMP port unreachable packets (type 3, code 3) for proper consistency.
I've already expanded the UDP port range by a lot, even 33000-65535 but it's unreliable nonetheless.
The code is opensource, some links:
https://github.com/traviscross/mtr - for the UNIX mtr
https://github.com/White-Tiger/WinMTR/releases - for the WinMTR (both original appnor version and the redux fork edition)
1. If you are not already on the latest version of PingPlotter (5.15.7), we recommend that you update as there have been numerous enhancements around resource usage recently. The latest version can be found here:
https://pingplotter.com/download2. If you are not running as a service, we recommend you install PingPlotter with that option enabled as users generally have better performance as a service. In that same vein -- as a temporary measure -- you can set up a Window Task Schedule to automatically restart the service for you whenever you like (presumably overnight) to fix the resource usage growth. We have a knowledge base article on how to accomplish this here
http://www.pingman.com/kb/603. Last thing I promise — It would be most helpful if you could send in a support ticket (Help -> Email PingPlotter Support). This will help us dive into these issues further to be able to address them more thoroughly.
I'm on the latest version.
The automatic restart of the service is a great idea, will make use of that.
Also, in service mode the performance is greatly improved with icmp.dll engine mode, it's almost as fast as using raw icmp mode. Thanks for the tip!
I will also make use of support tickets once I spot abnormal behaviours.
Thanks for your time.
Previous Topic
Index
