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
>>