Queuing doesn't make sense inbound anyway; once you've received the
packet, it has already consumed your bandwidth, and thus queuing won't
change anything.
queueing could delay ACK reply being sent and then whole connection
would get throttled.
it works really fine with
On Thu, 2005-10-20 at 12:23 +0200, Stanislaw Halik wrote:
Travis H. [EMAIL PROTECTED] wrote:
Queuing doesn't make sense inbound anyway; once you've received the
packet, it has already consumed your bandwidth, and thus queuing won't
change anything.
queueing could delay ACK reply being
The docs say that you can't queue on an inbound packet.
Queuing doesn't make sense inbound anyway;
once you've received the packet, it has already consumed your
bandwidth, and thus queuing won't change anything.
--
http://www.lightconsulting.com/~travis/ --
We already have enough fast, insecure
Travis H. [EMAIL PROTECTED] wrote:
Queuing doesn't make sense inbound anyway; once you've received the
packet, it has already consumed your bandwidth, and thus queuing won't
change anything.
queueing could delay ACK reply being sent and then whole connection
would get throttled.
it works
Hi
I'm sharing a connection and I'm trying to set aside bandwidth for some
users. Here is the pftop -v queue log
QUEUEBANDW SCH PRIO PKTSBYTES
DROP_P DROP_B QLEN BORROW SUSPENDS P/S B/S
std_outpriq 350
On Tue, 18 Oct 2005 10:20:25 +1000
Luke Fogarty [EMAIL PROTECTED] wrote:
#allow all traffic to and from lan
pass in on $int_if from $int_if:network to any keep state
As I said in my reply to you in misc@, when you're keeping state queue
assigment works a little bit differently.
You need to
