From d7365302a56c20b95e8415e608b2b0dfada27a51 Mon Sep 17 00:00:00 2001 From: teastep Date: Sun, 27 Nov 2005 01:18:10 +0000 Subject: [PATCH] Resolve conflict git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3079 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-docs2/traffic_shaping.xml | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/Shorewall-docs2/traffic_shaping.xml b/Shorewall-docs2/traffic_shaping.xml index b3a33ee3c..645e6e5be 100644 --- a/Shorewall-docs2/traffic_shaping.xml +++ b/Shorewall-docs2/traffic_shaping.xml @@ -99,12 +99,7 @@ the packets were already received by your network card before you can decide what to do with them. So the only choice would be to drop them which normally makes no sense (since you received the packet already, it - went through the possible bottleneck (the incoming connection); dropping - packets does have an advantage when you are connected - to the internet using a Cable Modem or DSL because it can prevent large - queues of download traffic from forming at your ISP and thus can improve - response time (see the definition of the IN-BANDWIDTH column of the - /etc/shorewall/tcdevices file below). The next + went through the possible bottleneck (the incoming connection). The next possible bottleneck might come if the packet leaves on another interface, so this will be the place where queuing might occur. So, defining queues for incoming packets is not very useful, you just want to have it