Re: [RE] Synchronous ethernet discussions
More comments...
-----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: Thursday, August 26, 2004 7:21 PM
To: STDS-802-3-RE@listserv.ieee.org
Subject: Re: [RE] Synchronous ethernet discussions
All,
Good to see that so more thoughts come once one breaks the ice.
A few thoughts follow...
>> 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
I tend to prefer interleaving traffic on the existing wires. That has
the
advantage that existing interfaces are more likely to work and keeps the
costs low.
<DC> From a silicon vendor's perspective, the more PHYs the better :-)
</DC>
There is no particular harm in delaying the synchronous traffic for
on the order of 125us, when it happens to be backed up behind an
in-progress asynchronous frame, provided that:
1) There are accurate clocks in the application, so that the traffic
can be buffered and sent (to the speaker, for example) at the right
time.
2) The delay due to the temporary asynchronous traffic blockage is,
indeed, on the order of 125us.
A point of interest:
120 us = (1500 bytes) * (8 bits/byte) / 100Mbs
Which means that asynchronous frame delays are reasonable on a 100Mbs
link, if jumbo frames are not supported, but not for 10Mbs.
A second point of interest:
68 us = (8,500 bytes) * (8 bits/byte) / 1Gbs
Which means that asynchronous frame delays are reasonable on a 1Gbs
link, even if jumbo frames are supported.
Of course, if one allows a synchronous frame to preempt an asynchronous
frame, then its possible to support jumbo frames even on a 10Mbs link.
Preemption at first seems scary, raising thoughts of fragmentation
buffers and special transmission codes. Its not really that bad, though,
if one only allows for one level of pre-emption, always returns to
the preempted frame, and avoids the use of special codings.
<DC> Evaluation of preemption without defining precisely how media
traffic will be carried is difficult, because such analysis is based on
worst cases.
Perhaps we should start the discussion with proposals for a sync cycle,
size of media frame, and a reservation mechanism. Then we can reason
about frame preemption...</DC>
<DC>Dirceu</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.
I was thinking that:
* data-delivery jitter is on the order of 125us,
* data-delivery latency is on the order of N*125us*B
where:
N is on the order of 1-4, the number of interval delays through
bridges
B is the number of bridge hops, limited perhaps to 5-10
HOWEVER, the clock jitter, as presented to the D/A converter of the
application,
must be much less, probably down in the tens of ns before PLLs and in
the ps
range after PLL filtering.
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 Dirceu
>> Cavendish
>> Sent: Thursday, August 26, 2004 11:16 AM
>> To: STDS-802-3-RE@listserv.ieee.org
>> Subject: 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
>> > >>
>>