Return to BSD News archive
Xref: sserve comp.sys.powerpc:35431 comp.sys.intel:33038 comp.unix.bsd:16353 comp.unix.pc-clone.32bit:8261 comp.unix.sys5.r4:9416 comp.unix.misc:16348 comp.os.linux.development:23993 comp.os.linux.misc:36432 comp.os.386bsd.development:3293 comp.os.386bsd.misc:5593 comp.os.misc:3888 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!agate!howland.reston.ans.net!pipex!uknet!str-ccsun!zippy.dct.ac.uk!yama.mcc.ac.uk!cs.man.ac.uk!fellowsd 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) Message-ID: <3k1fh9$f19@m1.cs.man.ac.uk> From: fellowsd@cs.man.ac.uk (Donal K. Fellows) Date: 13 Mar 1995 12:58:17 GMT References: <D3s19v.4M7@pe1chl.ampr.org> <3jith7$81c@park.uvsc.edu> <3jjn6e$4oi@trance.helix.net> <3jla66$hvi@park.uvsc.edu> Organization: Dept of Computer Science, University of Manchester, U.K. NNTP-Posting-Host: r8h.cs.man.ac.uk NNTP-Posting-User: 8028 Lines: 118 [ This is in too many newsgroups, but I've no idea how far to ] [ cut down the distribution. Oh well... ] In article <3jla66$hvi@park.uvsc.edu>, Terry Lambert <terry@cs.weber.edu> wrote: >dlinford@trance.helix.net (D. Linford) wrote: [ Much deleted ] 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... :) >[ ... a packet instead of circuit switched system ... ] > >] >It will offer the advantage that they need less equipment to >] >provide the same data services. Assuming they want to provide >] >my data services. If they don't, then I'm perfectly willing to >] >give my $60/month to TCI instead of US West. >] >] And people are not supposed to talk to each other on the phone >] in order to give you cheap data service? If you were to segregate the >] data service, you would have a very hard time affording any sort of >] data connection to the home. > >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 :) >] >Maybe you haven't noticed, but the various aspects of the phone >] >company have been literally climbing on each other's heads to >] >become "the infrastructure providers" for "the information super >] >highway". >] > >] >Either they really want this, or they've been climbing for nothing. >] >] But none of the options are going to be set up using >] simplistic packet switched services. ATM is "packet switched", but is >] designed to encapsulate circuit switched data. If it weren't for the >] need for connection oriented services, you wouldn't have ATM at all in >] the form it is in. > >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. >It's not circuit switched data that imposes this on ATM, it's >video data that does it. The amount of data necessary for a >sustainable frame rate sufficient for non-canned video is so >high that it imposes granularity requirements for pool retention >times. If it weren't for *video*, we wouldn't have ATM in the >form that it's in. Voice data is so *much* smaller, and it has >much less critical time requirements because a reduced pool size >can still retain relatively *huge* amounts of data. > 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... >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... >] >] >Triple rates in most areas of the US is ~$20/month * 3 = $60/month. >] >] >] >] I'd hate to pay that. I currently pay about $35/month for my two >] >] telephone lines. I couldn't afford $120/month. >] > >] >Why would you need two lines? Why wouldn't you just make sure >] >the one line you had was fat enough for the traffic instead? >] >] Maybe to talk to someone? > >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? Donal. -- Donal K. Fellows. -- Dept. of Computer Science, | 6, Randall Place, Heaton, University of Manchester | Bradford, BD9 4AE U.K. Tel: ++44-161-275-6137 | U.K. Tel: ++44-1274-401017 fellowsd@cs.man.ac.uk (preferred) | donal@ugglan.demon.co.uk (if you must) -- See my <A HREF="http://www.cs.man.ac.uk/~fellowsd/">home page</A>