On 31/03/13 21:37, Alan McKay wrote: > On Sun, Mar 31, 2013 at 4:21 PM, Tom Eastep <teas...@shorewall.net> wrote: >> Changing the OUTGOING configuration isn't going to do anything. If you >> have specified an IN-BANDWIDTH, get rid of it; do you have normal download >> speed then? > Duh, so simple! Yeah, that seems to have done the trick ... thanks! > > > -- > “Don't eat anything you've ever seen advertised on TV” > - Michael Pollan, author of "In Defense of Food" > > ------------------------------------------------------------------------------ > Own the Future-Intel(R) Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. Compete > for recognition, cash, and the chance to get your game on Steam. > $5K grand prize plus 10 genre and skill prizes. Submit your demo > by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users If you do want that on suggest you try it either using either burst or rate estimation for example on the 80mbps line at home in the past I've used:
~75mbit:500ms:8sec That's with rate estimation, which in my experience works better the problem is without burst the kernel I believe will only let through at most 1 packet each time it ticks and usually has a frequency of I think around 1,000Hz or something like that 1,000 packets per sec is insufficient for high bandwidth lines, max 1,500b (12,000bit) per packet 12,000*1,000=12,000,000 (12mbit) assuming all packets are full to mtu real world would be lower. That said I see little point to dropping arbitrarily like this on the inbound, I now use an IFB so I can selectively drop when the line is running near max that way typically I avoid dropping UDP as it seems pointless will have no effect on the rate anyway, instead opting to drop a low priority TCP packet and let TCP congestion control handle reducing the rate thus hopefully eliminating quing latency or worse random dropping at the ISP end of the choke point. You don't have the same kind of control you do on upload either way but it does help reduce the chances of more important services being adversely affected by say P2P, this could help prevent a large download via P2P or HTTP for example causing your VOIP to suffer high latency, jitter or packet drops all of which are bad. In my case I do it this way in particular for the benefit of the public NTP server here, NTP is far more accurate on stable connections with latency and jitter as low as possible similar to VOIP connections.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
