On Mon, 2019-03-25 at 22:01 +0000, David Woodhouse wrote:
> On Mon, 2019-03-25 at 21:50 +0000, Phillips, Tony wrote:
> > So before commenting this output line out, this is what I see:
> >
> > Requeueing failed ESP send (work done 0, monitored 0): Resource temporarily unavailable
> > Requeueing failed ESP send (work done 0, monitored 1): Resource temporarily unavailable
> > Requeueing failed ESP send (work done 0, monitored 1): Resource temporarily unavailable
> > Requeueing failed ESP send (work done 1, monitored 0): Resource temporarily unavailable
> > Requeueing failed ESP send (work done 0, monitored 1): Resource temporarily unavailable
> > Requeueing failed ESP send (work done 1, monitored 0): Resource temporarily unavailable
> > Requeueing failed ESP send (work done 1, monitored 0): Resource temporarily unavailable
> > Requeueing failed ESP send (work done 0, monitored 1): Resource temporarily unavailable
> > Requeueing failed ESP send (work done 1, monitored 0): Resource temporarily unavailable
> > Requeueing failed ESP send (work done 0, monitored 1): Resource temporarily unavailable
> > Requeueing failed ESP send (work done 1, monitored 0): Resource temporarily unavailable
> > Requeueing failed ESP send (work done 1, monitored 0): Resource temporarily unavailable
> > Requeueing failed ESP send (work done 1, monitored 1): Resource temporarily unavailable
> > Requeueing failed ESP send (work done 1, monitored 0): Resource temporarily unavailable
> > Requeueing failed ESP send (work done 1, monitored 0): Resource temporarily unavailable
> > Requeueing failed ESP send (work done 1, monitored 0): Resource temporarily unavailable
> > Requeueing failed ESP send (work done 1, monitored 0): Resource temporarily unavailable
> > Requeueing failed ESP send (work done 0, monitored 0): Resource temporarily unavailable
> > Requeueing failed ESP send (work done 1, monitored 0): Resource temporarily unavailable
> > Requeueing failed ESP send (work done 1, monitored 0): Resource temporarily unavailable
> > Requeueing failed ESP send (work done 1, monitored 0): Resource temporarily unavailable
> > Requeueing failed ESP send (work done 1, monitored 0): Resource temporarily unavailable
> > Requeueing failed ESP send (work done 0, monitored 1): Resource temporarily unavailable
>
> OK, you should be getting 'monitored 0' when the packet first failed to
> send, then 'monitored 1' when the packet was already requeued once
> before, and the socket was being monitored for writeability.
>
> It does look like it *isn't* spinning in an attempt to write. Running
> with -vvv may confirm that, as it shows the packets being correctly
> sent. Or might just slow the whole thing down to the point where the
> interesting case isn't happening any more.
>
>
> > Performance was about the same as previous run (~20 MB/sec)
> >
> > Commenting out the vpn_progress() call actually helps quite a bit!
> > I'm getting runs now as fast as 50MB/sec.
>
> That makes sense.
>
> > Still see lots of the same IP/UDP errors, and TCP is fairly clean
> > with only 23 retransmitted segments after 10 "dd" runs.
>
> Yeah, the attempts to send UDP packets while the sendbuf is full are
> still reported, but those packets aren't *lost* any more; they're sent
> as soon as the socket will accept them.
>
> > Run times are rather variable -- with the bs=33554432, runs range
> > between 20MB/sec to sometimes 50MB/sec.
> >
> > If I increase it, the runs tend to narrow down closer to 20MB/sec all
> > the time.
> >
> > Making progress!!
>
> At this point, you appear to be sending packets to the UDP socket as
> fast as it will accept them. Now, maybe there's some issue with latency
> and fairness, and the ACKs coming back are somehow relevant here? But I
> wouldn't have expected that.
>
> Now would be the time to try reducing the MTU. I wonder if your UDP
> frames are getting fragmented in transit, making less optimal use of
> the physical bandwidth than they should? Are you able to capture the
> encrypted traffic on the ingress network next to the VPN server?
>
> Can you try running a UDP netperf over the VPN, to eliminate TCP
> issues? And in fact, try running the same UDP netperf over the
> underlying public network, with various packet sizes.
You can also experiment with increasing core.wmem_{default,max} at this
point and see if it now helps.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
