extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-12-25 07:38:57 +01:00
Code Issues Packages Projects Releases Wiki Activity

Resolve conflict

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3079 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2005-11-27 01:18:10 +00:00
parent 37f238c36a
commit d7365302a5
1 changed files with 1 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
Shorewall-docs2/traffic_shaping.xml
View File

@ -99,12 +99,7 @@
the packets were already received by your network card before you can 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 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 which normally makes no sense (since you received the packet already, it
went through the possible bottleneck (the incoming connection); dropping went through the possible bottleneck (the incoming connection). The next
packets <emphasis>does</emphasis> 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
<filename>/etc/shorewall/tcdevices</filename> file below). The next
possible bottleneck might come if the packet leaves on another interface, possible bottleneck might come if the packet leaves on another interface,
so this will be the place where queuing might occur. So, defining queues 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 for incoming packets is not very useful, you just want to have it