RE: [EFM] Network timing? [Etherloop?]
i have no clue what etherloop has to do with network timing and network
clock transfer. All PSTN networks today carry clk information with them
including IP/SONET. CPEs in xDSL networks are generally required to recover
the timing from upstream network element or ATU-C. In Pure packet networks
you don't need to carry timing information as long as the traffic
engineering is done properly. in applications like voip it is covered via
proper singling conversion and time stamps etc.
generally one should be able to derive the network clk from whatever data
rate coming in at ATU-C. I believe in OLT it is better to lock your
transmitter to network clk, i.e. 8 khz
In term of channel capacity using shannon's laws (independent of duplexing)
there are some results that can be found in july and up coming meetings
-behrooz
-----Original Message-----
From: Fletcher E Kittredge [mailto:fkittred@xxxxxxx]
Sent: Wednesday, September 26, 2001 5:14 AM
To: Beanland Matthew
Cc: stds-802-3-efm@ieee.org
Subject: Re: [EFM] Network timing? [Etherloop?]
On 26 Sep 2001 16:04:00 +1000 "Beanland Matthew" wrote:
> I guess this is a question for the service providers out there. Imagining
an
> EFM ONU supporting bearer emulation (say, in order to provide E1/T1
interfaces
> for connection to a legacy PABX), is there any interest in having the OLT
> propagate network timing (usually 8kHz, traceable back to some reference)
to
> the ONUs by some method?
So do you envision this as a copper and fiber solution or a copper
only solution? If this is fiber only, please ignore all the
following...
If it is copper, using EFM to emulate the legacy PSTN via the legacy
PSTN seems unnecessarily complicated.
> Propagation of network timing is allowed for in the xDSL standards.
I am not sure if you are using this as an argument for or against
network timing.
Would propagating timing make more difficult some potential protocol
architectures for copper 10 mb/sec? For example, the Elastic Networks
Etherloop seems to work quite well in terms of distance, speed and
tolerance of bad line conditions. From what little I know of their
protocol, it doesn't use timing, but instead uses a master and slave
architecture. I also understand this architecture is why Etherloop
out performs competing protocols.
I know that there is some skepticism about the Etherloop protocol and
Elastic Network implementation because it seems to perform better than
people thought possible. I am not an expert in Etherloop; far from
it. I have never used Etherloop at all. However, at Copenhagen I was
going to present some results Frank Miller of Oregon Trails Internet
(OTI) put together of actual performance under a variety of
conditions. OTI has been using Etherloop for a while and I believe
has it installed quite widely. His slides show that Etherloop
actually performs better than specified out to at least 24k feet.
Due to a misunderstanding with Howard Frasier, Frank's slides got
deleted from the end of my presentation. I will work with Howard to
get them restored so you can see them.
Due to scheduling conflicts, Frank Miller could not attend the
Copenhagen sessions for mid-September. Perhaps he can make October
Los Angles sessions and give the results in person. It is still up in
the air whether or not I will be able to make Los Angles as the
session times overlap with PoPtech 2001.
regards,
fletcher
P.S. I would be very interested in hearing critiques of Etherloop, as we
are poised to make a big buy of Etherloop equipment. Please feel free
to contact me privately.