;Date 16 Jan 93 00:45:05 From: Uucp@1:125/555 To: Tomj@1:125/111 Subject: the latency collection... Options: kill-sent private ;Status: (read 2 times) ;INTL 1:125/111 1:125/555 From kumr!sug.org!mis From: mis@sug.org (Mark Seiden) To: tomj@fidosw.fidonet.org Date: Fri, 15 Jan 93 16:35:17 -0500 Xref: world comp.protocols.ppp:522 comp.dcom.modems:11827 Path: world!uunet!sun-barr!male.EBay.Sun.COM!c ronkite.Central.Sun.COM!exodus.Eng.Sun.C OM!appserv.Eng.Sun.COM!sun!amdcad!netcomsv!wolfgang From: wolfgang@netcom.COM (Wolfgang Henke) Newsgroups: comp.protocols.ppp,comp.dcom.modems Subject: Latency: T1,56Kbit,modem (was:Re: Our experience with T3000s/PPP/KA9Q) Message-ID: <1992Feb14.230555.20416wolfgang@netcom.COM> Date: 14 Feb 92 23:05:55 GMT References: <1992Feb13.083710.9253wolfgang@netcom.COM> Organization: Netcom - Online Communication Services (408 241-9760 guest) Lines: 37 Here some more latency data, including a T1. Please excuse me if I include the data I posted earlier again. This is only intended to facilitate a comparison between the numbers. Sun----9600 bps modem---codec--a couple miles---codec-----modem-----delfin.com Sun----DSU-----56 to 64 Kbit/s digital leased line-------------DSU--CALNet-pa1 Sun----DSU-----T1 1.34 to 1.536 Mbit/s digital leased line-----DSU-Barrnet.net The physical distance for both 56 and T1 is a bit over 12 miles and very close to each other. The command used was ping -s host packetsize-8. Then I just looked at a couple screenfull outputs and stopped. The lowest ping time reached during this run is recorded in the table below. Packetsize 9600bps modem link 56Kbit/s T1 ~1.5Mbit/s 16 230 29 0 32 230 30 0 64 310 40 0 128 400 60 9 256 560 100 10 512 830 130 20 1024 1510 350 30 2028 - - 50 2048 - 500 - I could not decrease the packet size under 16, that is 8 data bytes and 8 header bytes. At 2048 total bytes the modem link data was not reliable due to packet loss. So I did not enter a figure. The maximum data packet size to reliably return on the T1 was 2020 bytes. I added a new row to reflect this. -- ______________________________________________________________________________ Wolfgang Henke wolfgang@henke.sf-bay.org wolfgang@netcom.com Newsgroups: comp.dcom.modems Path: world!decwrl!netcomsv!mork!wolfgang From: wolfgang@netcom.com (Wolfgang Henke) Subject: DIGICOM V.32bis V.42bis fax modem: Test and Offer Message-ID: Date: Wed, 06 May 92 06:13:52 GMT Organization: Netcom Ever since the Digicom 9624LE+ showed the best performance in Vernon Schryver's recent SLIP ping tests (appended) I was interested in Digicom modems. Here are my test results of the new Digicom Systems Inc. lower priced Scout Plus V.32bis V.42bis fax modem, which is also based on the Analog Devices DSP chipset. Data throughput: Scout+ to T2500 V.32 V.42bis compressed 1050 cps Scout+ to T2500 V.32 V.42bis uncompressed 1750 cps Scout+ to T3000 V.32bis V.42bis compressed 1600 cps Scout+ to T3000 V.32bis V.42bis uncompressed 1900 cps(*) Scout+ to USR DS V.32 V.42bis compressed 1050 cps Scout+ to USR DS V.32bis V.42bis compressed 1600 cps Modem delay: Scout+ from Palo Alto to the Nat'l Institute of Standards time service in Colorado at 1-303-494-4774 using the echo feature. The one way delay is 75 msec. (The 16550 causes ~1.3 msec of this, taken at 1200 baud). This number compares well with other high speed modems. Interactive response: Smooth and zippy at V.32 V.42bis (T2500) and V.32bis V.42bis (T3000) to SunOS on Solbourne Series 5 multiprocessor system. Smooth to BBS in Colorado with unknown V.32 modem. Smooth to BBS in Berlin, Germany (but large satellite latency, estimated at 500 msecs). Smooth and zippy to 3 different local USR DS BBS systems based on PCboard/DOS 3.3 and CBBS/OS2. The modem is based on an Analog Devices 2101 DSP chipset which performs at a cycle speed of ~83 nsecs. Some might translate this into 12 MIPS and even multiply this number to reflect the three parallel arithmetic processors. I do not know if this is justified. There are two EPROMS with 1 MB and 512 kbytes. The DTE speed was locked at 57600 baud for all tests. New applications with this DSP can be anticipated in the future I hear, direction multimedia, ISDN, voicemail etc. The entry marked (*) was expected to have a higher data throughput but was limited due to a DTE speed of 19200 baud at the receiving modem. The Scout can initiate and respond to rate renegotiations. The speaker is scratchy and has no volume control besides ON, OFF and ON until the carrier is detected (default). The RJ11s do not connect through to a second line on the same RJ11 cable (because the lines are used for PBX signaling in the 9624LE+). The fax software was easy to install under DOS 3.3 and tested satisfactorily faxing to another fax machine across town as well as using MCIMail with the fax option. If there is enough interest I could offer these modems to readers of this newsgroup for $320 in a one time Usenet offer. Send email if interested. Here again the features: DIGICOM Scout Plus V.32bis, V.32, V.42bis, V.42, V.22bis fax modem 300-14400 bps data, 57600 baud DTE speed, mnp 2-5, Group 3 Fax, 9600 bps fax, Dosfax Lite and Winfax Lite software, Qmodem software, adaptive handshake, auto line monitor and retrain, initiates and answers retrain requests, 5 year warranty, internal version has 16550, external version is $320 and internal $312, Compuserve coupon. ---------- start appended file -------------- ~Newsgroups: comp.dcom.modems ~From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) ~Subject: Re: SLIP Propagation Delays Organization: Silicon Graphics, Inc. Mountain View, CA ~Date: Mon, 16 Mar 1992 22:40:16 GMT Enclosed are my results after testing a pair of ZyXEL with "V 4.04" EPROM's. Their latency is much improved, but their throughput is as before. Their latency is strangely bimodal. modem latency speed -------------------------------------------------------------------- Telebit T2500 to T2500 245 msec 1200 bytes/sec ("9600/LAPM" (v.32) at 19.2 DTE) When saturated, the modems would lock up with DCD + and CTS -. T3000 202 msec >3600 bytes/sec ("38400/LAPM/COMP/14400") 38.4 is not fast enough to overload the T3000's compressor with the repetative `ping` "data". --------------------------------------------------------------------- ZyXEL U-1496E ("U1496E 122091") 279 msec 3100 bytes/sec ("38400/V32b 14400/V42b") U-1496E ("U1496E V 4.04") 203 or 223 msec 3100 bytes/sec --------------------------------------------------------------------- Digicom Systems, Inc (DSI) 9624LE+ 163 msec 3550 bytes/sec ===================================================================== latency: `ping remotehost` for at least 60 seconds and note the quickest response. speed: `ping -s xxxx remotehost` for at least 20 seconds, and observing that the delay is not steadily increasing. The number 'xxxx' is the largest round number at which the modems seem to keep up. The first test is intended to measure the latency of the modems. The second depends on full-duplex throughput and modem compression. The data in the packets has low entropy, consisting of ICMP and IP headers and "counting bytes" (1,2,3,...). The packets in the first test are 3+84 bytes long (cslip framing, IP, ICMP, data). These tests are not real modem throughput measurements. They might almost be similar to SLIP traffic. The systems were running 4.3BSD-(mostly)reno TCP/IP stacks in SGI's IRIX 4.0.1 SLIP with VJ cslip. (Cslip does not compress ICMP ECHOs.) The MTU was 512. Each system used an intelligent serial board with modified firmware which can run 4 ports each at 38.4b/s or 5 ports at about 34KBytes/sec aggregate, measured by running several `cp bigfile /dev/ttyz` to loop-back cables. The drivers on the serial ports add as much as 20 milliseconds of (intentional) latency. Timing is done with the IRIX "fast timers" turned on. RIP, time service, and DNS traffic is on to keep things from being completely artificial. The phone lines are all in the same CO. Vernon Schryver, vjs@sgi.com ---------- end of appended file ---------------- -- _________________________________________________________________________ Wolfgang Henke wolfgang@henke.sf-bay.org wolfgang@netcom.com From: wolfgang@netcom.com (Wolfgang Henke) Newsgroups: comp.dcom.modems Subject: Re: Maximum uucp throughput over V.32bis? Message-ID: <-ldl##+.wolfgang@netcom.com> Date: 13 Jun 92 06:10:38 GMT References: <1992Jun12.213638.25730@jwt.UUCP> Organization: Netcom Lines: 30 john@jwt.UUCP (John Temples) writes: : keep streaming. Is this analysis correct? Do the latency times that : were posted here (which were in the range of 200 ms) include the : round-trip travel time, or only one way? Let me answer this since I believe that Vernon Schryver, the resident latency expert, recently moved to Colorado, away from SGI here in silicon valley. I sure wish we could continue to enjoy his expertise. The ping latency tests published here all used ICMP packets and measured the round trip time from transmitting to remote and back to the transmitting Unix workstation. Modems like the Digicom 9624LE+ performed very well with about 160 ms. Many others had times of 200 ms or more. There is an easy way to check your modem latency even without using a Unix workstation. Dial into the National Bureau of Standards Time Service in Colorado and use their echo feature to measure the one way delay between you and the time signal in Colorado. For 2400 bps modems its about 40 ms, more for high speed modems. The V32bis Digicom Scout Plus, my favorite modem, takes about a 75 ms one way delay. So, it seems that the modems I know have a shorter round trip delay than the number you calculated. The NBS time service number is 1 (303) 494-4774 and uses 1200 bps. -- _________________________________________________________________________ Wolfgang Henke wolfgang@henke.sf-bay.org wolfgang@netcom.com Path: world!uunet!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!ns-mx!isca From: isca@icaen.uiowa.edu (Iowa Student Computer Assoc) Newsgroups: comp.dcom.modems Subject: Speed tests on the Supra v.32bis modem Message-ID: <12098@ns-mx.uiowa.edu> Date: 10 Apr 92 03:27:07 GMT Sender: news@ns-mx.uiowa.edu Organization: isca Lines: 65 I recently did some thruput tests on various modems here at the U of Iowa using SLIP (Serial Line Internet Protocol) to give me some timing measurements. The results were posted to this group. Unfortunately, the Supra modem came in after most of the modems had been sent back. I did do a little testing with the Supra, and since it's the hot topic here these days, I thought I'd post the results. The bottom line of the testing was that the Supra did well on compression but did very poorly on latency testing. So the modem would be fine for downloading and general interative stuff, but not as good for things like SLIP or X-remote. Modems: ZyXEL U-1496E Codex 3260 series USRobotics V.32bis NEC N9635E Supra FAX Modem v.32bis Ping Times (ms) [Measures latency - lower number are better] | Local Remote | NEC USR Codex ZyXEL -------+----------------------------- NEC | 262 230 235 Codex | 233 171 230 202 USR | 146 179 168 Supra | 266 ASCII FTP transfer rate (Kbytes/sec) [Measures v.42bis compression - higher numbers are better] | Local Remote | NEC USR Codex ZyXEL -------+----------------------------- NEC | 3.31 3.32 3.16 Codex | 2.62 2.70 2.68 2.71 USR | 3.29 3.32 3.34 Supra | 3.30 Binary FTP transfer rate (Kbytes/sec) | Local Remote | NEC USR Codex ZyXEL -------+----------------------------- NEC | 1.50 1.51 1.50 Codex | 1.50 1.50 1.50 1.49 USR | 1.49 1.50 1.53 Supra | 1.48 If anyone would like info about the setup, mail me. - dave -- ----------------------------------------------------------------------------- | David Lacey | Try the ISCA BBS and Archives | | President, Iowa Student Computer Assn | Telnet/FTP: grind.isca.uiowa.edu | | The University of Iowa | telnet/rlogin in as iscabbs | | David-Lacey@uiowa.edu | 3 GIG of disk space and growing | ----------------------------------------------------------------------------- Path: world!uunet!zaphod.mps.ohio-state.edu!mi ps!news.cs.indiana.edu!umn.edu!umeecs!dip.eecs.umich.edu!dmuntz From: dmuntz@dip.eecs.umich.edu (Daniel A Muntz) Newsgroups: comp.dcom.modems Subject: Re: V.32bis modems, which one? Message-ID: <1992Feb6.041000.8773@zip.eecs.umich.edu> Date: 6 Feb 92 04:10:00 GMT References: <1992Feb04.231037.27239@ecst.csuchico.edu> <1992Feb6.002559.5233@celit.fps.com> Sender: news@zip.eecs.umich.edu (Mr. News) Organization: University of Michigan EECS Dept., Ann Arbor Lines: 12 In article vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >The latency I measured for ping's over a pair of T3000's was 202 msec, >compared to 163 msec for a pair of Digicom (DSI) 9624LE+'s. I could not >saturate the T3000's with only a 38.4kb/s DTE link, but could the DSI's. >(Of course, this is a measure of compression on low entropy data.) I've had similar results: a pair of T3000's shows ~200 msec latency while a pair of USR DS's has ~165 msec latency. (v.32bis v.42bis 38.4k-interface in both cases) -Dan Muntz dmuntz@dip.eecs.umich.edu Path: world!uunet!sun-barr!ames!sgi!rhyolite.wpd.sgi.com!vjs From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Newsgroups: comp.dcom.modems Subject: Re: V.32bis modems, which one? Message-ID: Date: 7 Feb 92 19:56:30 GMT References: <1992Feb6.002559.5233@celit.fps.com> <1992Feb7.121047.26252@athena.mit.edu> Sender: vjs@rhyolite.wpd.sgi.com Organization: Silicon Graphics, Inc. Mountain View, CA Lines: 34 In article <1992Feb7.121047.26252@athena.mit.edu>, lstein@athena.mit.edu (Lincoln Stein) writes: > I've been following the benchmark figures for various modems with > interest but puzzlement. > > What do these figures mean? Specifically, what is latency, and how do > you measure it? Under what circumstances does latency become the > limiting factor in the modem's performance? "Latency" in this case is how long it takes the modem to get off the dime and do something. I intended my measurements with `ping` to suggest the delay between when I type a character and when it appears on the screen. Ping is not a very good measure of that delay, because it involves an 80-byte burst of traffic, while VJ-cslip involves bursts of 5 bytes or so. A better measure of interactive TCP/IP/SLIP latency would be a tool which bounces single bytes off the standard echo servers. However, ping is already written and common. Many people can repeat and confirm or refute my measurements, without having to port a program. People can try the same test on modems I don't have, although with caution because they won't have the same UNIX hardware and software I have. I do not know how relevant ping latency is for dumb terminal uses of v.32bis modems. I doubt that a modem which does well with ping's would do badly on single characters, but I'm not sure a modem with unimpressive ping latency would be as bad on single characters. Performing the ping latency measurement is trivial, after you have a SLIP link running. Just read the ping man page, and try it. Vernon Schryver, vjs@sgi.com P.S. Don't you just hate "followup-author" without warnings?