I am assuming from your message that you are measuring the RTT of the "Ping" probe on IP. If that is not correct, please let me know.
InterMapper computes RTT by sending an echo request and recording the "send" timestamp. When an echo response arrives, InterMapper records the "receive" timestamp. To record the "receive" timestamp on a system using Open Transport, InterMapper relies on the OT notifier function which runs at "deferred task time"... this is related to system interrupt time, but of a lower priority. All Open Transport notifiers run at deferred task time, so running InterMapper on a machine with a lot of network activity (ie a lot of deferred tasks), or perhaps a periodic processor-intensive deferred task may elongate ping times.
On classic Mac OS, Timbuktu is probably doing everything in response to your network commands at deferred task time, or close to it. (That's just a guess; I don't have TB2).
There may be ways to improve the accuracy of InterMapper's timestamps under Open Transport on OS9, but it would probably involve a system extension of some other ad hoc programming. We are unlikely to implement such a solution unless the coding is obvious and easy; we have too many other features we'd like to add to InterMapper.
On Mac OS X, InterMapper uses the native sockets API to ask the OS for the time that the packet arrived. This is a front-door function call that is much simpler and less prone to interference from other application-level software. The Mac OSX network stack timestamps the received packet closer to the time when it is actually received by the network hardware so it should also be more accurate. If you can, I would run InterMapper under Mac OS X 10.2.x.
Regarding the "Finder quits" issue: that sounds like a bug in InterMapper, possibly a conflict with TB2. Does it happen only when you quit InterMapper from within your TB2 controlling session? Have you ever seen it when quitting InterMapper from the console?
Thanks,
Bill Fisher
Dartware, LLC
http://www.dartware.com
On Monday, December 23, 2002, at 01:27 PM, [EMAIL PROTECTED] wrote:
I'm using IM 3.7.1 Classic with MacOS 9.2. Intermapper is the only thing running on the system.
One of the parameters I monitor is round-trip time to many of the monitored. I've noticed that after I restart the system, RTT to "close" (same LAN) devices is small, as expected (1-3 msec, typically). Devices reachable across WAN links are longer, of course (~20msec). These are the times I expect and are consistent with the RTT's obtained when pinging from other, non-IM devices.
But after IM has been running for a while, or after it has been stopped and restarted, there is a bias of ~15-20 msec added to all the times. LAN RTT's become ~18-20, WAN RTT's become ~35-40msec and stay there until I restart the computer when they return to their low values. Ping times from other non-IM devices remain small as above.
Perhaps related, I notice that whenever I quit IM, Finder also quits. This happens every time.
On Thursday, December 26, 2002, at 07:44 PM, [EMAIL PROTECTED] wrote:
I�m running Timbuktu Pro 5.3.2 on the IM system for remote administration.� When I was composing my previous message, I connected using TB2 to check memory & versions etc, but didn�t restart IM.� But the RTT bias returned concurrent with that connection.� Often, when I restart IM, it�s thru a TB2 connection.
Are there issues between TB2 Pro & IM?� Is there another remote administration solution (besides TB2) that works with a Windows client?� Would moving to OSX offer any options?� IM Remote doesn�t quite have the functionality of the native application yet so I can�t rely on that.
____________________________________________________________________ Note: To unsubscribe from this mailing list, please send email to: <mailto:[EMAIL PROTECTED]> Thanks!
