RE: [RPRWG] Cut through definition?
I hope no one is talking of pre-emption during transmisison here. Did I
miss something ?
Regards,
Devendra Tripathi
VidyaWeb, Inc
90 Great Oaks Blvd #206
San Jose, Ca 95119
Tel: (408)226-6800,
Direct: (408)363-2375
Fax: (408)226-6862
> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxx [mailto:owner-stds-802-17@xxxxxxxx]On
> Behalf Of Leon Bruckman
> Sent: Wednesday, April 11, 2001 3:32 AM
> To: 'davidvja@xxxxxxxxxxx'
> Cc: stds-802-17@xxxxxxxx
> Subject: RE: [RPRWG] Cut through definition?
>
>
>
> DVJ
> My personal view is that preempting lower traffic in the middle
> of a packet
> adds complexity that is not really needed. At 1G, the
> transmission time for
> a 1500 bytes packet is 12 usec, so the worst case for a 256 ring
> will be 3.1
> msec of added delay because of low packets being transmitted and not
> preeempted. Furthermore, the probability of the worst case is
> very small. We
> did some simulations with the following assumptions:
> - There is always a low priority packet being transmitted by the node
> - High priority packet may arrive at any time during the low
> priority packet
> transmission (equal probability)
> Some of the results were presented during the January interim (by
> Gal Mor).
>
> For a 128 nodes ring operating at 1G the preeemption gain will still be in
> the msec range with very high probability, and this can easily be absorbed
> by the jitter buffers at the receiver.
> Leon
>
> -----Original Message-----
> From: David V. James [mailto:davidvja@xxxxxxxxxxx]
> Sent: Friday, April 06, 2001 4:27 AM
> To: Carey Kloss; Devendra Tripathi
> Cc: stds-802-17@xxxxxxxx
> Subject: RE: [RPRWG] Cut through definition?
>
>
>
> All,
>
> Relative to the discussion of cut through, et. al.
> My perception is that a cutthrough node has two
> insertion buffers, for classA (provisioned synchronous)
> and classB (provisioned asynchronous).
>
> The preferred transmit order is as follows:
> a) classA insertion buffer (always)
> b) classA transmit traffic (subject to provisioned rate)
> c) asynchronous traffic.
> The classA insertion buffer only needs to be the size of
> the maximum packets sent by this node, plus (perhaps) some
> extra symbols to deal with hardware decoding latencies.
>
> The classB insertion buffer is to deal with the accumulation
> asynchronous packets that occurs when (worst case) full asynchronous
> is coming in/out and rate-limited synchronous is being transmitted.
> The size of the classB buffer is on the order of several upsteam-link
> delays times rateOfSynchronous/rateOfLink ratio.
>
> Order of the asynchronous traffic (c) depends on the classB
> buffer-filled status, prenegotiated vs. consumed rates, and
> the size of the asynchronous backlog in the client.
>
> The asynchronous transmit buffer is a bit schitzophrenic on its
> behavior. It should be in the client (not the MAC) because that
> allows packets to be reordered/inserted/deleted until the just
> before transmission time. However, the amount of traffic in the
> asynchronous transmit queue may influence the MAC queue-selection
> and throttle-signal assertion properties.
>
> I personally favor allowing cut-through synchronous traffic to
> preempt asynchronous, even in the middle of a packet. That's
> yields the lowest possible jitter, but at some encoding complexity
> costs.
>
> DVJ
>
>