Try the ez shaper wizard and do not over commit your real bandwidth available. Over commiting the bandwidth values will have huge consequences.
Scott On 7/25/05, Xtian <[EMAIL PROTECTED]> wrote: > > Bill and Scott: > > Many thanks for the info and the field descriptions. Right, I was doing about > 105KBps down (on my 1Mbps down, 384Kbps up DSL) which is everything, and then > initiated an SSH session and latency was as high as ever. Then I looked in > the rules and saw nothing for SSH. So I assumed it didn't know about SSH. That > ACKs in general are prioritized makes sense. I tried to make a queue > specifically for port 22 traffic, and wanted to elevate that above the > default queue, and thats where I was at a loss as to what I should put in > those schedule fields. I assumed that what Monowall handles with pipes is > what got put into scheduler options, but I was just not groking the logic > behind it. > > I'm a sysadmin by trade, not a netadmin, but I try to learn, you know? ;) > > -Christian > > > On Mon, 25 Jul 2005, Bill Marquette wrote: > > > On 7/25/05, Christian Rohrmeier <[EMAIL PROTECTED]> wrote: > >> I haven't found that to be true. It doesn't create any rules for SSH. > >> pfSense has a wide selection of games and P2P software that it will make > >> rules and queues for, but not SSH, unless I overlooked something. > >> Certainly trying to SSH whilst FTPing a large suffered from the same > >> massive lag as always. > > > > SSH sets the TOS lowdelay bit on all it's ACKs, so non-bulk SSH should > > by default go into the ACK queue. Any chance you were saturating your > > downstream with ACKs, which would force SSH and FTP to then compete > > within the same queue? > > > >> I would still like to know what the 6 fields in the traffic shaper > >> scheduler are for though! > > > > I'll update the code with comments, in the meantime, from the pf.conf man > > page: > > The hfsc scheduler supports some additional options: > > > > realtime _sc_ > > The minimum required bandwidth for the queue. > > > > upperlimit _sc_ > > The maximum allowed bandwidth for the queue. > > > > linkshare _sc_ > > The bandwidth share of a backlogged queue. > > > > <sc> is an acronym for service curve. > > > > The format for service curve specifications is (m1, d, m2). m2 controls > > the bandwidth assigned to the queue. m1 and d are optional and can be > > used to control the initial bandwidth assignment. For the first d mil- > > liseconds the queue gets the bandwidth given as m1, afterwards the value > > given in m2. > > > > The boxes correspond to m1, d, m2 in that order (except m1 and d are > > not optional with pfsense). > > --Bill > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > devo dot com - "Where the future is only a memory." > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
