Lots of Flushing x bytes to y would block messages

[Guus Sliepen]

On Fri, May 06, 2016 at 05:48:35PM +0800, Terry T wrote:

> The server has a 1G symmetrical fibre line. It has been speedtested to
> various local servers to be close to 800-900M.

Ok, then we can rule out the Internet as the culprit.

> The server is configured as a bridge and is relaying multicasts
> continuously.  Below is the server configuration.
[...]
> Mode = hub

You want to use Mode = switch here, otherwise every packet is broadcast
to every node.

> Cipher = none
> Digest = none
> MACLength = 0
> PMTUDiscovery = yes

PMTUDiscovery might not work correctly if Digest = none or MACLength
= 0, because then there is no way to tell from which node packets with
an unknown address/port combination comes. So it could be that this is
forcing communication between nodes that are behind a NAT to go via TCP.
I recommend that if you really want Digest = none, that you set:

PMTUDiscovery = no
PMTU = 1440

> Broadcast = direct
> DirectOnly = yes

It's best to remove those two lines for efficiency.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20160506/cf8b39af/attachment-0001.sig>