Port locks with high time under LCNT

[John Högberg]

What you're seeing is caused by how we're using the `sendfile(2)`
system call. Like all other file operations it's impossible to make it
non-blocking on Linux, and since it's used from the output callback in
the inet driver it will block the scheduler until completion (while the
port lock is held, hence its visibility with `lcnt`). Fixing this is
non-trivial so we might force it to use the read/send fallback in a
patch.
/John
On Sat, 2020-01-04 at 11:39 +0100, Frank Muller wrote:
> Gonna update my design, test and report back 
> /Frank
> Sat. 4 janv. 2020 at 09:30, Max Lapshin <max.lapshin@REDACTED> wrote
> :
> > Yes.And we repack from mp4 to mpegts on fly.  We cannot do sendfile
> > due to this requirement and it happened that we do not need to do
> > it.
> > 
> > So 10 gbps is an absolutely normal load for E5.
> > 
> > But of course you need to be not green =)  Disable all powersave.
> > On Sat, Jan 4, 2020 at 10:59 AM Frank Muller <
> > frank.muller.erl@REDACTED> wrote:
> > > Hi Max
> > > Those numbers are amazing. Can you please elaborate more?
> > > So, you read data from disk with file:pread/3 and send it out
> > > using gen_tcp:send/2. Am I right?
> > > /Frank 
> > > Sat. 4 janv. 2020 at 08:32, Max Lapshin <max.lapshin@REDACTED>
> > > wrote :
> > > > I advise to try to refuse from sendfile and use pread/write
> > > > Our Flussonic can serve 10-20 gigabits per second. We have
> > > > removed all  "optimisations"  like mmap and so on and left with
> > > > old plain read/write.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200107/22f3ef1f/attachment.htm>