
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
******************************

                                                                         
