[vlc-devel] [PATCH 0/1] Improve SFTP network performance with buffer

Ilkka Ollakka ileoo at videolan.org
Thu Feb 15 10:29:39 CET 2018


On Wed, Feb 14, 2018 at 07:51:45PM +0200, Rémi Denis-Courmont wrote:
> Le mercredi 14 février 2018, 16:05:00 EET Martin Disch a écrit :

> > Not requesting that many bytes in one call of Read() might be ok
> > for devices that have relatively low latency due to being attached to the
> > local machine, but when these requests go over a network with some latency,
> > it's less than ideal.
> 
> It is the other way around. The more bytes you request from the previous 
> layer, the worse the latency becomes. Latency is minimized by requesting the 
> same number of bytes than a lower-layer frame can carry. Requesting more than 
> that will increase latency, as frame will need to be batched. If the request 
> size exceeds the upstream buffer size, then latency will explode, as network 
> round-trip becomes necessary to fill the request.
> 
> That is why the prefetch module makes relative small requests by default 
> (16 KiB), but then keeps asking for data until buffers are full, to reduce the 
> risk of TCP-level congestion and back-off.

hmm. I tought I saw 4096 as default read-size in code somewhere when
looked at this. But it's not that familiar code-area for me.

I got the impression that pf_read was meant for streaming-access where
you by nature of input can't really pre-fetch (dvb-card etc). And
pf_block would be in case you can by nature seek/prebuffer into future?

In that point of view, not sure how pre-fetch should even work with
pf_read calls, unless they are just for quick jumping back, as Martin
seems to point happening.

All that could is just speculation, as I don't remember writing any of
the related code.

-- 
Ilkka Ollakka



More information about the vlc-devel mailing list