From owner-freebsd-hackers Mon Mar 18 17:57:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA21428 for hackers-outgoing; Mon, 18 Mar 1996 17:57:16 -0800 (PST) Received: from wa3ymh.transsys.com (#6@wa3ymh.TransSys.COM [144.202.42.42]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id RAA21407 for ; Mon, 18 Mar 1996 17:57:11 -0800 (PST) Received: from wa3ymh.transsys.com (#6@localhost.TransSys.COM [127.0.0.1]) by wa3ymh.transsys.com (8.7.3/8.7.3) with ESMTP id UAA13663; Mon, 18 Mar 1996 20:56:55 -0500 (EST) Message-Id: <199603190156.UAA13663@wa3ymh.transsys.com> To: Terry Lambert cc: alk@Think.COM, hackers@freefall.freebsd.org From: "Louis A. Mamakos" Subject: Re: hackers-digest V1 #986 In-reply-to: Your message of "Mon, 18 Mar 1996 10:46:09 MST." <199603181746.KAA21733@phaeton.artisoft.com> Date: Mon, 18 Mar 1996 20:56:53 -0500 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Of course, this is orthoginal to terminating T1 leased lines from > > customer locations; some of them want their very own port from their > > premise to "mine", which isn't "shared". You can fix part of the > > problem space, but not all with one solution. Thus, the extreme > > interest in directly terminating M13 framed DS3 circuits carrying 28 > > T1 circuits. > > You have to have two clouds. You sell overcommit in the first, and > you don't overcommit the second. At a 50% load, it costs on the order > of twice as much for the committed rate. This assumes all common > costs (hardware, installation, lines, etc.) have been subtracted > out. The problem isn't a technical one; it's a marketing and product packaging one. It's like trying to argue over what color it should be :-) > 8-). I bet *against* ATM. Leaky-bucket is OK for voice, and can be > OK for video, assuming Cell animation with scene refresh. But it rots > out for data, which *must* get there *eventually*. I have yet to see > a working "source quench" without specialized hardware... besides, > with the number of audit records that would have be generated, they'd > be in the same boat as FR: no way to bill connect time. Not that that > is a bad thing. 8-). ATM may be OK in the local loop as a fine-grain muxing scheme, so long as you don't over commit the facilities. Of course, the problem is to have the LEC's actually offer ATM as a service... On the other hand, DS3 Frame Relay seems to work Just Fine.. > > Sorry for the diversion; this is pretty far afield from FreeBSD, 'cept > > that I run it on my machine and it works pretty good. > > No it isn't; it bears on what is a profitable use of time for drivers, > protocol stacks, and the ability to use FreeBSD for ISP services based > on communications throughput. Is UUNET still using those Sequent MP > boxes? Not for years; certainly not since I've been working there (about 2.5 years now). It's been a combination of Sparc and Pentium/BSDI platforms. There's a bunch of 'em these days. I think we've got on the order of 20 or 25 machines doing NNTP feeds at the moment. The Pentium machines are mostly CDDI attached, and we *sustain* about 30 Mb/s of just NNTP news feeds. High pressure USENET sewage pumping station.. louie