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