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@xxxxxxxxx
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.oftc.net
