[vlc-devel] [PATCH 0/1] Improve SFTP network performance with buffer
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.
More information about the vlc-devel