Carlos has a tendency to do this. :-)
In a good way!
Paul
Paul Negron
CCIE# 14856
negron.paul_at_gmail.com
On Jan 12, 2013, at 9:08 PM, Dave Serra <maybeedave_at_yahoo.com> wrote:
> With my previous example of the 56k link between California and NY I was
> trying to create an example where propagation delay is actually longer then
> serialization delay and show that serialization is complete before the
packet
> reaches the other side due to a very large propagation delay. I probably
> botched that given how long packets take to serialize on a 56k link. So
let
> me change my example to a 10Gig link between Californial and NY. Now in
this
> case the packet will fully be serialized before it reaches the other side
and
> it is in this case I believe we would have to take into
> acount 'deserialization' delay (I really like that one ;) ). So in that
> example we really can't overlap time persay.
>
> The 'time shift' concept is an
> interesting one when at that same point in time bits are being serialised
at
> one end and deserialized at the other but it does not take into account of
> everything. For example, take a 1500byte packet (12000 bits) that has
> serialized the first 2000 bits at the sender before the first bit reaches
the
> receiver. Now the 1st bit at the receiver should be deserialized at the
same
> time as the 2001st bit is serialized at the sender. So we now only have to
> account for the deserialization delay of the last 2000 bits as the packet
at
> the sender has finished serializing them so there is no more overlapping
time.
>
> This is a pretty good discusion as I only came up with the above after
think
> about what you said. You are making me think ;)
>
>
>
>
>
> Make a small loan,
> Make a big difference - Kiva.org
>
>
> ________________________________
> From:
> Carlos G Mendioroz <tron_at_huapi.ba.ar>
> To: Dave Serra <maybeedave_at_yahoo.com>
> Cc: "ccielab_at_groupstudy.com" <ccielab_at_groupstudy.com>
> Sent: Saturday, January
> 12, 2013 7:08 PM
> Subject: Re: QoS - Calculating path latency
>
> Well, it does
> not matter if the cable is 1 mt or 30km, because
> that time is taken into
> consideration by propagation delay.
>
> But tx serialization takes exactly the
> same time that rx
> "deserialization" takes, and once you do the "time shift",
> they can overlap.
>
> If you are able to see that the distance is not an issue,
> then you
> should see that one bit out the tx buffer happens at the same
> "shifted"
> time that the same bit enters the rx buffer.
>
> Your sentence about
> not being able to start receiving until you end
> transmitting is not true. It
> depends on which time is greater:
> serialization or propagation...
>
> -Carlos
> Dave Serra @ 12/01/2013 17:06 -0300 dixit:
>> hmmmm....I suppose on 10Gig links
> of short distances in a store and
>> forward switch this might happen and it
> most certainly does happen on a
>> LAN where R2 is a cut-through switch as R2
> can be bringing a packet in
>> while R1 is still serializing the tail end of it
> but lets assume that
>> these are long (from california to NY) links of 56k.
> In this scenario
>> R2 can not bring the packet into the router (what I am
> calling
>> 'serialization delay'. maybe I should call it 'input-serialization
>>
> delay' for better clarity) until R1 has finished serializing the packet
>> and
> it reaches R2.
>> Make a small loan, Make a big difference - Kiva.org
>> *From:*
> Carlos G Mendioroz <tron_at_huapi.ba.ar>
>> *To:* Dave Serra
> <maybeedave_at_yahoo.com>
>> *Cc:* "ccielab_at_groupstudy.com"
> <ccielab_at_groupstudy.com>
>> *Sent:* Saturday, January 12, 2013 2:58 PM
>>
> *Subject:* Re: QoS - Calculating path latency
>>
>> Hey Dave,
>> it might be that
> the R2 read serialization happens exactly as (during)
>> R1 write serialization
> ? Then, they do not add up, but only one of them
>> is used to account them
> both.
>>
>> -Carlos
>>
>>
>> Dave Serra @ 12/01/2013 16:41 -0300 dixit:
>>> I have
> a question. I've been reading Wendell Odom's cisco press book
>> 'Cisco
>>>
> QoS, Exam Certification Guide'. In it he calculates total latency
>> for the
>>> path as processing delay, serialization delay, propagation delay,
>>
> etc... My
>>> question is why do we calculate serialization delay only as
> the packet is
>>> leaving the interface and being placed on the wire and not
> ALSO when the
>>> packet is being received by the remote router. Surly there
> is some
>> delay to
>>> take an incoming packet off of the wire and store the
> bytes in memory
>> prior to
>>> processing it. So in other words, in the
> network as
>> PC1-->R1-->R2-->PC2 why
>>> are we not including the delay to
> get the packet off of the wire and into
>>> R2. ie, assume packet is already
> in R1--> processing delay, seralization
>>> delay of R1, propagation delay to
> reach R2 and then serialization
>> delay again
>>> to get the packet into R2
> for its processing?
>>>
>>> BTW, I know I grossly
>>> missquoted Odom by
> only including processing delay, serialization delay,
>>> propagation delay,
> etc... He has a lot more delay types in his book. My
>>> question really
> only focuses on the packet that is in R1 and getting
>> into R2
>>> so I
> omitted the others.
>>>
>>> I appreciate anyone's feedback.
>>>
>>> Thanks
> guys.
>>> Make a small loan, Make a big difference - Kiva.org
>>>
>>>
>>>
> Blogs and organic groups at http://www.ccie.net/
>>>
>>>
> _______________________________________________________________________
>>>
> Subscription information may be found at:
>>>
> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Carlos G Mendioroz <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>> LW7
>> EQI Argentina
>>
>>
>
> --
> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI
> Argentina
>
>
> Blogs and organic groups at http://www.ccie.net/
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Sat Jan 12 2013 - 22:06:14 ART
This archive was generated by hypermail 2.2.0 : Sun Feb 03 2013 - 16:27:17 ART