linux returns EAGAIN for closed ocserv interfaces

Nikos Mavrogiannopoulos nmav at gnutls.org
Fri Sep 26 06:28:01 PDT 2014


On Fri, 2014-09-26 at 13:33 +0100, David Woodhouse wrote:

> > > (Has anyone been running VoIP over ocserv connections, btw? This talk of
> > > buffers and EAGAIN reminds me that we need to make sure we avoid
> > > excessive buffering. cf.
> > > http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/3444f811
> > > )
> > 
> > I am. One can tune it using the output-buffer parameter. Since you
> > brought that, I suspect that this particular commit must have been the
> > responsible for the asymmetry in upload/download (it was on an old
> > thread, with openconnect upload being 4 times slower than download).
> > Unfortunately I have no longer the hardware to verify that theory.
> Hm, maybe I was a little too aggressive about cutting down the output
> buffering? But if we ask for MTU*2 don't we actually get to put *four*
> full-MTU packets into the socket before it stalls? Surely that ought to
> be enough to keep the packets flowing?

Well VoIP packets are quite short, and may not be easy to find a value
that would allow both low latency and bandwidth. If I remember well
g.729 uses 20-bytes for 20-ms while g.711a 200 bytes, meaning with 4 mtu
packets you can get a 500ms delay on g711a, but in g.729 it could be 5
seconds. It would be best to leave some reasonable default that does not
really hamper bandwidth, and allow configuration for certain cases. I
for example noticed that I use a 60-mtu packets buffer with g711a, and
have not noticed jitter during talk.

> Was there anything special we needed to test this? Just ocserv and
> openconnect running on different hosts on a gigabit Ethernet segment?

That's what I was using.

regards,
Nikos





More information about the openconnect-devel mailing list