cook@trane.UUCP (Eric Cook) (06/02/88)
Your tax dollars at work......
I found this in Sky & Telescope. If you are doing projects requiring
your computer syncing with UTC, this is for you. The phone number is
(303) 494-4774, they are to add a 900 number in the future.
----------------------------------------------------------------------------
DESCRIPTION OF THE
AUTOMATED COMPUTER TELEPHONE SERVICE (ACTS)
The following is transmitted (at 1200 baud) following completion of the
telephone connection.
? = HELP
National Bureau of Standards
Telephone Time Service
D L D
MJD YR MO DA H M S ST S UT1 msADV OTM
47222 88-03-02 21:39:15 83 0 +.3 045.0 UTC(NBS) *
47222 88-03-02 21:39:16 83 0 +.3 045.0 UTC(NBS) *
47222 88-03-02 21:39:17 83 0 +.3 045.0 UTC(NBS) *
47222 88-03-02 21:39:18 83 0 +.3 045.0 UTC(NBS) *
47222 88-03-02 21:39:19 83 0 +.3 037.6 UTC(NBS) #
47222 88-03-02 21:39:20 83 0 +.3 037.6 UTC(NBS) #
etc..etc...etc.......
UTC = Universal Time Coordinated, the official world time referred to the
zero meridian.
_________________________________________________________________________
DST = Daylight savings time characters, valid for the continental U.S., are
set as follows:
00 = We are on standard time (ST). 50 = We are on DST.
99 to 51 = Now on ST, go to DST when your local time is 2:00 am and the
count is 51. The count is decremented daily at 00 (UTC).
49 to 01 = Now on DST, go to ST when your local time is 2:00 am and the
count is 01. The count is decremented daily at 00 (UTC).
The two DST characters provide up to 48 days advance notice of a change in
time. The count remains at 00 or 50 at other times.
_________________________________________________________________________
LS = Leap second flag is set to "1" to indicate that a leap second is to be
added as 23:59:60 (UTC) on the last day of the current UTC month. The LS
flag will be reset to "0" starting with 23:59:60 (UTC). The flag will
remain on for the entire month before the second is added. Leap seconds
are added as needed at the end of any month. Usually June and/or December
are chosen.
The leap second flag will be set to a "2" to indicate that a leap second
is to be deleted at 23:59:58--00:00:00 on the last day of the current
month. (This latter provision is included per international recommendation
however it is not likely to be required in the near future.)
__________________________________________________________________________
DUT1 = Approximate difference between earth rotation time (UT1) and UTC, in
steps of 0.1 second. DUT1 = UT1 - UTC
___________________________________________________________________________
MJD = Modified Julian Date, often used to tag certain scientific data.
___________________________________________________________________________
The full time format is sent at 1200 baud, 8 bit, 1 stop, no parity.
The HH:MM:SS msADV time format at 300 baud is also 8 bit, 1 stop, no parity.
___________________________________________________________________________
Maximum on line time will be 55 seconds. If all lines are busy at any time,
the oldest call will be terminated if it has been on line more than 15
seconds, otherwise, the call that first reaches 15 seconds will be
terminated.
___________________________________________________________________________
Current time is valid at the "on-time" marker (OTM), either "*" or "#".
The nominal on-time marker (*) will be transmitted 45 ms early to account
for the 8 ms required to send 1 character at 1200 baud, plus an additional
7 ms for delay from NBS to the user, and approximately 30 ms "scrambler"
delay inherent in 1200 baud modems. If the caller echoes all characters,
NBS will measure the round trip delay and advance the on-time marker so
that the midpoint of the stop bit arrives at the user on time. The amount
of msADV will reflect the actual required advance in milliseconds and the
OTM will be a "#". The NBS system requires 4 consecutive delay
measurements which are consistent before switching from "*" to "#".
If the user has a 1200 baud modem with the same internal delay as that used
by NBS, then the "#" OTM should arrive at the user within +-2 ms of the
correct time. However, NBS has studied different brands of 1200 baud
modems and found internal delays from 24 ms to 40 ms and offsets of the
"#" OTM of +-10 ms. For many computer users, +-10 ms accuracy should be
more than adequate since many computer internal clocks can only be set with
granularity of 20 to 50 ms. In any case, the repeatability of the offset
for the "#" OTM should be within +-2 ms, if the dial-up path is reciprocal
and the user doesn't change the brand or model of modem used. This should
be true even if the dial-up path on one day is a land-line of less than
40 ms (one way) and on the next day is a satellite link of 260 to 300 ms.
In the rare event that the path is one way by satellite and the other way
by land line with a round trip measurement in the range of 90 to 260 ms,
the OTM will remain a "*" indicating 45 ms advance. For the user who wants
the best possible accuracy at the OTM, NBS offers an alternate 300 baud
service with only HH:MM:SS MSADV and OTM. To use the alternate service,
simply call at 300 baud. Because of the simple FSK modulation scheme used
at 300 baud, all modems tested had the same delay within about 1 ms.
___________________________________________________________________________
The full time format will be sent at 1200 baud, 8 bit, 1 stop, no parity. The
HH:MM:SS MSADV time format at 300 baud will also be 8b, 1s, np.
For user comments write:
NBS-ACTS
Time and Frequency Division
Mail Stop 524
325 Broadway
Boulder, CO 80303
Software for setting DOS compatable machines is available on a
360-kbyte diskette for $35.00 from:
NBS Office of Standard Reference Materials
B311-Chemistry Bldg, NBS, Gaithersburg, MD, 20899, (301) 975-6776
--------------------------------------------------------------------------awpaeth@watcgl.waterloo.edu (Alan Wm Paeth) (06/03/88)
In article <455@trane.UUCP> cook@trane.UUCP (Eric Cook) writes: > > Your tax dollars at work...... > I found this in Sky & Telescope. If you are doing projects requiring >your computer syncing with UTC, this is for you. The phone number is >(303) 494-4774, they are to add a 900 number in the future... >[discussion of time signals via 1200 modem follows]. As I recall the current telephone number arrangement is truly by "land-line" -- the NBS has arranged with Bell that the signals not be routed via satellite, as the speed of light path delay becomes a significant fraction of a second. These guys are always "on guard for purity", and seem to do a good job at that. /Alan Paeth Computer Graphics Laboratory University of Waterloo
glenn@otto.COM (Glenn Scott) (06/06/88)
In article <4691@watcgl.waterloo.edu>, awpaeth@watcgl.waterloo.edu (Alan Wm Paeth) writes: >As I recall the current telephone number arrangement is truly by > "land-line" -- the NBS has arranged with Bell that the signals not be > routed via satellite, as the speed of light path delay becomes a > significant fraction of a second. These guys are always "on guard for > purity", and seem to do a good job at that. > > /Alan Paeth > Computer Graphics Laboratory > University of Waterloo This doesn't make sense to me, so I'm not sure you're saying what I think you are. If I originate the call, my local telephone provider doesn't necessarily know that I'm calling the NBS Time Service, and it would route my call via the most viable way. That's not likely to be via "land-line" from Nevada to Colorado. In addition, the "speed of light delay" via satellite shouldn't be much different than the speed of light delay over a copper wire... Glenn -- Glenn Scott 702-564-8347 Las Vegas Sun 702-435-4651 Henderson, Nevada Las Vegas, Nevada glenn@otto.lvsun.com "Officials don't know what caused the blast, but they know it wasn't their fault."
woods@ncar.ucar.edu (Greg Woods) (06/07/88)
In article <585@otto.COM> glenn@otto.UUCP (Glenn Scott) writes: > In addition, the "speed of light delay" via satellite shouldn't be much >different than the speed of light delay over a copper wire... WRONG! Via satellite, the signal must travel 44,000 miles (22,000 each way to geosynchronous orbital height). Since light is about 186,000 miles a second, we're up to nearly a quarter second delay. Over a land line from Nevada to Colorado, we're talking a few hundred miles. This is a significant difference. --Greg
roy@phri.UUCP (Roy Smith) (06/07/88)
glenn@otto.UUCP (Glenn Scott) writes: > In addition, the "speed of light delay" via satellite shouldn't be much > different than the speed of light delay over a copper wire... If I call Colorado from New York and get a land line, I'm going over maybe 3-4000 miles of path (doesn't make much difference if it's copper wire, microwave, or fiber; in reality it's probably a combination of all three). For a 3000 mile path at 300,000 miles/second, that's a 10 msec delay. The kicker is that commsats are in geosynchronous orbit. If I remember correctly that means an altitude of 23,000 miles, making the path length twice that (uplink + downlink) or 46,000 miles. That's about 150 msec. -- Roy Smith, System Administrator Public Health Research Institute 455 First Avenue, New York, NY 10016 {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
wtm@neoucom.UUCP (Bill Mayhew) (06/07/88)
A geosynchonous orbit, in which the telecom satellites used by Ma Bell et. al. is 22,400 miles above the equator. For any place not on the equator directly below the satellite, the path is somewhat longer. That means that if a call is routed by satellite, just the time to get up to the bird and back down to the ground is about 300 mS. There is likely to be some delay in the ground based processing equipment too. It is my understanding that calls are often routed so that one half will be land line, while the other half is satellite to keep the turnaround delay from becomming excessive. Ocasionally when I call overseas, I think I get a call where both sides are going via satellite. It makes you tend to repeat yourself becuase the other person's reply is delayed enough that it feels like he/she is not understanding what you said. I've also had overseas calls that are half-duplex (probably for echo cancellation), and it can be very confusing because you can't say "uh-huh, yup, right, etc" while the other person is talking. The carrier tone of the answer modem is specially designed to supposedly ensure that the call is allowed to be full duplex, assuming that the modem will do its own echo cancelling. For land links, the trasmission delay plus the dealys introduced by the terminal equipment seems to me via qalitative observation to be well under 100 mS. I'd imagine that Rick Adams must have some interesting stories about satellite delay. Those calls to Singapore would require several satellite hops. Though I am not a guru, it seems feasible to me that at least some regions of the AT&T network would be smart enough to decide to give special routing to a call to a given number. --Bill
awpaeth@watcgl.waterloo.edu (Alan Wm Paeth) (06/07/88)
In article <585@otto.COM> glenn@otto.UUCP (Glenn Scott) writes: >In article <4691@watcgl.waterloo.edu>, awpaeth@watcgl.waterloo.edu (Alan Wm Paeth) writes: > >>As I recall the current telephone number arrangement is truly by >> "land-line" -- the NBS has arranged with Bell that the signals not be >> routed via satellite, as the speed of light path delay becomes a >> significant fraction of a second. > > If I originate the call, my local telephone provider doesn't necessarily >know that I'm calling the NBS Time Service, and it would route my call via >the most viable way. That's not likely to be via "land-line" from Nevada >to Colorado. In addition, the "speed of light delay" via satellite shouldn't > be much different than the speed of light delay over a copper wire... I believe the arrangement involves the use of (900) prefix numbers, but your arguments are compelling. I saw the reference in "Sky and Telescope" last year. The "speed of light delay" is indeed significant for a return bounce to a geosynchronous satellite at 40,000km. Talking long distance to Europe (from North America) can be very trying (many starts, stops and interruptions), because the delay is long enough to be interpreted as an intentional "pause", at which point both parties resume speaking, only to stop immediately when they hear the (delayed) voice of the other party. /Alan Paeth
glenn@otto.lvsun.com (Glenn Scott) (06/08/88)
In article <3335@phri.UUCP>, roy@phri.UUCP (Roy Smith) writes: >glenn@otto.UUCP (Glenn Scott) writes: > In addition, the "speed of light delay" via satellite shouldn't be much > different than the speed of light delay over a copper wire... > If I call Colorado from New York and get a land line, I'm going over >maybe 3-4000 miles of path (doesn't make much difference if it's copper >wire, microwave, or fiber; in reality it's probably a combination of all >three). Ah, well, then I don't think we're really talking about "land-lines" then. Ten years ago, during college, I worked for "The Phone Company" as a switchman. Way back then "land-line" meant metal. Specifically, no multiplexing (no microwave, no fiber, no satellite). But in any case, the receiver doesn't determine the routing. If an ordinary consumer makes a call it is routed via the most viable route. Glenn PS: There is a difference between copper wire, and microwave or fiber. Microwave and fiber are multiplexed and thus have some scheduling delays, albeit small.
jfh@rpp386.UUCP (John F. Haugh II) (06/08/88)
In article <3335@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >three). For a 3000 mile path at 300,000 miles/second, that's a 10 msec >delay. wow! faster than light telephone travel. is this something sprint is working on? ;-) just remember, 186,000 miles per second, it's not just a good idea, it's the law! - john.
davew@gvgpsa.GVG.TEK.COM (David C. White) (06/08/88)
In article <3335@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > If I call Colorado from New York and get a land line, I'm going over >maybe 3-4000 miles of path (doesn't make much difference if it's copper >wire, microwave, or fiber; in reality it's probably a combination of all >three). For a 3000 mile path at 300,000 miles/second, that's a 10 msec >delay. > The kicker is that commsats are in geosynchronous orbit. If I >remember correctly that means an altitude of 23,000 miles, making the path >length twice that (uplink + downlink) or 46,000 miles. That's about 150 >msec. Did I miss something, or were some basic laws of nature changed when I wasn't looking? I think we have the classic apples and oranges comparison case here. What I think Roy meant was that the speed was 300,000 km/sec rather than miles/second. The rest of the conversion from miles to kilometers is left as an exercise for the student. -- Dave White Grass Valley Group, Inc. PHONE: +1 916.478.3052 P.O. Box 1114 Grass Valley, CA 95945 davew@gvgpsa.gvg.tek.com
die@frog.UUCP (Dave Emery) (06/08/88)
In article <587@otto.COM> glenn@otto.UUCP (Glenn Scott) writes: > > Nevertheless, my point was that the receiver does not direct the routing. >If I make a call, it is routed via the most viable route. Satellite delays >notwithstanding. > >Glenn It is my understanding that the modern 4ESS/CCIS/SS7 AT&T long distance switches (and probably other carriers as well) can and do under at least some conditions selectively route calls to particular destinations over particular types of media (such as fiber rather than satellite). This capability was incorperated in the telephone network some years back in an effort to reduce the number of sensitive conversations that are routed via certain microwave and satellite links that the Russians and other foreign intelligence services routinely monitor. As I understand it the network is capable of refusing to route calls to particular specific destinations via less secure paths if all the more secure ones are busy. Further the detailed billing tapes available from your telephone carrier contain information about how a specific call was routed and perhaps whether it was specially routed or not. I do not know whether the software involved can specially process certain blocks of numbers within an office code differently than the rest of the office code but I suppose this is quite possible. Whether the knowlage of what numbers to process specially is contained in a database at the originating toll center or whether the destination serving toll office can pass back a CCIS message identifying a number as requiring special handling I do not know. It is therefore quite reasonable to suppose that when the NBS time number is called it is specially recognized and the call routed via terrestrial rather than celestial paths at least over AT&T. -- ---- David I. Emery Charles River Data Systems 983 Concord St. Framingham, MA 01701 Tel: (617) 626-1102 uucp: ...!decvax!frog!die
ldg@druin.ATT.COM (Doug Gibbons) (06/08/88)
in article <3335@phri.UUCP>, roy@phri.UUCP (Roy Smith) says: > Xref: druin sci.electronics:1945 sci.astro:1124 comp.dcom.modems:1203 comp.misc:1702 rec.ham-radio:3315 > > glenn@otto.UUCP (Glenn Scott) writes: >> In addition, the "speed of light delay" via satellite shouldn't be much >> different than the speed of light delay over a copper wire... > wire, microwave, or fiber; in reality it's probably a combination of all > three). For a 3000 mile path at 300,000 miles/second, that's a 10 msec > delay. 300,000 mi/sec??? When did this happen? Nobody ever tells me anything. Doug Gibbons AT&T ihnp4!druin!ldg
leonard@bucket.UUCP (Leonard Erickson) (06/09/88)
In article <585@otto.COM> glenn@otto.UUCP (Glenn Scott) writes: <In article <4691@watcgl.waterloo.edu>, awpaeth@watcgl.waterloo.edu (Alan Wm Paeth) writes: < <>As I recall the current telephone number arrangement is truly by <> "land-line" -- the NBS has arranged with Bell that the signals not be <> routed via satellite, as the speed of light path delay becomes a <> significant fraction of a second. These guys are always "on guard for <> purity", and seem to do a good job at that. <> <> /Alan Paeth <> Computer Graphics Laboratory <> University of Waterloo < < This doesn't make sense to me, so I'm not sure you're saying what I think <you are. < < If I originate the call, my local telephone provider doesn't necessarily <know that I'm calling the NBS Time Service, and it would route my call via <the most viable way. That's not likely to be via "land-line" from Nevada <to Colorado. At the point where it has been determined that the call is going outside your LATA they may have the computer set up too check for certain special numbers that receive special routing. This is already done for 800 and 900 numbers, so I'm sure they can do it for this one too! < In addition, the "speed of light delay" via satellite shouldn't be much <different than the speed of light delay over a copper wire... Huh?! The wire distance from here in Oregon to Colorado is, say 1500km. That's 5e-3 seconds. double that for the round trip. A satelite link, goes thru a comsat in geosynchronousd orbit at 37,000km. So we've got a total round trip length of 37,000*4= 148,000, call it 150,000 for ease of calculation. That gives uas a lag of .5 sec! So landline is .01, and satelite is .5. Thats close to two orders of magnitude difference! 50 times as much lag! -- Leonard Erickson ...!tektronix!reed!percival!bucket!leonard CIS: [70465,203] "I used to be a hacker. Now I'm a 'microcomputer specialist'. You know... I'd rather be a hacker."
mrapple@uop.edu (Nick Sayer) (06/09/88)
As I understand it, if you echo the characters you receive on the computerized version of the call, the NBS will time the echoing delay and adjust its sending rate to make sure that the <CR> at the end of the line gets to you right on time. The best way to avoid delays is to just turn on a shortwave receiver, and try to anticipate by a little bit. :-) I bought one of those Heathkit "most accurate clocks" that decodes the NBS time code. Nice conversation piece, that. I find it a bit of a white elephant, but it IS accurate. ---------------------------------------------------------------------- Nick Sayer | Packet Radio: N6QQQ @ WA6RDH | CMS: SYSOP@STOKTON%STOCKTON uucp: ...!sdcsvax!ucbvax!ucdavis!uop!mrapple | Fido: 161/31 Disclaimer: You didn't REALLY believe that, did you? cat flames > /dev/null
thad@cup.portal.com (06/09/88)
The operative word here is `DISTANCE.' Delays over a known satellite link are quite noticeable (contrasted to a land-line). Consider: 25,000 miles "up" and 25,000 miles back "down" is approx. 1/3 second.
les@chinet.UUCP (Leslie Mikesell) (06/10/88)
In article <11983@ut-sally.UUCP> nather@ut-sally.UUCP (Ed Nather) writes: >We sometimes send data via the phone lines, and satellite delay kills us. Is there a file transfer protocol that works well over satellite? Zmodem is supposed to allow the amount of outstanding data to be specified, but the sources that have been posted do not include a dialer or login routine to establish a connection. Does anyone have something like this working? How about uucp 'x' protocol (or 'f' or 'g' with the # of packets increased) or a kermit w/sliding windows for unix? Is there any real-world data on transfer rates using any of these protocols?
glenn@otto.lvsun.com (Glenn Scott) (06/10/88)
In article: <11997@ut-sally.UUCP>, nather@ut-sally.UUCP (Ed Nather) writes: >In article <1120@X.UUCP>, die@frog.UUCP (Dave Emery) writes: >> It is therefore quite reasonable to suppose that when the NBS time >> number is called it is specially recognized and the call routed via >> terrestrial rather than celestial paths at least over AT&T. -- >Yes, but is it *so*. I just called ATT Long Distance Services (800-222-0400) to determine this, and although they have a hard line on not divulging details on another customers accounts, they told me that "No, we have no special arrangements to route calls placed to specific phone numbers." Of course they do have special arrangements for 800 and 900 numbers, but not 303-499-7111. They (Gene and Nancy) were quick to point out, however, that routing a call via satellite was the rare case and that I shouldn't be "too concerned over that". So, in that light it is reasonable to suppose that when the NBS time number is called it does not travel over celestial routes. I don't think this is necessarily the last word on this. The people I talked to weren't directly involved in routing and they wouldn't tell me who to contact to get more specific info. Perhaps someone else out in netland knows who to contact to solve this ? Glenn PS: Many thanks to all of those who blasted me and set me straight on satellites.
jnp@calmasd.GE.COM (John Pantone) (06/10/88)
I'm not usually prone to flames, but this just "pushed my button": > If I call Colorado from New York and get a land line, I'm going over > maybe 3-4000 miles of path 3-4000 miles! WHAT? From Connecticut to San Diego by CAR and the not arrow straight roads is 3200 miles! NYC to Boulder is 2000+ miles. NE Main to SW California is <4000 miles. Will we ever start teaching geography again in this country? -- These opinions are solely mine and in no way reflect those of my employer. John M. Pantone @ GE/Calma R&D, 9805 Scranton Rd., San Diego, CA 92121 ...{ucbvax|decvax}!sdcsvax!calmasd!jnp jnp@calmasd.GE.COM GEnie: J.PANTONE
jewett@hpl-opus.HP.COM (Bob Jewett) (06/10/88)
> 300,000 mi/sec??? The speed of light is defined to be exactly 18737028625 ----------- miles per second 100584 This is approximately 186282.39705122087011850791378 miles/second or 299,792,458 meters per second exactly. > When did this happen? > Nobody ever tells me anything. We decided to change it one morning while you were asleep.
wcb@sortac.UUCP (Bill Barksdale) (06/10/88)
In article <588@otto.lvsun.com> glenn@otto.lvsun.com (Glenn Scott) writes: >--- >PS: There is a difference between copper wire, and microwave or fiber. > Microwave and fiber are multiplexed and thus have some scheduling > delays, albeit small. There is a difference between copper wire, and microwave or fiber - but the difference is not that multiplexing doesn't apply to copper wire. A lot of long distance traffic that goes over copper wire is multiplexed; the copper wire(s) being in a coaxial cable (often run underground.) -- "Even if the wheels fall off, we can SLIDE in from here!" - Rick Mears, just before winning the '88 Indy 500 Bill Barksdale AT&T Network Systems Atlanta, GA
james@bigtex.uucp (James Van Artsdalen) (06/11/88)
IN article <5785@chinet.UUCP>, les@chinet.UUCP (Leslie Mikesell) wrote: > Is there a file transfer protocol that works well over satellite? Zmodem > is supposed to allow the amount of outstanding data to be specified, but > the sources that have been posted do not include a dialer or login routine > to establish a connection. The posted sources are for the transfer protocol, nothing more. It's expected that you'll use "cu" or equivalent to make the underlying connection. In DOS you could use Pro-YAM or any of a number of modem programs that support external protocol modules (Qmodem and Procomm?). When you're writing a protocol driver, adding the connection code just yields a mess of a program (witness the various Kermit implementations). > Does anyone have something like this working? > How about uucp 'x' protocol (or 'f' or 'g' with the # of packets increased) > or a kermit w/sliding windows for unix? Is there any real-world data on > transfer rates using any of these protocols? I don't think C-Kermit supports sliding windows. uucp 'g' only permits a maximum of 7 packets or just under 500 bytes outstanding (about 2.2 seconds at 2400bps). Every now and again Chuck Forsberg posts real numbers for all this stuff. The best bet is Zmodem. The source code is readily available and in C. The code is small enough to work with too. It's pretty CPU efficient on both ends, and can allow for indefinite delays in propagation (it isn't necessary to have ACKs streaming back at the sender). Zmodem also handles varying line quality by dynamicly adjusting the packet size from a low of 32 bytes to at least 1K per packet. Finally, the most important thing to me is that on those occasions when you need to transfer GNU emacs by modem, you don't have to worry about the line being dropped two hours into your international phone call: you just call back and have zmodem continue the transfer where it left off. To the best of my knowledge, none of the other protocols you list can continue a transfer in the middle of a file like this. -- James R. Van Artsdalen ...!ut-sally!utastro!bigtex!james "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746
john@jclyde.UUCP (John B. Meaders Jr.) (06/12/88)
In article <268@druin.ATT.COM> ldg@druin.ATT.COM (Doug Gibbons) writes: >300,000 mi/sec??? >When did this happen? >Nobody ever tells me anything. Congress just approved the increase in the "speed limit" due to many complaints. You know Congress, they never tell anybody anything (they do talk a lot though). :-) :-) :-) :-) -- John B. Meaders, Jr. 1114 Camino La Costa #3083, Austin, TX 78752 ATT: Voice: +1 (512) 451-5038 Data: +1 (512) 371-0550 UUCP: ...!uunet!utastro!bigtex!jclyde!john or john@jclyde.UUCP
roy@phri.UUCP (Roy Smith) (06/12/88)
I wrote: > If I call Colorado from New York and get a land line, I'm going over > maybe 3-4000 miles of path which caused jnp@calmasd.GE.COM (John Pantone) to flame me: > 3-4000 miles! WHAT? [...] NYC to Boulder is 2000+ miles. [...] > Will we ever start teaching geography again in this country? Not only was I using round numbers, but it is indeed possible that the length of a terrestrial phone circuit from NYC to Boulder is 4000 miles. Calls get routed in strange ways sometimes if the direct trunks are overloaded. NYC->LA->Boulder might very well be 4000 miles as the electron flows. Jeeze! I posted what I thought was a reasonably informed answer to somebody's question. The result is that I've been roasted for using the wrong units by mistake, taken to task for saying that geosynchronous orbit was 23,000 miles instead of 22,400, and now I get accused of not knowing my geography. This net sure is a rough place; they don't let you get away with anything! -- Roy Smith, System Administrator Public Health Research Institute 455 First Avenue, New York, NY 10016 {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
eugene@pioneer.arpa (Eugene N. Miya) (06/13/88)
In article <2799@calmasd.GE.COM> jnp@calmasd.GE.COM (John Pantone) writes: > >I'm not usually prone to flames, but this just "pushed my button": >Will we ever start teaching geography again in this country? [stuff rm'ed] Okay geography is part of planetary science. Other flames to other groups. If you want buttons pushed, run a computer graphics society, hold a meeting on computer geography and cartography. Be ready to hear a lot of bogus info from the audience. Back to astronmy, please. Another gross generalization from --eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov resident cynic at the Rock of Ages Home for Retired Hackers: "Mailers?! HA!", "If my mail does not reach you, please accept my apology." {uunet,hplabs,ncar,decwrl,allegra,tektronix}!ames!aurora!eugene "Send mail, avoid follow-ups. If enough, I'll summarize."
halle@homxc.UUCP (J.HALLE) (06/13/88)
In article <2799@calmasd.GE.COM>, jnp@calmasd.GE.COM (John Pantone) writes: > > I'm not usually prone to flames, but this just "pushed my button": > > If I call Colorado from New York and get a land line, I'm going over > > maybe 3-4000 miles of path > 3-4000 miles! WHAT? From Connecticut to San Diego by CAR and the not > arrow straight roads is 3200 miles! NYC to Boulder is 2000+ miles. > NE Main to SW California is <4000 miles. > Will we ever start teaching geography again in this country? Read the posting again. He said 3-4000 miles of path, i.e. 3000+ miles of wire. That estimate is reasonable. A general rule of thumb is that the path length (to use his words) is about 1.5 times the airline distance. For long haul such as this the multiplier often drops to about 1.3, but rarely much lower. So I'd say that his estimate is reasonable. Will we ever start teaching thinking again in this country? Or manners?
hgp@lzaz.ATT.COM (H.PAGE) (06/13/88)
I've got a copy of the NBS Time distribution disk. If someone sends me shar and arc, I'll post it. Or, if you send me a 5 1/4 diskette, amd a stamped, addressed return envelope, I'll send you a copy... Howard G. Page AT&T IS 307 Middletown-Lincroft Road, Room 1B-115K Lincroft, NJ 07738-1526 -- Howard G. Page AT&T LZ 1B-115K (201)576-2731 ..!ihnp4!lzaz!hgp
ron@topaz.rutgers.edu (Ron Natalie) (06/14/88)
Nope, 3000-4000 miles is probably about right. The telephone company isn't a whole lot better aid out than the roads. You first have to make it from your house to the central office (probably 3-5 miles in most places). Then from there you have to go to the toll office where your long distance carrier has its point of presence. This may be halfway across the LATA in the wrong way. For example, our data circuits from north of Princeton run to Hamilton Square (which is precisely in the wrong direction) on their way north. Once you get into the long distance carrier system, you still get routed all over creation. A bit over a year ago a trunk cable was dug up in Oakland. This took out a large portion of the ARPANet. An interesting picture was the map of the ARPANet with the trunks shown as straight lines between the nodes they were connecting. Links that were interrupted as a result of the hole in Oakland were highlighted in blue. It was amazing how many points that aren't anywhere near California were affected. -Ron
karn@thumper.bellcore.com (Phil R. Karn) (06/14/88)
We could avoid all this arguing about whether calls to NBS are routed by satellite or terrestrial links if people would actually TRY it instead of engaging in armchair pontificating. It's quite easy; remember that the NBS output indicates how much it advances the on-second marker when you echo the marker back. I've used the NBS software a half dozen times now from northern NJ via AT&T, and I get pretty consistent propagation delays of 57-58 ms at 1200 baud. I haven't gotten a satellite path yet. Phil
donegan@stanton.TCC.COM (Steven P. Donegan) (06/15/88)
I came across a dos based time service program that used a Hayes modem to autodial the Naval Observatory in the Wash. DC area (I think) and retrieved the REAL time (plus/minus a second or so). If anyone knows of source for a similar program that I could port to my UNIX system I'd appreciate having it. Thanks. -- Steven P. Donegan Sr. Telecommunications Analyst Western Digital Corp. donegan@stanton.TCC.COM
is813cs@pyr.gatech.EDU (Cris Simpson) (06/15/88)
In article <3348@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: [ History of poor Roy's unfortunate error deleted] > Jeeze! I posted what I thought was a reasonably informed answer to >somebody's question. The result is that I've been roasted for using the >wrong units by mistake, taken to task for saying that geosynchronous orbit >was 23,000 miles instead of 22,400, and now I get accused of not knowing my >geography. This net sure is a rough place; they don't let you get away >with anything! >Roy Smith, System Administrator >{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net The worst part about the whole business is the incredible waste of net bandwidth by all those people who said: " Hey, look at this! Some guy screwed up on the speed of light! I know what the speed of light is, I'll show the whole world I'm smarter than this here System Administrator. He even rounds off numbers! Must be one of those sloppy engineers. I'm gonna post a correction so evryone can be enlightened! " It seems that this group had more traffic in flames to Roy than it has had in real discussions in a long time. What have we gotten? Lots of copies of people saying the same thing. The moral: READ BEFORE YOU POST!!!!! If you want to correct or answer, mark that message as unread, finish reading the group, then go back and post your response! Don't wind up posting the same stuff everyone else has posted. Thank you. Feel better now... STAMP OUT AND ABOLISH REDUNDANCY! -- ||...despair! Despair I can handle, it's the hope... J.Cleese,Clockwise || Cris Simpson is813cs@pyr.gatech.edu GA Tech Atlanta,GA ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!is813cs
bruce@cognos.uucp (Dwayne Bruce) (06/17/88)
-----
Well kids, after reading about the NBS telephone time service, and having
read about an expensive commerical system from Precision Standard Time, Inc.,
I just had to tell you about the system I cooked up.
We've been keeping our VAXen in sync with a simple system that uses the
AFSK time code produced by CHU. CHU is Canada's provider of brodcast time,
and it has a signal that can be heard regularly all over the western
hemisphere. During seconds 31..39 of each minute, they transmit a time
code in 103-type AFSK. I built a modem, plugged it into an HF receiver, and
wrote a piece of code to handle the output. The code is enclosed.
If you want to know more about the hardware, consult the article I wrote in
the April, 1988 edition of "The Canadian Amateur" (published by the
Canadian Amateur Radio Federation).
Anyway, here's the code. It runs under UNIX and VMS.
-------------------------
/* CHU Marcus Leech VE3MDL Aug 1987 */
/* This program reads and understands the timecode format
* produced by the CHU broadcast signal. This signal provides
* an atomic time standard to most places in North and South
* America on 3.330 7.335 and 14.670 MHZ, mode A3. During
* seconds 31 thru 39 the time is broadcast using Bell 103 AFSK.
* The time code looks like this:
* 6.d|d.d|h.h|m.m|s.s|6.d|d.d|h.h|m.m|s.s
* The time code is repeated twice for error detection. Each . represents
* one nibble boundary. The nibbles get transmitted reversed, so you
* have to flip them to make sense of the time code. Each nibble is a BCD
* digit.
* It takes one argument, the input device, and some optional flags:
* chu [-adst] <device>
* -
* a adjust attempt to adjust the system clock to CHU time
* d daemon run continuously as a daemon
* s show show semi-raw timecode
* t tune show chars that wouldn't get considered for time code
*
* When used as a system-time-adjuster, you need to set the system time
* to within 2mins of the correct time. The program will drag the
* clock into exact synchronism.
*/
#include <stdio.h>
#ifndef VMS
#include <sys/types.h>
#include <sgtty.h>
#include <time.h>
#else VMS
#include <types.h>
#include <time.h>
#endif VMS
/* Macros to fetch individual nibbles. */
#define hinib(x) (((x) >> 4) & 0x0F)
#define lonib(x) ((x) & 0x0F)
/* Macro to restore correct ordering within a byte. */
#define byte(h,l) (((l) << 4)|(h))
#define ADJINT 27
#define TWEAK 50 + 12 /* Fudge factor in centiseconds. */
/* CHU code is skewed by 0.5 seconds. */
#define iabs(x) ((x < 0) ? -x : x)
char sample1[5]; /* The first time code. */
char sample2[5]; /* The second (error checking) time code. */
main (argc, argv)
int argc;
char **argv;
{
char c, *p;
#ifndef VMS
struct sgttyb sgb; /* For fiddling with tty line params. */
#endif VMS
int line; /* Fd for the tty line.*/
int i;
int adjcnt; /* Number of samples before we adjust.*/
struct tm *localtime(), *ltp, *gmtime(); /* To break out the time. */
time_t now, time();
#ifdef VMS
long t0[2], t1[2], t2[2];
#endif VMS
int amm, ass, mmss, diff;
char *devstr;
int adjust;
int show;
int tune;
int daemon;
setbuf (stdout, NULL);
adjust = show = tune = 0;
devstr = "/dev/null";
for (i = 1; i < argc; i++)
{
if (argv[i][0] == '-')
{
p = &argv[i][1];
while (*p)
{
switch (*p)
{
case 'a':
adjust++;
break;
case 't':
tune++;
break;
case 's':
show++;
break;
case 'd':
daemon++;
break;
default:
fprintf (stdout, "unknown flag '%c'\n", *p);
exit (1);
}
*p++;
}
}
else
{
strcpy (devstr, argv[i]);
}
}
line = open (devstr, 0);
#ifndef VMS
/* Set up 8-bit datapath, at 30CPS. */
gtty (line, &sgb);
sgb.sg_ispeed = sgb.sg_ospeed = B300;
sgb.sg_flags |= RAW;
stty (line, &sgb);
#endif VMS
adjcnt = 0;
if (!daemon)
{
adjcnt = 19;
}
/* Read forever, waiting for the synchronizing BCD 6 digit to appear. */
for (;;)
{
read (line, &c, 1);
/* We have a syncronizing digit. Grab two samples and compare. */
if (lonib(c) == 6)
{
/* Get first sample. */
sample1[0] = byte(hinib(c),lonib(c));
for (i = 1; i < 5; i++)
{
read (line, &c, 1);
sample1[i] = byte(hinib(c),lonib(c));
}
/* Get second sample. */
for (i = 0; i < 5; i++)
{
read (line, &c, 1);
sample2[i] = byte(hinib(c),lonib(c));
}
/* If samples match, we have a valid time code. */
if (compare (sample1, sample2, 5) == 0)
{
/* Show the code (if -s). The high-order nibble in the
* first byte is the synch digit, so it gets masked out
* for printing.
*/
if (show)
{
fprintf (stdout, "TC: ");
for (i = 0; i < 5; i++)
{
fprintf (stdout, "%02x", sample1[i]);
}
fprintf (stdout, "\n");
}
if (adjcnt++ >= ADJINT)
{
adjcnt = 0;
/* Fetch UTC (GMT). */
time (&now);
ltp = gmtime (&now);
/* Convert time code minutes and seconds into
* binary.
*/
amm = (hinib(sample1[3]) * 10) + lonib(sample1[3]);
ass = (hinib(sample1[4]) * 10) + lonib(sample1[4]);
/* Convert minutes and seconds portion of system time. */
mmss = (ltp->tm_min * 60) + ltp->tm_sec;
/* Compute the difference. */
diff = ((amm * 60) + ass) - mmss;
/* Adjust the system time. */
now += (long)diff;
if (iabs(diff) > 120)
{
fprintf (stdout, "%02d-%02d-%02d %02d:%02d:%02d ",
ltp->tm_year, ltp->tm_mon + 1, ltp->tm_mday,
ltp->tm_hour, ltp->tm_min, ltp->tm_sec);
fprintf (stdout, "TERROR %d\n", diff);
if (!daemon)
{
break;
}
continue;
}
/* Only do it if there IS a (reasonable) difference. */
if ((diff != 0) && (adjust))
{
ltp = localtime (&now);
fprintf (stdout, "%02d-%02d-%02d %02d:%02d:%02d ",
ltp->tm_year, ltp->tm_mon + 1, ltp->tm_mday,
ltp->tm_hour, ltp->tm_min, ltp->tm_sec);
fprintf (stdout, "ADJUST %d\n", diff);
/* What we'd REALLY like here is a system call of
* the form: stime (*time, ticks)
* that would allow you to set the system tick
* counter to <ticks> in centiseconds. Too bad.
*-->stime (&now, TWEAK);<--
*/
#ifndef VMS
#ifndef EUNICE
stime (&now);
#endif EUNICE
#else VMS
t1[0] = 100000 * ((diff * 100) + TWEAK);
t1[1] = 0;
if (diff < 0)
{
t1[1] = -1;
}
sys$gettim (t0);
lib$addx (t0, t1, t2);
sys$setime (t2);
#endif VMS
}
ltp = localtime (&now);
fprintf (stdout, "%02d-%02d-%02d %02d:%02d:%02d TVALID\n",
ltp->tm_year, ltp->tm_mon + 1, ltp->tm_mday,
ltp->tm_hour, ltp->tm_min, ltp->tm_sec);
if (!daemon)
{
break;
}
}
}
}
else if (tune)
{
fprintf (stdout, "FT: %c (%02x)\n", c, (unsigned)c);
}
}
}
/* Compare two byte-arrays (s1, s2) of length cnt. */
compare (s1, s2, cnt)
char *s1;
char *s2;
int cnt;
{
int i;
for (i = 0; i < cnt; i++)
{
if (*s1++ != *s2++)
{
return (1);
}
}
return (0);
}
#ifdef VMS
struct tm *
gmtime (tod)
time_t *tod;
{
int hh;
int mm;
char s;
int secdiff, sgn;
time_t utc;
char *p, *getenv ();
p = getenv ("UTCDISP");
sscanf (p, "%c %02d:%02d", &s, &hh, &mm);
utc = *tod;
secdiff = (hh * 3600) + (mm * 60);
sgn = (s == '+') ? 1 : -1;
secdiff *= sgn;
utc += secdiff;
return (localtime (&utc));
}
#endif VMS
-- ml@gandalf utzoo!dciem!nrcaer!gandalf!ml