Return to BSD News archive
Xref: sserve comp.sys.powerpc:35436 comp.sys.intel:33043 comp.unix.bsd:16355 comp.unix.pc-clone.32bit:8264 comp.unix.sys5.r4:9417 comp.unix.misc:16352 comp.os.linux.development:23996 comp.os.linux.misc:36437 comp.os.386bsd.development:3294 comp.os.386bsd.misc:5594 comp.os.misc:3889
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!uwm.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!news.sprintlink.net!news.itsnet.com!news.byu.edu!bones.et.byu.edu!hamblin.math.byu.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@cs.weber.edu>
Newsgroups: comp.sys.powerpc,comp.sys.intel,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.unix.sys5.r4,comp.unix.misc,comp.os.linux.development,comp.os.linux.misc,comp.os.386bsd.development,comp.os.386bsd.misc,comp.os.misc
Subject: Re: flat rates for Internet/phone (Re: X on dial-in)
Date: 13 Mar 1995 18:01:22 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 132
Message-ID: <3k219i$c2u@park.uvsc.edu>
References: <D3s19v.4M7@pe1chl.ampr.org> <3jith7$81c@park.uvsc.edu> <3k1fh9$f19@m1.cs.man.ac.uk>
NNTP-Posting-Host: hecate.artisoft.com
fellowsd@cs.man.ac.uk (Donal K. Fellows) wrote:
] Someone (I forget who) effectively made the claim that phone switches
] are based on a bus architecture. Anyone who built a system like that
] ought to expect to be shot, as there are switch networks that can
] carry much higher loads for very little cost (and can deal with much
] more in the way of pathological cases... :)
It was me, referring to Nothern Telecom equipment.
Perhaps NT was just thinking ahead to packet switching? 8-).
] >No, people are supposed to digitize then compress their voice
] >before sending it over the packet switch network.
] >
] >Just like is done now for all major long distance carriers and
] >most ROBCs.
] >
] >I am not suggesting segregating voice and data services. I am
] >suggesting doing away with analog lines.
]
] How are you going to cope with the old fogeys who don't want to use
] `new-fangled' technology? IAMTA :)
By relying on the fact that old fogeys have a shorter life
expectancy than new fogeys? 8-).
I realize you're just being the devil's advocate, but the "fogeys"
in question are the accountants who want to continue to amortize
the 15 year old rural electro-mechanical switches another 5 years
to get the full 20 years out of them.
The issue is making it so it isn't cost effective for them to do
this.
Not that I'm in a rural area anyway.
] >Please. ATM is a 27% overhead pig of a standard that's a cruddy
] >48 bytes of data compromise between the competing 32 and 64 byte
] >standards that spawned it.
] >
]
] Not quite. ATM has a frame size of 64 bytes, but it needs 25% of that
] for itself, leaving 48 bytes of payload. When an ATM link is set up,
] each stage of the link from packet source to packet sink is configured
] so that routing is as quick as possible. This makes each packet travel
] faster (though the delay on equivalent wires will be the same, of
} course... :). In short, ATM is not PTM (packets) and it is not STM
] (circuits), but rather an unholy crossbreed of the two. It gets you
] better performance on circuits than PTM, but it is still packet based
] so that you can get away with less wire, etc.
The competing standards had 32 and 64 bytes of data, respectively.
The 48 bytes of encapsulated data *was* the compromise.
Unholy though it may be, your original point that it solves the
problem, of circuit switching is well taken. It does, though I'd
be much happier dropping the video off it for pipes lower than
a certain bandwidth to optimize data traffic.
After all, more people own computers than own video phones.
I'm one of the people who *would* opt for a larger pipe to get
the video, however, since the ability to attend meetings is the
only thing that ties me to a location regionally "near" where I
work. Unfortunately, too much of human communication is visual
for me to be able to effectively do my job *as well* as I do it
with the ability to attend meetings in person rather than via
conference call. I could still do it, but there would be a loss
of effectiveness in the process.
] Why the hell shouldn't we have video over the net in the first place?
] While _I_ don't actually need it (I think), that doesn't mean that it
] should be ruled out. Plus, who knows what applications may be devised
] in the future? I _know_ I don't...
You're right; we should. Let's replace all copper wire with fiber,
except that used in power systems.
While we are at it, we can get 300% of current capacity at the
central office for circuit switching and a 300% increase in inter
LATA pipeline size.
This way, we can have video the way you want, keep the antiquated
and obsolete circuit switching around for another 5 years or so
until the load once again becomes too heavy, and avoid violating
the accounting principles on the 15-20 switches curently undergoing
amortization.
] >Unless you're from Utah too, you've never seen anything as large
] >as a state-wide ATM network in operation.
]
] Have you ever seen a workstation that used an ATM network instead
] of a bus? Quite an eye-opener...
Are you talking about the Novell or the SGI video delivery efforts
(I've seen both of them), or some other effort?
Neither enamors me of ATM. I would much rather pursue things
like service anonymity for unidirectional video delivery.
There's a wonderful quote from WIRED magazine regarding "Video On
Demand":
"We have the technology. The only thing standing in
the way of Video On Demand is the lack of Demand".
If I've mangled this, then it's a quote from me. 8-).
] >Use digital instead of analog communications equipment. It tends
] >to be cheaper to build anyway.
]
]
] Please explain how an entirely digital phone is cheaper than an
] at least partially analogue one. Or were you just referring to the
] Telco's end?
You have to cut the load balancing capacitors off of both ends.
8-).
Most telephones have digital components. Like their dialers.
All telephones, even "all digital" ones, have analog speakers,
microphones, and ringers. 8-).
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.