Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: Proposal for accomodating 10.0000 and 9.58464 line rates





Buzz,

As long as standard concatenated payloads are used, there is no difference
in the cumulative payload rate between
an STS-192c, four STS-48c's muxed into an STS-192, sixteen STS-12c's muxed
into an STS-192, etc. The formula
for calculating the payload rate of an STS-Nc is:

			9x8x[(87xN) - (N/3)]/125E-06

For N=48, the payload rate is 2.396160 Gb/s, multiplied by four gives
9.584640 Gb/s. Perhaps you were thinking of
a non-standard approach?

...Dave

David W. Martin
Nortel Networks
+1 613 765-2901   
+1 613 763-2388 (fax)
dwmartin@xxxxxxxxxxxxxxxxxx <mailto:dwmartin@xxxxxxxxxxxxxxxxxx> 

========================

	-----Original Message-----
	From:	Rigsbee, Everett O [SMTP:Everett.Rigsbee@xxxxxxxxxxxxxx]
	Sent:	Wednesday, August 04, 1999 2:17 AM
	To:	dan_dove@xxxxxx; stds-802-3-hssg@xxxxxxxx;
NetWorthTK@xxxxxxx
	Subject:	RE: Proposal for accomodating 10.0000 and 9.58464
line rates


	Dan,  Has anyone considered that you can configure an OC-192 as 4
STS-48c's instead of 64 STS-3c's and thereby boost the payload rate to
9.6192 Gb/s by reducing the redundant overhead bytes.  This would also
simplify the multiplexing interface to some multiple of 4 bytes (factors of
3 are always messy).  
	Thanx,  Buzz
	Dr. Everett O. (Buzz) Rigsbee
	Boeing SSG
	PO Box 3707, M/S: 7M-FM
	Seattle, WA  98124-2207
	Ph:  (425) 865-2443
	Fx:  (425) 865-6721
	Email:  everett.o.rigsbee@xxxxxxxxxx
	----------
	From:  NetWorthTK@xxxxxxx [SMTP:NetWorthTK@xxxxxxx]
	Sent:  Tuesday, August 03, 1999 9:14 PM
	To:  dan_dove@xxxxxx; stds-802-3-hssg@xxxxxxxx
	Subject:  Re: Proposal for accomodating 10.0000 and 9.58464 line
rates

	Dan:
	Thanks very much for your patience in replaying my questions.  I
agree with your comments.  However, there are questions to which you may
wish to respond: 
		>  We will need buffers in the PHY to accomodate the
difference in MAC and link speeds. I assume this will necessary anyway to
allow for some latency in the framing process.
	I agree we need buffers.   Using the numbers we are discussing,
10.000 Gbps +/- 100ppm and 9. 58464 Gbps +/- 100 ppm at the maximum frame
size of 1500 bytes, the worst case timing skew due to the data rate
difference is 6.53ns.  In other words, if the MAC/PLS and PHY interface is a
byte-wide, the buffer size we need is 66 bits deep (byte) FIFO.  I believe
Steve has mentioned before a short buffer, 64 bit deep.
	The buffer size is small; therefore, buffer is not an issue at all.
On the other hands, if we make all IPG 64 bytes (or 66 bytes the worst case)
in conjunction with 66 bit deep byte-buffer, theoretically, we are in good
shape without any additional flow control.  Although the small packet, 64
byte, will slow down to  of the maximum throughput.  Is this suggestion
causing other deficiencies? 
		>  I am in support of a MAC/PLS interface that is un-coded
data (as Shimon suggested) and will therefore allow PHYs that use different
coding for their different environments. It is entirely reasonable to
believe that the coding requirements for a 40Km link will be different than
those of a 20m copper link.
	I agree.  I do not have any qualm with this. 
						Regards, 
						Edward  S. Chang
	NetWorth Technologies, Inc.
	NetworthTK@xxxxxxx <mailto:NetworthTK@xxxxxxx>