[EFM] PON timing parameters - quick locking
Dear Jonathan,
Just one more thought: I wouldn't say that the biggest motivation for loop
timing is efficiency. It certainly improves the potential for efficiency
(which would then have to be realised in practice). I think the biggest
reason for doing loop timing is that it simplifies the equipment, the
testing of the equipment, and the standard.
Basically, what it means is that the ONT does not need its own clock. This
basically eliminates a function, and some circuitry. So there is some cost
savings there. And, I simply can't see a downside to just tying the ONT's
Tx clock to that derived from the Rx in our setting. Can anybody?
Regards,
Frank Effenberger
To: <stds-802-3-efm@ieee.org>
Subject: RE: [EFM] PON timing parameters - quick locking
From: "Jonathan Thatcher" <Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 19 Dec 2002 11:26:19 -0800
Sender: owner-stds-802-3-efm@majordomo.ieee.org
Thread-Index: AcKnB8ifJQxeypApSq+gSK/yWQRTwQAisvkA
Thread-Topic: [EFM] PON timing parameters - quick locking
----------------------------------------------------------------------------
----
Frank,
Thank you. I think we are on the same page.
If loop timing efficiency is critical, I am certainly supportive of
modifying the design assumptions and presumptions in order to achieve the
objectives. We'd better decide this in January if we want to get to Working
Group ballot anytime soon.
jonathan
p.s. The "I don't understand how it can be done. But, if it is possible to
trade "rapid lock" against latency or delay, there could be significant
benefits." question stands. This question implies a clock recovery scheme. I
should have made it explicit. Perhaps the signal could be split, and slowed
down by running one path at absolute zero.... :-)
| -----Original Message-----
| From: FEffenberger@xxxxxxxxxxxxxxxxx
| [mailto:FEffenberger@xxxxxxxxxxxxxxxxx]
| Sent: Wednesday, December 18, 2002 6:29 PM
| To: Jonathan Thatcher; FEffenberger@xxxxxxxxxxxxxxxxx;
| stds-802-3-efm@ieee.org
| Subject: RE: [EFM] PON timing parameters - quick locking
|
|
| Dear Jonathan,
|
| Forgive my misinterpretation of your Email, but you did say:
| "I don't understand how it can be done."
|
| I see where you are going now. Well, I think a big change in
| the modus
| operandi is that all burst mode receivers I've seen don't try
| to regenerate
| the clock from the incoming signal. So, it doesn't make
| sense to define or
| measure jitter transfer, rejection, or tolerance. One does
| define a jitter
| generation in the upstream transmitter, but that largely
| folds into the eye
| diagram.
|
| In short, if you go my way, all the dispersion language you
| know is wrong.
| (But that shouldn't surprise you, because burst mode master-slave
| communication is intrinsically different from continuous mode
| peer-to-peer
| communication.)
|
| You are right that this issue should be dealt with, because
| it goes to the
| heart of the requirement for loop timing the ONU. I wonder:
| what is the
| status of that issue? It is important, and should be
| answered before we go
| any further with specifying PON PMA issues such as the ones
| you have in
| mind.
|
| Sincerely,
| Frank Effenberger.
|
|