Re: [RE] Synchronous ethernet discussions
My 2c below - thank goodness we have started discussions...
Dirceu Cavendish
NEC Labs America
10080 North Wolfe Road Suite SW3-350
Cupertino, CA 95014
Tel: 408-863-6041 Fax: 408-863-6099
-----Original Message-----
From: owner-stds-802-3-re@listserv.ieee.org
[mailto:owner-stds-802-3-re@listserv.ieee.org] On Behalf Of Alexei
Beliaev
Sent: Wednesday, August 25, 2004 11:20 PM
To: STDS-802-3-RE@listserv.ieee.org
Subject: Re: [RE] Synchronous ethernet discussions
David,
Thank you for breaking the silence!
As for the choice between 1000 and 100/1000, I would risk to say that
the
problem is easily solvable for 10/100 if we use the normally unused (at
10/100) wires in CAT5 for sending synchronous data. This would require
an
additional PHY per every port but 10/100 PHY chips are inexpensive. This
approach certainly provides compatibility with regular non-synchronous
ports
since the synchronous 10/100 channel would simply discover itself
disconnected when a synchronous-capable 10/100 port is connected with a
regular port. As another example, two musical instruments with such
10/100
ports could potentially use for communication only synchronous channel
in
Gibson's MaGIC manner (www.gibsonmagic.com).
<DC>
I wonder how 802.3 would take the idea of two PHYs per connector...
</DC>
At the Gigabit speed, all cable wires are already used but the
throughput
looks sufficient for carrying both synchronous and non-synchronous data.
I
wonder if someone from Pioneer could post the old Sync-E presentation as
an
example.
<DC>
I would say that we should list all proprietary solutions in detail, for
each CE application for which we have group member representatives. If
we showcase these applications/solutions, plus how these applications
break down if connected to regular Ethernet, we would certainly send a
strong message towards the creation of a standard project...
</DC>
Synchronization. I would say that data frame jitter must not be very
much
larger than an acceptable jitter error in synchronized clocks because
otherwise it would result in requirements to have larger data buffers
and
ultimately increase latency at the application level. A few 125us cycles
feel safe.
<DC>
The issue boils down to how much latency an application can bear -
therefore, it is application dependent. Certainly, a ResEther solution
should support the most stringent application envisioned.
</DC>
<DC> Dirceu </DC>
Best regards,
Alexei Beliaev
7794 Robindell Way,
Cupertino, CA 95014
tel: 408-313-2665
email: synce@brainpot.com
----- Original Message -----
From: "David V James" <dvj@ALUM.MIT.EDU>
To: <STDS-802-3-RE@listserv.ieee.org>
Sent: Wednesday, August 25, 2004 9:34 PM
Subject: Re: [RE] Synchronous ethernet discussions
> Janoj,
>
> I'll do my best to answer your questions, but opinions vary.
> If others disagree, at least that will start the discussions...
>
> >>
> >> 1. What is the topology targeted for the solution:
> >> - Small network with one/two hops (bridges)?
>
> Small residential network, but mine already has 4 hops.
> So, I suspect the one/two hops is a bit small.
>
> >> - 10/100 only or can use 10/100/1000?
>
> I think the debate is between 100/1000 and 1000 only.
> Most folks seem to agree that the cost difference between
> 10Mb and 100Mb doesn't justify additional work to support it.
>
> However, 100Mb with Jumbo frames is an interesting question.
> If one can do 100Mb with Jumbo frames, then one can probably
> also do 10Mb, with or without Jumbo frames.
>
>
> >> 2. Is there any workload characterization?
> >> - Packet sizes/distribution
>
> No strong assumptions, although there has been a leaning to only
> support synchronous frames when they represent the accumulation
> of a common interval, where that period is one or a few 125us
> intervals.
>
> >> - burstiness
>
> The one or a few intervals is a constraint on synchronous transfers.
> There is no constraint on the async traffic burstiness.
>
>
> >> 3. What is the expected/acceptable performance criteria?
> >> - Throughput at the end-station
>
> I believe folks seemed to be comfortable with 50-75% of the
theoretical
> maximum, based on the media bandwidth.
>
> >> - Latency/Latency jitter
>
> Latency jitter would be a few intervals. Latency varies from one to
> a few (probably less than 4) intervals per bridge hop.
>
> >> - Packet drop sensitivity?
>
> Better to drop than to delay excessively. HOWEVER, better never to
drop
> due to congestion conditions.
>
>
> >> - clock sync need (with respect to what?)
>
> Yes, relative to the clock master, where one of the stations is
nominated
> to be the clock master.
>
>
> >> 4. Is any quantitative data available that shows above can
not
> >> be met on GiGE? (Except clock-sync). Pointer will
certainly
> >> help.
>
> It certainly can be met by Gigabit Ethernet, with the appropriate
> constraints
> on insertion behavior and jitter delays through bridges. Even the
clock-sync
> is possible, since its more critical that one measure delays than
eliminate
> them.
>
> >> 5. What is a synchronous frame? Pointer to any prior work
will
> >> really help.
>
> My terminology for a synchronous frame is one that is labeled for
> preferential
> treatment through bridges, presumably based on prenegotiated
bandwidths.
>
> See the 802.3 site for slides from the last meeting. I would like to
get
> 802.9 material for reference purposes, but I'm not sure where that is.
>
> Your may also want to read IEEE 1394, which (some of us feel) should
be
> useful for background and is also highly desirable to support in a
> reasonably transparent-to-traffic fashion.
>
> Respectfully,
> DVJ
>
> David V. James
> 3180 South Ct
> Palo Alto, CA 94306
> Home: +1.650.494.0926
> +1.650.856.9801
> Cell: +1.650.954.6906
> Fax: +1.360.242.5508
> Base: dvj@alum.mit.edu
>
> >> -----Original Message-----
> >> From: owner-stds-802-3-re@listserv.ieee.org
> >> [mailto:owner-stds-802-3-re@listserv.ieee.org]On Behalf Of Wadekar,
> >> Manoj K
> >> Sent: Wednesday, August 25, 2004 5:54 PM
> >> To: STDS-802-3-RE@listserv.ieee.org
> >> Subject: Re: [RE] Synchronous ethernet discussions
> >>
> >>
> >> Hi All,
> >>
> >> Being new to this effort for Residential Ethernet, my
apologies
> >> if my questions are too basic.
> >>
> >> Has there been any material that gives overview about
Digital
> >> Home requirements re:
> >>
> >> 1. What is the topology targeted for the solution:
> >> - Small network with one/two hops (bridges)?
> >> - 10/100 only or can use 10/100/1000?
> >> 2. Is there any workload characterization?
> >> - Packet sizes/distribution
> >> - burstiness
> >> 3. What is the expected/acceptable performance criteria?
> >> - Throughput at the end-station
> >> - Latency/Latency jitter
> >> - Packet drop sensitivity?
> >> - clock sync need (with respect to what?)
> >> 4. Is any quantitative data available that shows above can
not
> >> be met on GiGE? (Except clock-sync). Pointer will
certainly
> >> help.
> >> 5. What is a synchronous frame? Pointer to any prior work
will
> >> really help.
> >>
> >> Appreciate any feedback.
> >>
> >> Thanks,
> >> - Manoj
> >>
> >>
> >> -----Original Message-----
> >> From: owner-stds-802-3-re@listserv.ieee.org
> >> [mailto:owner-stds-802-3-re@listserv.ieee.org] On Behalf Of David V
> >> James
> >> Sent: Wednesday, August 25, 2004 12:02 PM
> >> To: STDS-802-3-RE@listserv.ieee.org
> >> Subject: [RE] Synchronous ethernet discussions
> >>
> >> All,
> >>
> >> We had quite a few adhoc like teleconferences before
> >> the Residential Ethernet became a study group. I found
> >> these to be very helpful, and we now have an official
> >> reflector to continue that activity.
> >>
> >> I'll throw out a few ideas for discussion, to stimulate
> >> such activities. Please respond if you deem this inappropriate
> >> (in which case I will stop) or continue with criticisms,
> >> refinements, or alternative concepts.
> >>
> >> It seems like there are a few issues to be addressed,
> >> including:
> >>
> >> 1) Synchronous frame formats. Should we:
> >> a) Is a synchronous frame simply an frame with a distinct
> >> typeLength field?
> >> b) Is a synchronous frame a collection of subframes,
> >> so that it can be more compact, but easily converted
> >> into real frames in a context-free manner?
> >> c) Is a synchronous frame a collection of data chunks,
> >> so that it can be most compact, but only converted
> >> into real frames in a context-dependent manner, based
> >> on setup information stored in the bridge and/or
> >> destination?
> >> DVJ preferences:
> >> 1a or 1b, with 1b if necessary for efficiency.
> >>
> >> 2) Bandwidth allocation. How does the "system" ensure that
> >> the bandwidth allocations on any specific link do not
> >> exceed its capacity?
> >> a) A central manager.
> >> b) Connection-establishment information flows through
> >> bridges, over the same path that the data will follow.
> >> DVJ preferences:
> >> 2a, as bridges are done today.
> >>
> >> 3) Frame timing.
> >> a) Do we support jumbo frames on 100Mb, in which case it
> >> may be necessary to preempt nonsynchronous frames?
> >> b) Is a form of synchronous timing necessary, to avoid
> >> bunched traffic that exceeds the link capacity?
> >> DVJ preferences:
> >> 3a) No strong opinions.
> >> 3b) Yes, 125us seems to be a good number.
> >>
> >> 4) Clock-synchronization accuracies.
> >> a) Is application level synchronization sufficient?
> >> b) Does data have to be closely synchronized with the clock?
> >> DVJ preferences:
> >> 4a) No. Some lower-level hardware snapshot hardware is needed.
> >> 4b) No. Data frame jitter can be much larger (a few 125us
cycles)
> >> than an acceptable jitter error in synchronized clocks.
> >>
> >> Some thoughts to stimulate some conversation...
> >>
> >> DVJ
> >>
> >>
> >> David V. James
> >> 3180 South Ct
> >> Palo Alto, CA 94306
> >> Home: +1.650.494.0926
> >> +1.650.856.9801
> >> Cell: +1.650.954.6906
> >> Fax: +1.360.242.5508
> >> Base: dvj@alum.mit.edu
> >>