Re: [codec] #19: How large is the frame size depended delay / the serialization delay / frame size depended processing delay?

["codec issue tracker" <[e-mail]>]

#19: How large is the frame size depended delay / the serialization delay /
frame size depended processing delay?
------------------------------------+---------------------------------------
 Reporter:  hoene@…                 |       Owner:     
     Type:  enhancement             |      Status:  new
 Priority:  minor                   |   Milestone:     
Component:  requirements            |     Version:     
 Severity:  -                       |    Keywords:     
------------------------------------+---------------------------------------

Comment(by hoene@…):

 [Cullen]:
 This does not match the measurements I have. And I certainly don't have
 100+ year voip experience but I do have two of the #1 selling enterprise
 phones connected to an oscilloscope. Test with other phones suggest most
 the major vendors of IP hard phones have fairly comparable performance
 when it comes to delay.

 [Raymond]:
 Hmm... That's interesting.  Would you please share more details of your
 measurement equipment setup, the codec used, the codec frame size, the
 number of codec frames in each packet, the way you measured the delay, and
 the measured delay value, etc.?

 [Cullen]:
 Sure - it's really simple to set up. I use a signal generator that makes a
 tone burst. Typically I do something like 550 Hz tone that is a 200 ms
 long burst that occurs once a second. I play this into a speaker near the
 microphone on one phone and also put it into 1 channel of a scope.  I
 think put a microphone near the speaker of the other phone and put that on
 another channel of the scope and measure the mouth to ear delay. It's
 really easy to see the starts of the two bursts from the speaker and
 microphone and measure the delay within a few ms. I've done lots of clever
 things over the years using stats from software in the phones but this
 technique is easy and pretty fool proof on getting good results. The
 phones were plugged into Netgear 100Mbps hub as I sometimes look at the
 timing of the ethernet packets too. I set up phones for G.711, one frame
 per packet - I choose this as  it is easy to change the length of each
 frame but results are similar with other codecs.

 I was using two Cisco 7960 phones - no idea what version of the software
 and may have been a development build but it's pretty unlikely that
 current production software would have different results from what I
 tested. I set the phones for G.711 with 20 ms packets, measured delay,
 then set the phones for 30 ms packets and measured delay. For a given
 packet length, when I make multiple phone calls or reboot one of the
 phones, the measurements stay consistent.

 The resulting change in delay between the two experiments was much less
 than 30ms that a (3x 30 ms - 3 x 20 ms) would have predicted. I feel like
 a total tool not providing the details of the exact measurements but lots
 of measurements like this Cisco considers confidential and I'm just not up
 to arguing with folks about what can and can not be said publicly. I
 probably should have done a test with 10 ms packets too but I did not. Yes
 I realize how nuts it is to consider something that anyone can easily
 measure as confidential. If anyone really cares, I will go do the work to
 be able to provide the numbers.


 [Raymond]:
 I didn't come up with this 3*(codec frame size) delay number for IP phones
 myself.  A very senior technical lead in Broadcom's IP phone chips group
 told me that, and Broadcom is currently the #1 world- wide market share
 leader in IP phone chips, accounting for more than half of the world's IP
 phone chip shipments. Most of the world's
 tier-1 IP phone manufacturers use our IP phone chips at least in some of
 their product lines.

 In my original email discussion of VoIP gateways, I did not use the phrase
 "ultra-low delay".  What I did say was that due to the large number of
 voice channels that the DSPs and the (possibly two layers of) micro-
 controllers have to handle simultaneously, the timing/scheduling can be
 quite complex, and the necessary buffering at the (possibly
 three) hierarchical layers of processors can add substantial delay.
 Therefore, the worst-case codec-dependent one-way delay may be up to 5X to
 6X the codec frame size before delay optimization, and even after the
 engineers "optimize the delay to death", they could only manage to get the
 worst-case codec-dependent delay down to around 3X codec frame size.

 Again, I didn't come up with that myself.  A senior technical guy who was
 deeply involved in high-density VoIP gateway designs told me that, and
 another technical guy who worked at a different company than the first guy
 and who was involved in the design of a different VoIP gateway based on a
 different DSP chip and a different system architecture independently gave
 me a range of codec-dependent one-way delay around 3X codec frame size,
 and he didn't know that I talked to the first guy.

 Due to this 3X multiplier, an increase in the codec frame size will have a
 larger delay impact in VoIP gateways than, say, a softphone that has a
 lower multiplier.

 [Koen]:
 Still:
 - You've presented no satisfactory explanation for your theory
 - Nor any verifiable empirical evidence
 - It comes from an anonymous source
 - It has changed over time (going from 5x to 3x)
 - It goes against accepted wisdom

 [Christian]:

 some recent studies on the speech quality of gateways and IP phones are
 present in http://www.head-
 acoustics.de/telecomfiles/5th_ETSI_SQTE_Anonymous_Test_Report.doc
 Please have a look at the document first...

 At the first glance, I did see evidence for the 3x factor for IP gateways.
 The best in class at a 40.4 ms one-way delay for G.711 (20ms packets) and
 a 54.3 ms delay for G.729 (20ms packets) referring to Tables 4.1 and 4.2.
 The algorithmic delay of G.729 is 15ms (5ms lookahead).  Thus, the
 algorithmic delay was 20ms for G.711 (plus an unknown delay of PLC) and
 25ms for G.729. Thus, a factor of 3 seems to be valid (5msx2,9=53,3-40,4)

 [Mikael]:
 One-way delay of 40.4ms for G.711 sounds like 20ms for packet size and
 20ms for jitter buffer. I wouldn't call that "algorithmic delay", that's
 packet and jitter buffer delay, "algorithmic delay" for G.711 should be
 "zero" or am I getting the concepts wrong (since it doesn't do any
 compression).

 [Roman]: This is a great discussion, but I don't see how it is relevant.
 If the question is should the new CODEC support 5 ms frames, then the
 answer is probably yes. If there a compelling reason (like achieving
 better quality or having algorithm delay that makes this irrelevant) we
 might agree to a bigger minimum frame size. If the question is if the
 CODEC should support 20ms and bigger compound frames, then the answer is
 absolutely yes. There are use cases for both. I guess, the only question
 for me, is if in case of 5 ms frames we care about compression. The packet
 header overhead is fairly big that you might use PCMU in this case.

 P.S. From what I know about soft phones the delay component dependent on
 frame size is 1x. There are other delay components, but they are not frame
 size dependent.

 [Stephen]:
 Total algorithmic delay for G.711 should be no more than .125 ms, total
 algorithmic delay for G.729 is 20 ms (15 ms per frame and 5 ms look-
 ahead).  References are here:
 http://en.wikipedia.org/wiki/G.711
 http://en.wikipedia.org/wiki/G.729

 [Frank Kettler]
 We did not explicitly verify the relation between algorithmic delay and
 the measured delay, because all manufactures typically built "something
 around". We tested "end products" (gateways, IP phones, ...) and there
 might always be some internal overhead compared to pure coders...

 [Raymond]:
 I agree with Roman that this 1X versus 3X debate has reached a point that
 it is almost irrelevant.  What's really relevant now is the question of
 whether the IETF codec should have a low-delay mode with a codec frame
 size of 5 to 10 ms, and for that question you previously wrote on May 6:

 CONSENSUS: No further discussions and clarifications on this issues.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/19#comment:4>
codec <http://tools.ietf.org/codec/>