Article View: demon.tech.mac
Article #77Re: Determining modem speed, packet loss, other diagnostics etc.
From: Hugh Thomson
Date: Sat, 17 Jun 1995 00:00
Date: Sat, 17 Jun 1995 00:00
54 lines
3323 bytes
3323 bytes
In article <AC06E7A296686797@jims.demon.co.uk>, subrosa@jims.demon.co.uk (Jim Smith) wrote: >kay, I now have MacTCP Monitor. Can anybody explain precisely what the >windows mean as it doesn't appear to be in the ReadMe > > >Jim Log on to demon. activate your newsreader. open MacTCP Monitor. Two windows appear. A small squarish one with an array of boxes, 6 x 6? maybe and a longer oblong window with initially 3 dividing horizontal lines marked 512, 384,256 and 0. Commence download of news. The small square window will show, initially in the top left hand box, a light blue colour. This indicates that you have one channel open through TCP. This box changes colour i.e. deep blue, green, red depending on whether your modem is transmitting, receiving, or in standby mode. The larger box will proceed to show a graph of the second by second state of TCP moving from right to left. As traffic passes through TCP the graph senses the transmission speed. i.e. if you get a burst at say 1608, the dividers on the graph will alter to read 1608,1206,804,0 with a green line (receiving colour) reaching to the top of the graph. The fastest speed achieved on any seond resets the graph. One of the groups I take the headers for is comp.sys.mac.comm. This is a fairly high traffic group and will frequently reset my graph max to 3000+ or even occasionally 4000+ b/s as the headers download. I take demon local complete articles and waching say 200 articles download you can see that all the short articles with maybe only 5/700 bytes including headers can only be transmitted at that rate, but long articles of more than 1800 bytes will transmit probably at 1600+ b/s. Incidentally, I would tend to disagree with those who complain about long sigs a a waste of bandwidth. While I agree that reading long fancy (or otherwise) sigs can get boring, unless they cause a message that would otherwise be less than about 1600 bytes to go over that figure, I do not believe that it affects total throughput time when downloading news type articles. If you simultaneously use another service, ie FTP, Anarchie, email, etc. further small boxes go active. I think it is probable that just downloading news is wasteful of time. If you can arrange to FTP files you want at the same time, the modem throughput would appear to improve. This is *my* understanding of MacTCP monitor. If any of the comms guru's tell me I'm talking through my hat, I bow to superior knowledge. Hugh:
Technical Details
Message-ID:
<AC0843DA9668255B0D@thrl.demon.co.uk>Path:
arc1-ca.pugleaf.net!unknown!not-for-mailReferences:
<6346064@thebeast.demon.co.uk> <95061114512100033@thaw.demon.co.uk> <AC06E7A296686797@jims.demon.co.uk>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 10b5a2,7af16a15ce95ba6d X-Google-Attributes: gid10b5a2,public X-Google-Thread: 103cba,7af16a15ce95ba6d X-Google-Attributes: gid103cba,public X-Google-Thread: 10f989,7af16a15ce95ba6d X-Google-Attributes: gid10f989,public From: hugh@thrl.demon.co.uk (Hugh Thomson) Subject: Re: Determining modem speed, packet loss, other diagnostics etc. Date: 1995/06/17 Message-ID: <AC0843DA9668255B0D@thrl.demon.co.uk> X-Deja-AN: 104589241 distribution: world x-nntp-posting-host: thrl.demon.co.uk sender: news@news.demon.co.uk references: <6346064@thebeast.demon.co.uk> <95061114512100033@thaw.demon.co.uk> <AC06E7A296686797@jims.demon.co.uk> organization: T C Estimates newsgroups: demon.tech.mac,demon.ip.support.mac,comp.sys.mac.comm