No subject


Mon Jul 5 15:10:54 CEST 2010


0x800 indicates that a buffer size of 2048 bytes was allocated for the
read, and the return value of 2048 indicates how many bytes were
successfully read. Note that this 2048byte read buffer is not linked
to the 16384 KB cache that I had specified.

Could this be the cause of the problem? Looking at the dtruss output
for the cat command, the buffer size is 0x20000, or 131072 bytes,
which is significantly larger than 2048.

I did some other tests that suggest that this read buffer size really
could be the problem.

dd if=3D/Volumes/share/path/to/file.mkv of=3D/dev/null bs=3D2048 yields
consistent network speed of ~ 660KB/s, just like mplayer.

I hypothesize that the read syscall blocks, and so the maximum
theoretical throughput would be bounded by buffersize/network latency.
On my wireless network, I get pings to the NAS of approximately 2.5ms.
ie, 0.0025ms

Playing with other values shows that the read buffer size has a
visible relationship to network speed, up to a certain point.
bs (B) approxthroughput (KB/s) theoretical bs/latency (KB/s)
512 150 204
1024 400 410
2048 650 819

Is it possible to increase the read buffer to something that would
work in high bandwidth, high latency environments? If possible, I'd
suggest going with the value used by cat (128KB or 131072 bytes), so
that high throughput is still achievable in a long distance network
with 100ms latency. Alternatively, something which pre-fetches from
file streams to fill the cache buffer might do the trick too.

I think the 2048b buffer size is defined in main/stream/stream.h
57: #define STREAM_BUFFER_SIZE 2048

and it's used in main/stream/stream_file.c
54: static int fill_buffer(stream_t *s, char*=A0buffer, int max_len){
int r =3D read(s->fd,buffer,max_len);
=A0=A0return (r <=3D 0) ? -1 : r;
}
79: int len=3Ds->fill_buffer(s,s->buffer,STREAM_BUFFER_SIZE);


More information about the MPlayer-users mailing list