dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
5
share rss forum feed


DrDrew
That others may surf
Premium
join:2009-01-28
SoCal
kudos:15

1 edit

1 recommendation

reply to ikyuaoki

Re: [ALL] workaround for over limit of cap line issues

Disabling the TCP Nagle Algorithm can make the connection less efficient by increasing the number of packets send over a network. The Nagle algorithm groups small bits of info into a packet with one header vs. lots of small bits each with their own header. In other words, disabling it creates more overhead for the same amount of data. Read more here:
»en.wikipedia.org/wiki/Nagle%27s_algorithm

Reducing TCP windows settings usually causes more ACK packets to be sent because the amount of received but unacknowledged data allowed is reduced.... in other words more overhead is created because the receiver has to indicate they received it more often, for the same amount of total data. Besides creating more overhead, it often slows down the connection since the sender is waiting more often for permission to send more data.
»en.wikipedia.org/wiki/TCP_window···e_option

Doing both can create a "Silly window" problem where there is more header packet data, then actual data, i.e. more overhead then real data.
»en.wikipedia.org/wiki/Silly_window_syndrome

Producing more overhead for the same amount of real data results in more overall data consumed.... getting you closer to bandwidth cap.
--
If it's important, back it up... twice. Even 99.999% availability isn't enough sometimes.



ikyuaoki

join:2011-04-12
Wichita, KS
Reviews:
·Cox HSI

With TCP disabled nagle, i gets lower latency where i am gaming, however that disabled TCP nagle does not produced any inefficient issues for me. silly window problem is not happening anymore where i did tested with disabled TCP window settings that i was getting around 20Mbits downstream that does not affected me at all.

EDIT: that suggestion thread is for who can't afford to have second line and on the limited of capped.



DrDrew
That others may surf
Premium
join:2009-01-28
SoCal
kudos:15

said by ikyuaoki:

With TCP disabled nagle, i gets lower latency where i am gaming, however that disabled TCP nagle does not produced any inefficient issues for me. silly window problem is not happening anymore where i did tested with disabled TCP window settings that i was getting around 20Mbits downstream that does not affected me at all.

Latency and download speed are separate from bandwidth used. Telling us your latency in the game is better and your apparent speeds have changed, doesn't tell us the actual bandwidth used changed.

Since you've done it, have you actually measured bandwidth used before and after for long periods of time? Especially telling would be numbers on the percentage of overhead before and after.

Unless you get several percentage points in bandwidth savings and you're running right up to the limit, this won't make any difference.

BTW, what do you mean exactly by "disabled TCP window settings"? TCP window settings are a set size or set to auto/OS controlled. A setting of "disabled" doesn't make sense. What does a current "tweak" test show? Can you post a screenshot?
--
If it's important, back it up... twice. Even 99.999% availability isn't enough sometimes.


ikyuaoki

join:2011-04-12
Wichita, KS
Reviews:
·Cox HSI

said by DrDrew:

said by ikyuaoki:

With TCP disabled nagle, i gets lower latency where i am gaming, however that disabled TCP nagle does not produced any inefficient issues for me. silly window problem is not happening anymore where i did tested with disabled TCP window settings that i was getting around 20Mbits downstream that does not affected me at all.

BTW, what do you mean exactly by "disabled TCP window settings"? TCP window settings are a set size or set to auto/OS controlled. A setting of "disabled" doesn't make sense. What does a current "tweak" test show? Can you post a screenshot?

that TCP window settings is autotuninglevel set that found in the netsh command sets in windows vista, 7 and 8

that netsh context tcp settings lists below here.

autotuninglevel - One of the following values:
disabled: Fix the receive window at its default
value.
highlyrestricted: Allow the receive window to
grow beyond its default value, but do so
very conservatively.
restricted: Allow the receive window to grow
beyond its default value, but limit such
growth in some scenarios.
normal: Allow the receive window to grow to
accomodate almost all scenarios.
experimental: Allow the receive window to grow
to accomodate extreme scenarios.


DrDrew
That others may surf
Premium
join:2009-01-28
SoCal
kudos:15

So what is the fixed TCP receive window size you are running at?

Seems your download speed dropped 8 Mbps when you turned off autotuning TCP window settings.

That still doesn't answer the question amount of bandwidth used. The whole premise of this thread was that you said changing these settings LOWERED a persons bandwidth usage.
--
If it's important, back it up... twice. Even 99.999% availability isn't enough sometimes.



ikyuaoki

join:2011-04-12
Wichita, KS
Reviews:
·Cox HSI

yes what i said that changing to a slower speeds custom settings from the windows default settings would lower the bandwidth rate and that may be able to reduces the meter count on clocks.

the two words are different that is not same things.

1. bandwidth is how much measures in Mbits datarate what you are gets.

2. meter count on clocks is how much you used in data consumed each month.



ikyuaoki

join:2011-04-12
Wichita, KS
Reviews:
·Cox HSI
reply to DrDrew

said by DrDrew:

So what is the fixed TCP receive window size you are running at?

That i am running mostly normal TCP window settings where that default normal set is up to 16MB window buffers.

EDIT: additional, I was in the WOW game online that i gets latency is around 60ms where the nagle is disabled (i set the nagle to be disabled peramently)


DrDrew
That others may surf
Premium
join:2009-01-28
SoCal
kudos:15

1 edit
reply to ikyuaoki

Reducing a users speed doesn't mean they will reduce their data usage.

Example 1: Someone who watches Netflix 4 hours a day will transfer the same amount of data at 36 Mbps as they would at 28 Mpbs, if overhead is the same. Netflix streaming bandwidth doesn't use data as fast as either connection is capable of, so the user wouldn't see any difference.

Example 2: A user downloading 50 movies at 1.5 GB each will still transfer at least 75 GB of data at 36 Mbps as they will at 28 Mbps, if overhead is the same, but it will just take longer at the slower rate.

Your suggestions make the connection less efficient, it doesn't reduce the amount of data the user transfers.

I can see how disabling the Nagle Algorithm setting can change the average latency for small packet based connections (less waiting to fill bigger packets), but it doesn't reduce data transferred. With more packets and packet headers, it would actually increase total data transfered.

To really reduce the amount of data transferred, users have to change what they're downloading and uploading. Playing tricks with protocol options leads to minor changes in data transferred, usually leading to increases due to more overhead.

--
If it's important, back it up... twice. Even 99.999% availability isn't enough sometimes.



azchrisf8657

@cox.net

said by DrDrew:

Reducing a users speed doesn't mean they will reduce their data usage.

Example 1: Someone who watches Netflix 4 hours a day will transfer the same amount of data at 36 Mbps as they would at 28 Mpbs, if overhead is the same. Netflix streaming bandwidth doesn't use data as fast as either connection is capable of, so the user wouldn't see any difference.

Example 2: A user downloading 50 movies at 1.5 GB each will still transfer at least 75 GB of data at 36 Mbps as they will at 28 Mbps, if overhead is the same, but it will just take longer at the slower rate.

Your suggestions make the connection less efficient, it doesn't reduce the amount of data the user transfers.

I can see how disabling the Nagle Algorithm setting can change the average latency for small packet based connections (less waiting to fill bigger packets), but it doesn't reduce data transferred. With more packets and packet headers, it would actually increase total data transfered.

To really reduce the amount of data transferred, users have to change what they're downloading and uploading. Playing tricks with protocol options leads to minor changes in data transferred, usually leading to increases due to more overhead.

Exactly.