Date: Fri, 19 May 2006 12:38:31 -0400 From: Mike Tancsa <mike@sentex.net> To: Ian Smith <smithi@nimnet.asn.au> Cc: freebsd-net@freebsd.org Subject: Re: improving transport over lossy links ? Message-ID: <6.2.3.4.0.20060519121104.1126b480@64.7.153.2> In-Reply-To: <Pine.BSF.3.96.1060520014045.15967A-100000@gaia.nimnet.asn. au> References: <6.2.3.4.0.20060519110026.05820230@64.7.153.2> <Pine.BSF.3.96.1060520014045.15967A-100000@gaia.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
At 12:06 PM 19/05/2006, Ian Smith wrote:
>Assuming that V.42 error correction is working properly - forced if need
>be - there shouldn't =be= any data loss, however slow getting through,
>this side of protocol timeouts of course. I can't guess your mystery
>application, but often slower connections are better than dropped ones,
>or even ones that spend half their time trying to retrain at high rates.
Hi,
Thanks for the reply. Even at 28.8 I am seeing loss with
the connection dropping and seeing dropped packets (e.g.
May 19 12:04:43 soekris4801 ppp[3404]: tun0: Phase: 1: HDLC errors ->
FCS: 1, ADDR: 0, COMD: 0, PROTO: 0)
Error correction is on and negotiated, from the terminal server's
perspective at least and I imagine the modem too
Testing here at the office
Card Type: LU1674 Chipset
State: ACTIVE
Active Port: S26
Transmit Rate: 28800
Receive Rate: 26400
Connection Type: LAPM/V42BIS
Chars Sent: 215666023
Chars Received: 58090941
Retrains: 0
Renegotiations: 4
The application is TCP based and monitors remote machinery. (And no,
there is no chance at this point to re-write the application). The
transport is over a VPN (either IPSEC or OpenVPN) which ever deals
better with the lossy connection. However, many of the sites have
dynamic IP addresses which makes it a pain to use with IPSEC and FreeBSD.
One think I observed with multi-link so far is that if I kill one of
the connections, the modem does not tell ppp that it has lost carrier
right away. Instead, I have to wait for the LCP echo timeout. In the
mean time, I get 50% packet loss for about 20 seconds. However I can
reduce that by setting the lqrperiod to a lower value. However, I
dont want that too low, otherwise it spends all its time chewing up
the link with LCP traffic.
I was going to look at the one2many ng module to see if I can send
out the same packets on both links at the same time as a sort of "as
long as one packet gets there strategy" Although the customer doesnt
use wireless right now, we might have some sites that would need it
in the fture and this might be an approach. I imagine satellite users
run into this as well no ?
---Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6.2.3.4.0.20060519121104.1126b480>