From telecom-request@delta.eecs.nwu.edu Sat Aug 26 23:20:12 1995 by 1995 23:20:12 -0400 telecomlist-outbound; Sat, 26 Aug 1995 20:38:28 -0500 1995 20:38:26 -0500 To: telecom@delta.eecs.nwu.edu I have had various complaints about issue 358 from Thursday not getting delivered to a large number of names on the mailing list, so it is being retransmitted at this time. If you already have a copy, please excuse the duplicate as it appears most of the list does not have it. PAT TELECOM Digest Thu, 24 Aug 95 22:37:00 CDT Volume 15 : Issue 358 Inside This Issue: Editor: Patrick A. Townson Before You Call Telco (was Re: AT&T Credit For Cut Calls) (Peter M. Weiss) UCLA Short Course on Optical Fiber Communications (Bill Goodin) What Does Internet Information Transmission Really Cost? (A. E. Siegman) Online Telephone Directories Wanted (Bob Coret) Text to Speech Test Assistants Wanted (David A. Rivkin) Re: Telecom and the End of WW-2 (Mark Brader) TELECOM Digest is an electronic journal devoted mostly but not exclusively to telecommunications topics. It is circulated anywhere there is email, in addition to various telecom forums on a variety of public service systems and networks including Compuserve and America On Line. It is also gatewayed to Usenet where it appears as the moderated newsgroup 'comp.dcom.telecom'. Subscriptions are available to qualified organizations and individual readers. Write and tell us how you qualify: * telecom-request@eecs.nwu.edu * The Digest is edited, published and compilation-copyrighted by Patrick Townson of Skokie, Illinois USA. You can reach us by postal mail, fax or phone at: 9457-D Niles Center Road Skokie, IL USA 60076 Phone: 500-677-1616 Fax: 708-329-0572 ** Article submission address only: telecom@eecs.nwu.edu ** Our archives are located at lcs.mit.edu and are available by using anonymous ftp. The archives can also be accessed using our email information service. For a copy of a helpful file explaining how to use the information service, just ask. ************************************************************************ * * TELECOM Digest is partially funded by a grant from the * * International Telecommunication Union (ITU) in Geneva, Switzerland * * under the aegis of its Telecom Information Exchange Services (TIES) * * project. Views expressed herein should not be construed as represent- * * ing views of the ITU. * ************************************************************************ * In addition, TELECOM Digest receives a grant from Microsoft to assist with publication expenses. Editorial content in the Digest is totally independent, and does not necessarily represent the views of Microsoft. ------------------------------------------------------------ Finally, the Digest is funded by gifts from generous readers such as yourself who provide funding in amounts deemed appropriate. Your help is important and appreciated. A suggested donation of twenty dollars per year per reader is considered appropriate. See our address above. All opinions expressed herein are deemed to be those of the author. Any organizations listed are for identification purposes only and messages should not be considered any official expression by the organization. ---------------------------------------------------------------------- Here is a checklist that PSU computer support personnel have developed for dialup network users. Though it was customized to the PSU community, I think it is worthy of consideration in many environments. The author is Herman "Skip" Knoble who has given permission for me to re-post for non-commercial use. Pete Weiss -- Penn State (Qualified feedback to this posting is solicited, particularly for platforms not mentioned herein. Please send to: Skip Knoble, hdk@psuvm.psu.edu) Why Did My Penn State Successful Dial-Up Connection Drop? A Checklist by H. D. Knoble 08/15/95 The Pennsylvania State University Center for Academic Computing Library Computing Services Office of Administrative Systems Office of Telecommunications Once an Access dial-up connection is established at a data rate compatible with your modem and serial port to Penn State TCP/IP services, the connection may drop; the following is a check list of possible reasons for this specific scenario. We recommend that you copy and check this list before calling for technical assistance if and when you experience seemingly random connection drops (disconnections). This not only will help us; but it will help you improve the reliability of your microcomputer communications. The checklist follows: (1) a) Between the hours of Monday-Thursday -- noon to midnight, Friday -- noon to 6:00 p.m., and Sunday -- 6:00 p.m. to Midnight, the CAC Serial Protocol (dial-up) servers (xxx-xxxx, xxx-xxxx, and phone numbers at other Penn State locations) drop data (drop the modem connection) after 1 hour of Internet activity or after 15 minutes of inactivity. "Inactivity" is defined as no Internet data exchange. E.g., using Eudora to compose a letter taking more than 15 minutes to compose it while using no other Access clients; e.g., while connected using any Windows applica- tions that are not Access clients - like Word Perfect, Excel, etc. - for more than 15 minutes at a time would cause no Internet data exchange and so would be considered Internet "inactivity." b) Twenty-four hours per day, the OTC Serial Protocol (dial-up) servers (xxx-xxxx) drop everyone after one hour of inactivity. "Inactivity" is defined as no Internet data exchange. This was done because some people were staying connected (using a Server rack modem) for hours (sometimes 24 hours) at a time, even when not using their PC; therefore many others were often getting a BUSY signal when dialing the Servers. (2) In addition to (1) above, when accessing specific hosts through Telnet/TN3270 the following applies: a) For LIAS (or dial-up connections to LIAS) after approximately 6 minutes of inactivity, the connection is dropped. After 5 minutes of inactivity a message and a beep is sent; then after 1 more minute of activity the connection to LIAS will be dropped. b) For OAS, 15 minutes of inactivity causes re-authentication via password; after one hour of inactivity, the connection is then dropped. (3) For both CACSLIP (DOS clients) and CACTWIN (Windows clients) (rarely for MacTCP), some screen savers (some TSR's in general) do interfere with communications. Typical symptoms in this case are "random" line drops (when screen saver kicks in/out), and file transfer via FTP interrupted and aborted. We do not recommend running screen savers or other timer-related DOS Terminate and Stay Ready programs when using modems--period. (4) For Windows Access clients, a Windows GPF (General Protection Fault) may cause the connection to be dropped. Please see the file: pub/dos/windows/gpfguide.txt on FTP.CAC.PSU.EDU for more about Windows General Protection Faults. (5) There are lots of external (environmental) causes for faulty modem communications, especially (but not only) for high-speed (14.4/28.8) connections. Most of these are related to the phone line itself. Sometimes (but rarely) this is a Bell Atlantic problem. More often the problem is related to the phone line between the phone jack and modem, or serial connection between modem and microcomputer serial port. Our recommendations, based on years of experience and experiments involving actual cases, follow: a) Do not route the phone line within three inches of any electrical cord or extension cord, or PC CPU cord, or Printer cord, or Monitor cord, or any electrical appliance or power supply. This often means taping or stapling the phone line away from such places between jack and modem. Symptoms are random dropping of the line, problems with TCP/IP clients, logging in, etc. Inductance from electrical lines wreaks havoc with phone lines. b) Do not route a phone line being used by a modem through answering machines. Some of the "smarter" (and cheaper) ones have been known to intercept/inject data, which of course is undesirable. c) Do not route a phone line underneath a carpet since people probably will walk on it, thus crushing the very fine wires therein. The same is true for running phone lines where doors will close on them, etc. d) Do not use old phone lines from jack to modem. Use a new phone line of the correct length, without splicing (splicers also have been known to cause loose connections, and thus problems, in some cases). e) For external modems, if your serial adaptors or serial cable is old, adaptor pins bent, or cable cracked, replace them. Make sure your serial connections are TIGHT. Parts (a) and (c) above above also apply to serial cables. f) For internal modems, and for all microcomputers in general, dust buildup on internal components compromises built-in PC cooling systems. While any PC is running, fans circulate air around internal components. We recommend that after unplugging all related electrical connections, you remove the CPU cover and carefully blow dust off all computer components, including internal modem cards, at least once a year; compressed air cans (purchased where electronic components are sold) or reversible vacuum cleaners may be used this purpose. Dust free components PREVENT communications problems. g) Surge protectors for both computer power and phone connections are recommended. But we recommend that you unplug your computer and modem during electrical storms (which may do more than interfere with a TCP/IP dial up connection). 6) When dialing with a modem through a phone with the Bell Atlantic feature "Call Waiting", if "Tone Block" is not activated (i.e.,Call Waiting is not canceled for this call) then if someone calls after such a dial-up connection has been made, it is highly likely that the data connection will be dropped. (Please see page 43 of the 1995-1996 Bell Atlantic phone book for State College for information.) That in fact is most often the case if the connection is via CACSLIP or CACTWIN via CAC or OTC Serial Protocol servers. One activates tone block (downtown State College) by prefixing the four characters "*70," to the phone number to be computer dialed; for example: *70,xxx-xxxx. The CACTWIN and CACSLIP install/customization menus provide the option to select dial-up numbers with the tone block prefix. (7) Hours of availability for the Penn State Data Backbone are advertised as follows by OTC: "Normal operating hours for the Data Backbone are from 7:30 a.m. to 5:00 a.m.; 5:00 a.m. to 7:30 a.m. is the time designated for normal maintenance. Most often, the historical record shows that the maintenance period was given over to normal operations. However, normal maintenance may disrupt the data backbone so no guarantees about quality are made for the normal maintenance time." (8) Finally, the Backbone, a Nameserver, Router, or Mainframe (such as PSUVM, LIAS, or OAS) is down or was down (or hung, or overloaded) when the problem was being experienced. One of the CAC Help Desks can help confirm these instances. Call them AFTER you checked out possibilities (1) thru (6) above: (1) and (2) can be monitored by being alert and using a watch; (3) thru (6) should be attended to as regular maintenance as good computing practice. ------------------------------ On September 26-29, 1995, UCLA Extension will present the short course, "Optical Fiber Communications: Techniques and Applications", on the UCLA campus in Los Angeles. The instructors are Tran V. Muoi, PhD, President, Optical Communication Products, Del Hanson, PhD, Principal Engineer, Hewlett-Packard, and Richard E. Wagner, PhD, District Manager, Bellcore. This course offers a review of optical fiber communications fundamentals, then focuses on state-of-the-art technology and its applications in present and future communication networks. The course begins with the major building blocks of optical fiber communications systems (fiber and passive components, sources and transmitters, detectors and receivers). Actual design examples of fiber optic links for short-haul and long-haul applications are studied, and recent technological advances in addressing problems due to fiber loss and dispersion are presented. The impact of fiber optic technology on communications is highlighted in the latter half of the course. Recent developments in local and metropolitan area networks to support multimedia traffic (i.e., data, voice, and video) and their evolving architectures and standards are fully covered. The treatment on telecommunications systems includes various technological options for subscriber networks, exchange networks, and the global undersea networks. Network architectures evolving from the traditional telephone and CATV networks are contrasted. Technology trends and directions for realizing the so-called information superhighway are examined as well. Finally, optical networks using wavelength routing and multi-wavelength cross-connects are presented. The course fee is $1295, which includes extensive course materials. For additional information and a complete course description, please contact Marcus Hennessy at: (310) 825-1047 (310) 206-2815 fax mhenness@unex.ucla.edu ------------------------------ Out of curiosity, and an engineer's natural tendency to want to understand the order of magnitude costs of things, I'd like to have even the roughest estimate of what it costs to send, say, a megabyte of data from one point to another over the Internet? I appreciate this is a very poorly defined quantity and that these costs are spread (and hidden) all over the place. But, let's say we peel out all the costs (hardware, software and peopleware) associated with what people do with Internet data after they get it, or the costs of generating it before they send it, and just consider some reasonable estimate of the transmission costs (phone lines) plus some reasonable estimate of the real costs associated with the activities of individual Internet nodes in receiving, processing and passing on data that flows through them. How much, averaged in some way over all the worldwide links, to send a megabyte (or a gigabyte, if a megabyte is too small) from here to there? ------------------------------ Does anyone know of on-line telephone directories? Currently I found the following: - France (minitel) >> http://www.epita.fr:5000/11/ - Italy (Electronic Yellow Pages) >> http://www.saritel.interbusiness.it/pge/LoginPgeEn.html - Switserland (Telecom) >> http://etv.eunet.ch/cgi-bin/etvq I need to look up adresses and telephonenumber for my genealogical research. Please mail me if you know any other online telephone directories. Bob Coret, The Netherlands b.coret@cs.utwente http://www.cs.utwente.nl/~coret/ [TELECOM Digest Editor's Note: Don't forget the service available on Compuserve. Although not a complete listing of all USA telephone numbers, it is rather large and quite useful. PAT] ------------------------------ I am looking for people to evaluate a few text to speech systems and grade the quality based on fidelity and proper conversion to spoken English (American). This will be blind test where you will receive wave(.wav) file output from the various systems and the text that they all read and a questionaire to fill out and return. Please let me know if you can help me out. I am not a developer of any of these, just wanting to get several peoples opinions on the systems. ·_ Thanks, David Rivkin Rivkin Science and Technology, Inc. RivkinDA@PE-Nelson.com ------------------------------ Pat writes in Volume 15 Issue 349: > ... I was very privileged to be a nearby neighbor of Laura Fermi, the > widow of Enrico Fermi. She often took her dinner in the Anchorage, > which was the name of the hotel dining room as did I, and she told a > story once ... Her words from this point forward ... Except that the story has appeared in this newsgroup/digest twice before -- in January 1990 in Volume 10 Issue 12, and again two and a half years later in Volume 12 Issue 667. It turns out that the previous posting was transcribed by Pat from tape, but this time he was reconstructing the story from memory. It was at my suggestion that Pat reran the article in 1992, but after making the suggestion then, it occurred to me to have a look at the applicable section of Richard Rhodes's superb book "The Making of the Atomic Bomb" (Simon & Schuster, 1986, ISBN 0-671-44133-7). The book turns out to imply, on pretty good evidence, that there is something quite wrong with Mrs. Fermi's story. Following is the "rebuttal" which I wrote in 1992. Text quoted with "|" signs is from the accurate version of the story, as posted then. Notes that are [[double-bracketed, like this]] are being added this time, in 1995. ---+--- Let me summarize the timetable: | "The test was set for 4:30 AM the next morning, so we returned to the | hotel and went to bed early. We got up at 3 the next morning and drove | out to the location ... The chronology that she gives after that is: 4:45... they return to town to telephone, but can't get the operator. 5:00 or just after... Fermi finds and wakes up the operator. They are back at their observation point 5 minutes before the explosion. | .... later, we got together with the others who had | been assigned there and found out that it wasn't the rain that delayed | things; it was that woman asleep; you see, the main people responsible | were linked by phones through Alamogordo; they had to coordinate what | they were doing and sychronize their work. All of them got the same | thing on the phone we got: no answer from the operator for 45 minutes! So this would imply that the operator's nap started at about 4:15, if not earlier. Okay, now to Rhodes. On page 664 of my copy: # [Robert] Oppenheimer, [Gen. Leslie] Groves, [Kenneth] Bainbridge, # [Gen. Thomas] Farrell, [Richard] Tolman and an Army meteorologist met # with [the meteorologist for the test, Jack] Hubbard at McDonald Ranch # at four that afternoon [the day before the test] to consider the # weather. ... They decided to wait and see. They had scheduled # a last weather conference for the next morning at 0200 hours; # they would make up their minds then. The shot was set for 0400 # and they let that time stand. As a source for at least part of this paragraph, Rhodes cites "The Day the Sun Rose Twice" by Ferenc Morton Szasz (Univ. of N.M. Press, 1984). Now on page 666: # Thunderstorms began lashing the Jornada [del Muerto] at about 0200 # hours ... Winds gusted to thirty miles an hour. Hubbard hung # on at Zero for last-minute readings -- only misting drizzle had yet # reached the tower area -- and arrived eight minutes late for the # 0200 weather conference at Base Camp, to find Oppenheimer waiting # for him outside the weather center there. Hubbard told him they # would have to scrub 0400 but should be able to shoot between # 0500 and 0600. Oppenheimer looked relieved. # # Inside they found an agitated Groves waiting with his advisors. # "What the hell is wrong with the weather?" the general greeted # his forecaster. ... Groves demanded to know when the storm would # pass. Hubbard explained its dynamics: a tropical air mass, night # rain. Afternoon thunderstorms took their energy from the heating of # the earth and collapsed at sunset; this one, contrariwise, would # collapse at dawn. Groves growled that he wanted a specific time, # not an explanation. I'm giving you both, Hubbard rejoined. ... # # Oppenheimer applied himself to soothe his bulky comrade. Hubbard # was the best man around, he insisted, and they ought to trust his # forecast. The others at the meeting--Tolman and two army meteor- # ologists, one more than before--agreed. Groves relented. "You'd # better be right on this", he threatened Hubbard, "or I will hang # you." He ordered the meteorologist to sign his forecast and set # the shot for 0530. Then he went off to roust the governor of New # Mexico out of bed to the telephone to warn him he might have to # declare martial law. For all of this material, Rhodes again cites Szasz, but he notes that Szasz in turn cites Hubbard's *contemporary* personal journal. This is pretty solid evidence, unless Hubbard had some reason to falsify it. The signed forecast would be even better evidence: has anyone seen it or seen it reproduced somewhere? According to Rhodes, Hubbard gave it to Bainbridge at "about 0508", following which the master switches were unlocked and the bomb fired with a 20-minute delay. There is further evidence that the telephones were not all down during the period that Mrs. Fermi mentions. From page 667 of Rhodes: # The meteorologist prepared his final forecast at S-10000 [the command # center, 10000 yards south of Zero]. He called Bainbridge at 0440. # "Hubbard gave me a complete weather report", the Trinity director # recalls, "and a prediction that at 5:30 am the weather would be # possible but not ideal. ... I called Oppenheimer and General # Farrell to get their agreement that 5:30 would be T = 0." Hubbard, # Bainbridge, Oppenheimer and Farrell each had veto power over the shot. # They all agreed. Rhodes cites a different source for this: "All in our Time" by Jane Wilson (Bulletin of the Atomic Scientists, 1975). There is a further problem with Mrs. Fermi's story, which is this: the Trinity test site is 60 miles from Alamogordo! From her account it seems to be at most a 25-minute drive from the telephone exchange to the observing point, which she says is 15 miles from the site. (Unfortunately, while Rhodes mentions something about what Fermi did during the test, he doesn't mention where he did it.) [[ In the version posted this year, she doesn't say how far the observing point is from the Trinity test site, but does say it's 5 miles from Alamogordo, and refers to people being stationed *50* miles out. I guess Pat remembered *part* of this exchange of postings from 1992, and unconsciously adjusted the distances this time to fit the times. Before I found out that the recent posting was unreliable for fine detail, it occurred to me that Mrs. Fermi might still have had an Italian accent in 1965, really said "50 miles", and Pat misheard it when transcribing the tape in 1990. Unfortunately for this explanation, the complete sentence is: | It was set up that the scientists were deployed over about a | two hundred square mile area; we were about fifteen miles from | the target. A circular area of 200 square miles would have a radius of just 8 miles. Of course, the observing locations need not have formed a complete circle. In fact the main observing points were 10 miles out. I don't know if Fermi was at one of those points, though. ]] I am left with three possible interpretations. One is that Mrs. Fermi's story simply never happened. A second is that it happened exactly as she said, except that after 20 years she got some of the times wrong, while Hubbard participated in a cover-up, and Wilson's source was also misleading. And the third, which I think most likely, is that Fermi's drive into town did happen, but the operator's nap did not really affect the timing of the test. In this interpretation, not all the telephones for everyone went through that operator; perhaps it was only the lines between the test site and the hotels where the scientists were staying, say. (Also, maybe the operator was not in Alamogordo but in a smaller town closer to the site, such as Tularosa or Carrizozo.) Maybe what someone really said was that they had been afraid that the test would have to be cancelled because certain people couldn't be telephoned, and then it was all right. I dunno. I'd like to believe the original story. But the evidence... Mark Brader, msb@sq.com, SoftQuad Inc., Toronto "But even though they probably certainly know that you probably wouldn't, they don't certainly know that although you probably wouldn't there's no probability that you certainly would." -- Sir Humphrey Appleby ("Yes, Prime Minister") on nuclear deterrence My text in this article is in the public domain. ------------------------------ End of TELECOM Digest V15 #358 ******************************