RE: Clock Tolerance and WAN PHY
Devendra,
At 100 ppm, the difference in transfer time for a maximum length packet
between the maximum data rate and the minimum data rate is less than 3 bit
times. However, we can only delete and insert idles to compensate for that
data rate difference in increments of 4 octets which is the larger factor in
the sizing of elasticity buffers. Cutting the data rate tolerance to 50 ppm
reduces that to 1.5 bit times for a maximum packet which probably doesn't
save at all on elasticity buffer size.
Also, if the implementation is 10GBASE-X or XGXS, the elasticity buffering
also has to be large enough to compensate for lane skew of 40 to 80 UI. If
the implementation is 10GBASE-W, the elasticity buffering has to cover the
fact that the SONET data rate is an average rate with periods of ~600 bytes
when SONET is sending overhead.
Therefore, benefit to elasticity buffers of reducing the clock tolerance
will be negligible.
I also agree with the statements of Rich and others: You don't get a 50 ppm
data rate tolerance by buying a 50 ppm oscillator. Anyone doing a cost
comparison would need to do it for oscillators that will meet the data rate
spec over time, temperature, etc and not just under nominal conditions.
Pat
-----Original Message-----
From: Devendra Tripathi [mailto:tripathi@xxxxxxxxxxxx]
Sent: Saturday, January 27, 2001 7:24 PM
To: Jonathan Thatcher; stds-802-3-hssg@xxxxxxxx
Subject: RE: Clock Tolerance and WAN PHY
Jonathan,
I started the thread on a very simple note that it is time we reduce the
clock tolerance
to 50 ppm as it greatly helps in design of elasticity buffers at various
clock change
points. The cost of 50 ppm and 100 ppm ocsillators are almost same (I wish I
had numbers,
may be some one can provide that). This is similar request to moving voltage
level to
lower values to facilitiate higher density and faster designs.
If some one could compare cost of even lower ppms and we find it OK, it may
be wise
to change the requirement even to that. At least we do not have to worry
about being
compatible to 10/100/1000 on this one.
Regards,
Devendra Tripathi
VidyaWeb, Inc
90 Great Oaks Blvd #206
San Jose, Ca 95119
Tel: (408)226-6800,
Direct: (408)363-2375
Fax: (408)226-6862
-----Original Message-----
From: owner-stds-802-3-hssg@xxxxxxxx
[mailto:owner-stds-802-3-hssg@xxxxxxxx]On Behalf Of Jonathan Thatcher
Sent: Saturday, January 27, 2001 5:43 PM
To: stds-802-3-hssg@xxxxxxxx
Subject: RE: Clock Tolerance and WAN PHY
I enter here with great trepidation. I would like to offer a couple of
thoughts, based on our current draft (I am intentionally calling this by
number) and what I remember reading on the reflector.
1. A 20 ppm clock or any other ppm less than or equal to 100 ppm would be
compliant with the standard and would interoperate with all compliant
hardware.
2. I do not remember seeing any data regarding the cost ratio offered
between a 20 ppm clock and a 100 ppm clock. ($$ not allowed in comparison).
3. I do not remember seeing any data regarding the volume ratio of WAN to
LAN PHYs expected in the market place.
4. I do not remember seeing any data regarding the cost ratio of an ELTE
that has to support input of 100 ppm clock rates as compared to one that has
to support 20 ppm (or other).
5. Based on 2, 3, 4, I cannot therefore make even the simplest calculation
regarding a global optimization.
6. Based on 1, and 5, I don't see anything broken and I see no supporting
evidence that a change is beneficial (or, would provide incentive for 75% of
the voters to change this specification).
Also,
A. I don't see any reason why a LAN PHY can't source data at the OC-192 rate
and still be considered compliant to the standard and fully interoperable
with other LAN PHYs.
B. From an implementation standpoint, it is quite reasonable to think of
building an ELTE with the defined WIS and use a LAN PHY as the connection
between the Ethernet equipment and the ELTE running the mode specified above
in A.
C. The equipment ELTE built in B could easily translate between the two
clock domains (100 ppm and anything less than 100 ppm).
D. All that I describe above, I believe, would be compliant to the proposed
IEEE 802.3ae draft standard.
Therefore, what is the problem? It seems to me that any of you can implement
whatever you want and still be okay. I don't think that I am hearing issue
with our draft. I think that I am hearing implementation questions/issues.
What am I missing?
jonathan