<p dir="ltr">On 12 Mar 2015 20:18, "Narseo Vallina Rodriguez" <<a href="mailto:narseo@icsi.berkeley.edu">narseo@icsi.berkeley.edu</a>> wrote:<br>
><br>
> Hi Jonathan<br>
><br>
> > Status quo is that loading a web page with many resources on it is<br>
> > unreliable. Early connections succeed and become established, the congestion<br>
> > window opens, the buffer in the 3G tower begins to fill up, inducing several<br>
> > seconds of latency, and subsequent DNS lookups and TCP handshakes tend to<br>
> > time out. End result: often, half the images on the page are broken.<br>
> ><br>
><br>
> The way you're describing this specific part, sounds more to me like a<br>
> control-plane latency issue (i.e., the time for the RNC to allocate a<br>
> radio channel to the client by promoting it from IDLE/FACH to DCH)<br>
> rather than a buffer size related issue (which is actually introduced<br>
> both on the handset and the RNC/eNB to deal with the C-Plane latency)<br>
><br>
> <a href="https://www.qualcomm.com/media/documents/files/qualcomm-research-latency-in-hspa-data-networks.pdf">https://www.qualcomm.com/media/documents/files/qualcomm-research-latency-in-hspa-data-networks.pdf</a></p>
<p dir="ltr">No, that's backwards. The first connection is the most reliable, because the link isn't loaded yet, and trying to make later connections times out because the buffers are full from the first ones, still in progress. If C-plane latency was the problem, the symptoms would be reversed - unless the system is inexplicably reverting to the idle state between packets in a continuous stream, and I refuse to believe it's that dumb without firm evidence.</p>
<p dir="ltr">Unloaded latency on this link is on the order of 100ms.</p>
<p dir="ltr"> - Jonathan Morton</p>