Jeff, On Jul 8, 2014, at 12:31 PM, Jeff Pinner <jpinner@twitter.com> wrote: >> It is not the size of the frame that hurts multiplexing, it is the >> amount of time it takes to move it, also known as "bandwidth". > > It's not that large frames hurt multiplexing necessarily, it's that it > hurts "responsiveness." > > If you are in the process of sending a large data frame, you cannot > respond to a PRIORITY frame that prioritizes a different stream and > begin to send data for that stream until the entire frame is flushed. How fast do you need to respond to a PRIORITY frame? What are you trying to do that requires such a sudden priority change? What are your performance requirements? Let's take a 5mbit/sec DSL connection (pretty typical low-end "high speed" service offered in many locations). The time to transmit a 16k DATA frame over that link would be approximately 33ms, 32k would take ~66ms, 64k would take ~131ms, and so forth. None of those times seem overly long to me, and certainly I'm not going to really notice any loss of responsiveness if the page or new video starts loading 1/8th of a second after I click on a link. But what I *will* notice is video stuttering caused by too much multiplexing, or apparently hung page loads because the priority for a video stream was set to the maximum just to ensure that two small DATA frames would be delivered close together so that the video doesn't stutter. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Tuesday, 8 July 2014 17:01:55 UTC