From owner-stds-802-3-hssg@ieee.org Wed Mar 1 18:26 GMT 2000 Received: from gatekeeper.pdd.3com.com (gatekeeper [161.71.169.3]) by isolan.pdd.3com.com (8.9.1b+Sun/8.9.3) with ESMTP id SAA17327; Wed, 1 Mar 2000 18:25:58 GMT Received: from ruebert.ieee.org ([199.172.136.3]) by gatekeeper.pdd.3com.com (Netscape Messaging Server 3.6) with ESMTP id AAA218C; Wed, 1 Mar 2000 18:24:08 +0000 Received: by ruebert.ieee.org (8.9.3/8.9.3) id MAA25771; Wed, 1 Mar 2000 12:48:12 -0500 (EST) Message-Id: <4.2.0.58.20000301104330.00a77b70@192.168.2.12> X-Sender: mwincn@192.168.2.12 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 01 Mar 2000 10:47:40 -0700 To: JR Rivers , jmw , JR Rivers , Vivek Telang , "stds-802-3-hssg@ieee.org" From: "Mike Wincn" Subject: RE: PAM-5, what are your BERs ? In-Reply-To: <4.1.20000301082433.00db7f00@smbmail3> References: <4.2.0.58.20000301055952.00a78700@mail.bayarea.net> <4.1.20000229180017.00d72bd0@smbmail3> <01BF82B7.070ECDE0@pc24.cicada-semi.com> Mime-Version: 1.0 Sender: owner-stds-802-3-hssg@ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: stds-802-3-hssg X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: stds-802-3-hssg-approval@majordomo.ieee.org X-Lines: 27 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 928 JR: thanks for better clarity, and i agree completely. i see little reason to compel anyone to choose one technology over another. standards bodies are more concerned with answering the question 'can it be done?'. -- J M Wincn, Staff Engineer Cielo Communications, Inc. 325 Interlocken Pkwy, Bldg A Broomfield, CO 80021-3497 Voice: 303-464-2264 Cell: 408-394-5283 Fax: 303-460-6348 At 08:34 AM 01-03-2000 -0800, JR Rivers wrote: >During the course of these discussions, I've seen people use "hard to do in >CMOS" as a reason to reject a proposal. > >I'm not trying to say that someone couldn't/shouldn't build a 10GbE >transceiver in CMOS; however, I am questioning the REQUIREMENT that it be >built in CMOS at standardization. I've been working on Ethernet products >for quite a long time, and every signalling technology has started off with >some non-CMOS implementation and eventually been reduced to CMOS. > >JR