RE: altq priq Anomaly?
Amir S Mesry wrote:
> Interesting issue, I have't encountered it. 3MB Down/384KB Up.
>
> altq on $eth0 priq bandwidth 325Kb queue { q_pri, q_def }
> queue q_pri priority 7
> queue q_def priority 1 priq(default
>
> What program are you using to measure it?
Please see my original post... FTP.
RE: altq priq Anomaly?
Stefan Zill wrote: > Jon Hart wrote: > > On Thu, Jun 23, 2005 at 07:39:41AM -0400, Melameth, Daniel D. wrote: > > > The TCP ACKs are not the issue. The issue is I never get more > > > than half of what I set the bandwidth value to. > > > > I've never been able to get exactly the bandwidth I specified in my > > pf.conf altq rules. > > I almost always get, what I specify in the altq-definitions. Yet, > Once I had such an issue. I ran some kind of local proxy, which > connected from my (tun0) to (tun0) and later this data left through > tun0 on a different connection. The first connection, although not > physically passing through the external interface, consumed > altq-bandwidth. Maybe you have a similiar kind of issue, such that > your traffic passes through altq twice. I removed my problem by > simply using (lo0) to (lo0) connections, instead of (tun0) to (tun0). > Maybe this behaviour can be considered a bug, maybe it can be removed > by using better pf-rules. No proxy is in place, but I might look into this further... or maybe it's a bug.
RE: altq priq Anomaly?
Interesting issue, I have't encountered it. 3MB Down/384KB Up.
altq on $eth0 priq bandwidth 325Kb queue { q_pri, q_def }
queue q_pri priority 7
queue q_def priority 1 priq(default
What program are you using to measure it?
Amir Mesry
[EMAIL PROTECTED]
Cadillac Jack, Inc.
http://www.cadillacjack.com/
Network & Systems Administrator
2420 Meadowbrook Parkway
Duluth, GA 30096
770-865-0034
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Melameth, Daniel D.
Sent: Thursday, June 23, 2005 7:40 AM
To: pf@benzedrine.cx
Subject: RE: altq priq Anomaly?
Ingolf Zeiner Petersen wrote:
> Melameth, Daniel D. wrote:
> > > I implemented altq's priq a while back in the hope of "speeding
> > > up" my overall 'net connection by prioritizing empty TCP ACKs.
> > > However, I noticed that I was never coming close to my 256Kb/s
> > > upload cap since I did this and looked into it a little bit
> > > further today.
> I don't know if you've got ADSL, but for my own case I got 1024/256
> ADSL, and I have actually set the up-limit to 180Kbit/s to get useful
> latency-rates (together with priq queues). Because empty TCP ACKs is
> much about how fast the packets get sent to the destination - this
> becomes relevant.
>
> Try it, and tell us about your result! :-)
The TCP ACKs are not the issue. The issue is I never get more than half
of what I set the bandwidth value to.
RE: altq priq Anomaly?
Jon Hart wrote: > On Thu, Jun 23, 2005 at 07:39:41AM -0400, Melameth, Daniel D. wrote: > > The TCP ACKs are not the issue. The issue is I never get more than > > half of what I set the bandwidth value to. > > I've never been able to get exactly the bandwidth I specified in my > pf.conf altq rules. In trying to figure out what bandwidth > specification in pf.conf would give me the rate I pay for, it really > is about 2x. At home I've got 6M down, 768K up. My altq definitions > specify 12M down and 1.5M up and everything works fine. Well, I guess I'm glad I'm not the only one having the issue. I might file a PR.
Re: altq priq Anomaly?
Jon Hart wrote: On Thu, Jun 23, 2005 at 07:39:41AM -0400, Melameth, Daniel D. wrote: The TCP ACKs are not the issue. The issue is I never get more than half of what I set the bandwidth value to. I've never been able to get exactly the bandwidth I specified in my pf.conf altq rules. I almost always get, what I specify in the altq-definitions. Yet, Once I had such an issue. I ran some kind of local proxy, which connected from my (tun0) to (tun0) and later this data left through tun0 on a different connection. The first connection, although not physically passing through the external interface, consumed altq-bandwidth. Maybe you have a similiar kind of issue, such that your traffic passes through altq twice. I removed my problem by simply using (lo0) to (lo0) connections, instead of (tun0) to (tun0). Maybe this behaviour can be considered a bug, maybe it can be removed by using better pf-rules. HTH Stefan
Re: altq priq Anomaly?
On Thu, Jun 23, 2005 at 07:39:41AM -0400, Melameth, Daniel D. wrote: > The TCP ACKs are not the issue. The issue is I never get more than half > of what I set the bandwidth value to. I've never been able to get exactly the bandwidth I specified in my pf.conf altq rules. In trying to figure out what bandwidth specification in pf.conf would give me the rate I pay for, it really is about 2x. At home I've got 6M down, 768K up. My altq definitions specify 12M down and 1.5M up and everything works fine. -jon
RE: altq priq Anomaly?
Ingolf Zeiner Petersen wrote: > Melameth, Daniel D. wrote: > > > I implemented altq's priq a while back in the hope of "speeding > > > up" my overall 'net connection by prioritizing empty TCP ACKs. > > > However, I noticed that I was never coming close to my 256Kb/s > > > upload cap since I did this and looked into it a little bit > > > further today. > I don't know if you've got ADSL, but for my own case I got 1024/256 > ADSL, and I have actually set the up-limit to 180Kbit/s to get useful > latency-rates (together with priq queues). Because empty TCP ACKs is > much about how fast the packets get sent to the destination - this > becomes relevant. > > Try it, and tell us about your result! :-) The TCP ACKs are not the issue. The issue is I never get more than half of what I set the bandwidth value to.
Re: obsd install sets
Qv6([EMAIL PROTECTED])@2005.06.22 22:57:47 -0500: > I'm new to obsd and I trying to learn what the different install sets > are. For example, what are the implications of installing comp37.tgz, > or xhare37.tgz, etc. > wrong list, subscribe to [EMAIL PROTECTED] > A link will do fine. BTW, I have googled to no avail. > simply reading the FAQ would have done the job - no need for google: http://openbsd.org/faq/faq4.html#FilesNeeded at least it tells you what the file sets are for. regards teemu -- "Every man takes the limits of his own field of vision for the limits of the world." - Schopenhauer pgpxMIYBFTUkN.pgp Description: PGP signature
Re: altq priq Anomaly?
Melameth, Daniel D. wrote: I implemented altq's priq a while back in the hope of "speeding up" my overall 'net connection by prioritizing empty TCP ACKs. However, I noticed that I was never coming close to my 256Kb/s upload cap since I did this and looked into it a little bit further today. I don't know if you've got ADSL, but for my own case I got 1024/256 ADSL, and I have actually set the up-limit to 180Kbit/s to get useful latency-rates (together with priq queues). Because empty TCP ACKs is much about how fast the packets get sent to the destination - this becomes relevant. Try it, and tell us about your result! :-)
RE: altq priq Anomaly?
I sent this email back in March when I was running 3.5 and didn't look
into this further because this was an older release--but now I'm running
3.7 and I have the same issue. Any ideas? No one on misc@ seems to...
Melameth, Daniel D. wrote:
> I sent something similar to this to misc@ with nary a response so I
> hope someone on this specialized list can shed some light on this...
>
>
> I implemented altq's priq a while back in the hope of "speeding up" my
> overall 'net connection by prioritizing empty TCP ACKs. However, I
> noticed that I was never coming close to my 256Kb/s upload cap since I
> did this and looked into it a little bit further today.
>
>
> It appears an expected bandwidth value for altq in this scenario:
>
> altq on $ext_if priq bandwidth 240Kb queue { tcp_ack, default }
>
> ..limits my upload speed to about half (128Kb/s) of what I should get
> and doubling this value:
>
> altq on $ext_if priq bandwidth 480Kb queue { tcp_ack, default }
>
> ..gives me my 256Kb/s back.
>
> Details below... Any thoughts appreciated.
>
>
> $ uname -mrsv
> OpenBSD 3.5 GENERIC#34 i386
>
> Snippet from my normal pf.conf:
>
> altq on $ext_if priq bandwidth 240Kb queue { tcp_ack, default }
> queue tcp_ack priority 7
> queue default priority 1 priq ( default )
> ..
> nat on $ext_if from $int_if:network to ! $modem -> ( $ext_if:0 )
> nat on $ext_if from $int_if:network to $modem -> $ext_alias
> ..
> pass in quick on $ext_if inet proto tcp from ! $int_if:network to
> \ ( $ext_if:0 ) port ssh flags S/SA keep state queue (
> default,
> tcp_ack )
> ..
> pass out quick on $ext_if inet proto tcp to any flags S/SA \
> keep state queue ( default, tcp_ack )
>
> Output of pfctl -vvs queue during a large FTP upload:
>
> $ sudo pfctl -vvs queue
> queue tcp_ack priority 7
> [ pkts: 5 bytes:270 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 0/ 50 ]
> queue default priq( default )
> [ pkts:862 bytes: 754536 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 9/ 50 ]
>
> queue tcp_ack priority 7
> [ pkts: 5 bytes:270 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 0/ 50 ]
> [ measured: 0.0 packets/s, 0 b/s ]
> queue default priq( default )
> [ pkts:952 bytes: 827452 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 11/ 50 ]
> [ measured:18.0 packets/s, 116.67Kb/s ]
>
> queue tcp_ack priority 7
> [ pkts: 8 bytes:432 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 0/ 50 ]
> [ measured: 0.3 packets/s, 129.60 b/s ]
> queue default priq( default )
> [ pkts: 1052 bytes: 907197 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 10/ 50 ]
> [ measured:19.0 packets/s, 122.13Kb/s ]
>
>
> Simply updating my pf.conf with:
>
> altq on $ext_if priq bandwidth 480Kb queue { tcp_ack, default }
>
> ..and reloading my rules with:
>
> $ sudo pfctl -f /etc/pf.conf
>
> ..during the current same FTP upload process gives:
>
> $ sudo pfctl -vvs queue
> queue tcp_ack priority 7
> [ pkts: 0 bytes: 0 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 0/ 50 ]
> queue default priq( default )
> [ pkts: 53 bytes: 54598 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 7/ 50 ]
>
> queue tcp_ack priority 7
> [ pkts: 0 bytes: 0 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 0/ 50 ]
> [ measured: 0.0 packets/s, 0 b/s ]
> queue default priq( default )
> [ pkts:233 bytes: 212130 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 5/ 50 ]
> [ measured:36.0 packets/s, 252.05Kb/s ]
>
> queue tcp_ack priority 7
> [ pkts: 3 bytes:162 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 0/ 50 ]
> [ measured: 0.3 packets/s, 129.60 b/s ]
> queue default priq( default )
> [ pkts:410 bytes: 369754 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 2/ 50 ]
> [ measured:35.7 packets/s, 252.12Kb/s ]
>
>
> So what's going on? Why is the first altq statement not allowing me
> to get close to my maximum (when there is mostly nothing in the higher
> priority queue)?
obsd install sets
I'm new to obsd and I trying to learn what the different install sets are. For example, what are the implications of installing comp37.tgz, or xhare37.tgz, etc. A link will do fine. BTW, I have googled to no avail. TIA
pf for my little world.
I'm getting closer.
This is what I think I want. Is there a problem with it?
---
# macros
int_if = "rl0"
ext_if = "ne1"
tcp_services = "{ 22, 113 }"
bad_services = "{ 137, 138, 139, 445 }"
icmp_types = "echoreq"
table const \
{ 127/8, 10/8, 172.16/12, 192.168/16, !192.168.0/24 }
# options
set block-policy return
set loginterface $ext_if
# scrub
scrub in all
# nat/rdr
nat on $ext_if from $int_if:network to any -> $ext_if
rdr on $int_if proto tcp from any to any port 21 -> 127.0.0.1 \
port 8021
# filter rules
block all
pass quick on lo0 all
block drop in quick on $ext_if from
block drop quick on $ext_if port $bad_services
pass in on $ext_if inet proto tcp from any to $ext_if \
port $tcp_services flags S/SA keep state
pass in on $ext_if inet proto tcp from port 20 to $ext_if \
user proxy flags S/SA keep state
pass in inet proto icmp all icmp-type $icmp_types keep state
pass in on $int_if from $int_if:network to any keep state
pass out on $int_if from any to $int_if:network keep state
pass out on $ext_if proto tcp all modulate state flags S/SA
pass out on $ext_if proto { udp, icmp } all keep state
--
Don't knock President Fillmore. He kept us out of Vietnam.
