The platform is an Xserve running 10.2.3 Server with InterMapper 3.7.1 and Timbuktu 6.0.2...
I'm about to try out VNC and the Apple Remote Desktop product (and InterMapperd to remove the GUI dependency).
fwiw,
Charlie.
On Tuesday, December 31, 2002, at 02:07 PM, <[EMAIL PROTECTED]> wrote:
I'll investigate moving to OS X. I need some way to remote control from a Windows client, however. Most of my probes are SNMP so I don't know what times you are using.
I see the Finder Quit when quitting IM at the system console (w/o TB2).
-----Original Message-----
From: William W. Fisher [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 30, 2002 7:22 AM
To: InterMapper Discussion
Subject: Re: Round Trip Time bias
John:
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! ____________________________________________________________________ Note: To unsubscribe from this mailing list, please send email to: <mailto:[EMAIL PROTECTED]> Thanks!
-- C. Charles Winchcombe Group IT Infrastructure Architect Visy Industries 53 Charles Street� /� Coburg� VIC� /� Australia� 3058 Ph: +61-3 9286-2222 /� Fax: +61-3 9286-2338� /� ICQ: 4203990 PGP Fingerprint: 9880 18EA 5960 E164 283B� F927 2C75 A2D9 B472 84C2 "An error is the more dangerous the more truth it contains." -- Henri-Frederic Amiel ____________________________________________________________________ Note: To unsubscribe from this mailing list, please send email to: <mailto:[EMAIL PROTECTED]> Thanks!
