Borrow isn't borrowing much
Hi, Is this the right place to ask this question? Here's my pfctl -vvs queue output. I'm not doing much but trying to send as much through the 'bulk' queue as possible, but as you can see although it does borrow, it does not borrow much. (I tried turning off red on the 'std' queue and that didn't help.) I would like to get closer to 600Kb/sec but I seem to be getting only about 160Kb/sec. Is this the way it's supposed to work or am I missing something here? (Id be happy to supply pf.conf but AFIK the queue layout is all that's relevant. Some of my rules are just "pass on $if" rather than "pass in on $if", could that possibly make the outbound traffic affect the bandwidth computations borrow uses??) This is typical output, the bulk queue just does not seem to ramp up it's borrowing. (FYI, the 'throttled' queue does not serve any purpose at the moment.) queue root_dc1 bandwidth 1.28Mb priority 0 cbq( wrr root ) {throttled} [ pkts: 2826 bytes:3361143 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured:17.0 packets/s, 162.49Kb/s ] queue throttled bandwidth 1.28Mb priority 7 {std, voip} [ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.0 packets/s, 0 b/s ] queue std bandwidth 642Kb priority 6 cbq( red ) {high, defaultq, bulk} [ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.0 packets/s, 0 b/s ] queuehigh bandwidth 192.60Kb priority 6 cbq( borrow ) [ pkts:222 bytes: 12036 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 1.4 packets/s, 627.13 b/s ] queuedefaultq bandwidth 321Kb priority 5 cbq( borrow default ) [ pkts:102 bytes: 14685 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.3 packets/s, 387.43 b/s ] queuebulk bandwidth 128.40Kb priority 4 cbq( borrow ) [ pkts: 2502 bytes:3334422 dropped pkts: 0 bytes: 0 ] [ qlength: 26/ 50 borrows: 2347 suspends:132 ] [ measured:15.2 packets/s, 161.48Kb/s ] queue voip bandwidth 642Kb priority 7 cbq( borrow ) [ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.0 packets/s, 0 b/s ] Thanks. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Borrow isn't borrowing much
On 5/28/06, Karl O. Pinc <[EMAIL PROTECTED]> wrote: Is this the right place to ask this question? Yes. Is this the way it's supposed to work or am I missing something here? (Id be happy to supply pf.conf but AFIK the queue layout is all that's relevant. Some of my rules are just "pass on $if" rather than "pass in on $if", could that possibly make the outbound traffic affect the bandwidth computations borrow uses??) This is a misunderstanding based on the #1 FAQ. Queues are _only_ on outbound traffic. Queuing on inbound makes little sense, as the packets have already crossed the wire, so there's not much impact on the bottleneck (the wire) by dropping or reodering them once you've received them. Processing the packet is fast by comparison. -- Scientia Est Potentia Security "guru" for rent or hire - http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484
Re: Borrow isn't borrowing much
On 05/29/2006 04:28:49 AM, Travis H. wrote: Queues are _only_ on outbound traffic. I am queueing on outbound traffic, typing "in" was a mistake. (Actually, I'm queueing both ways, using an additional box. But that's neither here nor there when it comes to what's happening with borrowing.) Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
RE: Borrow isn't borrowing much
I found that cbq didn't borrow as aggressively as I expected. Switching to the hfsc scheduler approached closer to what I wanted. -Steve S. Karl O. Pinc wrote: > On 05/29/2006 04:28:49 AM, Travis H. wrote: >> >> Queues are _only_ on outbound traffic. > > I am queueing on outbound traffic, typing "in" was > a mistake. (Actually, I'm queueing both ways, using > an additional box. But that's neither here nor there > when it comes to what's happening with borrowing.) > > > Karl <[EMAIL PROTECTED]> > Free Software: "You don't pay back, you pay forward." > -- Robert A. Heinlein
Re: Borrow isn't borrowing much
On 05/29/2006 07:02:40 AM, Steven Surdock wrote: I found that cbq didn't borrow as aggressively as I expected. Switching to the hfsc scheduler approached closer to what I wanted. That does seem to be better, but I clearly am not getting how hfsc uses the 'bandwidth' parameter as it seems to be using more bandwidth for a sub-queue than 'bandwidth' would allow. Perhaps I should be setting "upperlimit" as well Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Borrow isn't borrowing much
On Monday, May 29, 2006, at 10:48 US/Pacific, Karl O. Pinc wrote: On 05/29/2006 07:02:40 AM, Steven Surdock wrote: I found that cbq didn't borrow as aggressively as I expected. Switching to the hfsc scheduler approached closer to what I wanted. That does seem to be better, but I clearly am not getting how hfsc uses the 'bandwidth' parameter as it seems to be using more bandwidth for a sub-queue than 'bandwidth' would allow. Perhaps I should be setting "upperlimit" as well HFSC is different enough that the "bandwidth" setting alone often doesn't make much sense. CBQ works in terms of bandwidth limits; HFSC works with bandwidth guarantees. You've got 3 options to play with: hfsc(realtime) is the minimum bandwidth for this queue. No matter what traffic comes along, a queue is guaranteed to get at least this much bandwidth. hfsc(upperlimit) is the maximum bandwidth for this queue. It will never get more than this. hfsc(linkshare) is what the "bandwidth" setting controls. It sets the weight of this queue (in relation to the others) for excess bandwidth on the interface, which is what is left over after the realtime guarantees have been satisfied for all queues. If you had 2 queues, each with a linkshare of 50% (or the equivalent bandwidth setting), and both queues were equally contending for the same bandwidth, they would each get 50% of the excess. If one queue wasn't in use at all, the other would get 100%. For a given queue, available bandwidth under HFSC is: realtime <= (excess weighted by linkshare) <= upperlimit
Re: Borrow isn't borrowing much
On 05/29/2006 10:06:32 PM, Trevor Talbot wrote: hfsc(linkshare) is what the "bandwidth" setting controls. If hfc(linkshare) and "bandwidth" are the same thing, then what happens if you specify both? Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Borrow isn't borrowing much
On Tuesday, May 30, 2006, at 08:22 US/Pacific, Karl O. Pinc wrote: On 05/29/2006 10:06:32 PM, Trevor Talbot wrote: hfsc(linkshare) is what the "bandwidth" setting controls. If hfc(linkshare) and "bandwidth" are the same thing, then what happens if you specify both? The hfsc(linkshare) value is used. Unless it's 0, in which case bandwidth is used.