Re: MAC delay constraint
Hi Pat
pat_thaler@xxxxxxxxxxx wrote:
>
> Gareth,
>
> We did discuss delay constraints at the meeting. There were quite a few good
> comments on them in the ballot especially ones by Adam Healey which
> contained analysis showing that some of the current numbers were to small
> and proposed more achievable values. The editor's took away an action item
> to make the delay specs more consistant from clause to clause and to assure
> that d2.1 has a consistant set of numbers that will allow interoperability
> at our interoperability interfaces.
I wasn't aware of this until I received the resolved comments database;
it's one of the downsides of a multi-tracked meeting is that one cannot
be everywhere :-(
The reason I've restarted this discussion is that I believe the MAC
delay constraint numbers to be unduly severe, but going through the D2.0
spec and comments gave me a bit of a fright.
>
> I'm not sure what you meant to say in your last comment. We cannot get
> interoperability by just having an overall spec. We need specs that will
> allocate the delay to each side of compatability interfaces and that is what
> we agreed to do.
Absolutely! What I was pointing out was that Shimon's comment was
rejected on valid grounds (although he may not agree!), but that the
issue remained unresolved.
>
> If you want to be part of what's going on, you really need to participate in
> the comment generation and resolution process. Reflector discussions can
> help bat ideas around, but they aren't what changes the draft.
Again, agree wholeheartedly. Unfortunately I've come to the table quite
late (mid December) and there was an awful lot of information to
assimilate quickly if I wanted to make meaningful comments within the
fortnight then available; the comments I did make were editorial rather
than technical for that reason. The full implications of the delay
constraints question only hit me over the weekend.
I do intend to participate more fully in the D2.1 commenting process!
There are too many observers of this process and not enough
participants.
>
> Pat
>
Cheers
Gareth
> -----Original Message-----
> From: Gareth Edwards [mailto:Gareth.Edwards@xxxxxxxxxx]
> Sent: Wednesday, January 24, 2001 10:16 AM
> To: HSSG
> Cc: Shimon.Muller@xxxxxxxxxxx
> Subject: MAC delay constraint
>
> Hello all,
>
> I watched with interest in December as a discussion started on the
> reflector on delay constraints within the various clauses, which then
> diverged into a discussion on what constituted a point-to-point link and
> what the effects of 40km of fiber would be. Neither discussion addressed
> the point at hand, namely the bounding of delays in layers, consistent
> with some budget defined in clause 31.
>
> For instance, in clause 46.2.7 and table 46-5 of the D2.0 draft, the end
> to end delay time for the MAC+RS is specified at 256 bit times. The PCS
> has a similar specification which is equivalent to 1024 bit times but is
> quoted in ns to avoid coded/uncoded bit time confusion. Clause 51 PMA
> indicates that there is a minimum of 16 (coded) bit time delay due to
> the serdes function, but places no upper bound on what this delay could
> be. The clause 52 PMD has no specified delay, but an editor's note
> saying something along the lines of "This is not important anymore".
>
> Leaving for now the obvious stylistic inconsistencies, there is a total
> budget in clause 31B.3.7 for MDI->MAC Control->MDI of 40 pause_quanta. I
> can only see 5 pause_quanta accounted for in the above specification.
> Have we underestimated the requirements for delay within the sublayers,
> given the total requirement?
>
> Does anyone else see this? I think Shimon does, but his comment at
> Irvine was rejected on the basis that it proposed to drop individual
> layer constraints in favour of the 31B.3.7 spec; this makes
> interoperability difficult at best.
>
> Cheers
> Gareth
>
> --
> / /\/\ Gareth Edwards mailto:gareth.edwards@xxxxxxxxxx
> \ \ / Design Engineer
> / / \ System Logic & Networking Phone: +44 131 666 2600 x234
> \_\/\/ Xilinx Scotland Fax: +44 131 666 0222