Folks: We have received several customer comments on the short-term packet loss feature of InterMapper 4.5. While the overall reaction to the facility is positive, certain aspects of the current implementation cause problems where InterMapper does not accurately report the true state of the network.
There seem to be two major concerns: 1) Device going down: When a device drops three packets (or four, or whatever meets the Down threshold), those dropped packets are counted in the short-term packet loss, and can dramatically increase the displayed rate. For example, if the short-term loss were 0%, and the device were turned off, InterMapper would mark it down after three lost packets. The three lost packets would constitute a 3% short-term packet loss, that would not return to zero until the device comes back up and 100 more packets had been successfully sent - a process that can take nearly an hour at a 30-second poll interval. 2) Actual burst of errors: If there were a burst of errors, InterMapper would quickly (and properly) increment the short-term packet loss. However, once the burst was over (e.g., after the problem was fixed) the high short-term packet loss would persist for another 100 packets. Proposal: The following suggestions could get around these problems. We are considering adding both of these strategies: 1) When a device goes down, InterMapper should "deduct" the lost packets from the most recent 100. That is, if three lost packets caused InterMapper to mark a device as down, InterMapper should ignore those three lost packets from the accumulation. (InterMapper already ignores additional lost packets when a device has been marked as down.) In the example above, the short-term packet loss would remain at zero. 2) We could add a new "Reset" button to the device's Status window that would reset only the Short-term packet loss. After the problem causing the burst of errors was cleared, you could open the device's status window and click Reset for the short-term value, and set it back to zero. Please give us your thoughts as to whether this would solve the problems you have seen. Many thanks! Rich Brown [EMAIL PROTECTED] Dartware, LLC http://www.dartware.com 10 Buck Road, PO Box 130 Telephone: 603-643-9600 Hanover, NH 03755-0130 USA Fax: 603-643-2289 PS This note has been sent to the InterMapper-Talk mailing list, as well as to the individuals who filed complaints/bug reports about the current implementation. Please respond either to the IM-Talk list or back to me, as you see fit. Thanks.! ____________________________________________________________________ List archives: http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ To unsubscribe: send email to: [EMAIL PROTECTED]
