Re: [LARTC] Problems at end of slow satelite link

[Stef Coene <stef.coene@docum.org>]

On Monday 10 March 2003 12:00, Ben Clewett wrote:
> Stef Coene wrote:
> > I think it's best you create a htb setup with different classes.  One of
> > the classes needs a higher priority so the packets in that classes are
> > send first.  Next you need to put the ssh/telnet/syn/ack packets in that
> > classes. All needed information can be found in the LARTC howto.  And you
> > can also find more info on www.docum.org.
>
> This is Hierarchical Token Bucket, explained in section 9.4.5 of the
> HOWTO document?
>
> I was rather hoping you were going to surgest something else, as this is
> not in my kernel... :)
You can also use cbq.  But htb is easier to configure.  Or go for the 2.4.20 
kernel.  That has htb support.

> I will however check out the documentation in some more detail.  There
> are a few unresolved questions I have on this pleasent protocol.
>
> Like I notice it claims to scale up to the available bandwidth in
> proporsion to the allocated bandwidth.  I need to know how it calculates
> this bandwidth, as our link shows all the properties of the available
> bandwidth being proporsional to 1/S noise.  Ie, unpredictable and
> un-averagable.
>
> I would like to know also whether HTB scales down, if bandwidth becomes
> throtted by our unpredictable pipe.  And in either case, whether it's
> possible to have a protected channel, like an admin channel, which
> doen't scale up or down with the rest, staying at, say, 16kbit...
You can configure a protected channel with a minimum bandwidth.

> All of which I will now try and find out.  And then attempt to get it
> into my kernels at either end. :)
>
> Ben
>
> The biggest mistory of my link-from-hell is the ping.  This shows either
> a latency of 800ms, or 1.5 seconds, or up to 30 seconds when the line
> goes on-hold for a while.  About once every two minutes.  Yet Telnet/SSH
> consistently give latency far far more than this, of about 10 to 60
> seconds consistetly.
Have you tried screen?  If you start screen, you get a virtual console.  You 
can work in it like you normally do, but if your session is terminated, you 
can reconnect to the same screen session with "screen -r".  Very handy if you 
have a faulty connection :)

> If anybody can surgest a reason for this, I think this is likelly to be
> at the heart of any fix I can find...
I have no idea ..

Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/