shahid1
asked on
modify TCP/IP segment size?
How can we find out currnet TCP/IP segemnt size under WINDOWS NT, and how
we can modify the TCP/IP segment size from 536 bytes (default value) to
larger value?
thank u
shahid sardar
we can modify the TCP/IP segment size from 536 bytes (default value) to
larger value?
thank u
shahid sardar
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
In the last one you will notice that NT can try an MTU discovery, and automatically adjust
> how we can modify the TCP/IP segment size from 536 bytes
> (default value) to larger value?
Why would one want to do that?
Using "short" packets means that your computer will "task-switch" more often, thus giving more "time-slices" to each of your open windows, and thus will improve the "responsiveness" of each application, whether or not that application uses TCP/IP.
> (default value) to larger value?
Why would one want to do that?
Using "short" packets means that your computer will "task-switch" more often, thus giving more "time-slices" to each of your open windows, and thus will improve the "responsiveness" of each application, whether or not that application uses TCP/IP.
The default MTU isn't 536 bytes anyway, if the packet is for the local LAN then it uses the default for the medium http://support.microsoft.com/support/kb/articles/Q140/3/75.asp and if there's a router in the way it attempts to determine the path MTU as per http://support.microsoft.com/support/kb/articles/Q159/2/11.asp
Otta,
>> how we can modify the TCP/IP segment size from 536 bytes
>> (default value) to larger value?
>Why would one want to do that?
Surely it depends on whether multitasking or transferring lots of data fast is the goal?
Otta,
>> how we can modify the TCP/IP segment size from 536 bytes
>> (default value) to larger value?
>Why would one want to do that?
Surely it depends on whether multitasking or transferring lots of data fast is the goal?
> it depends on whether multitasking or transferring lots of data fast is the goal?
Yes.
Some web-browsers use multi-tasking to download the multiple
images on a single web-page at the same time.
So, if you watch the multiple images appearing, bit-by-bit, in parallel, more slowly,
does it seem "faster" than if the images are downloaded, serially, more quickly?
Yes.
Some web-browsers use multi-tasking to download the multiple
images on a single web-page at the same time.
So, if you watch the multiple images appearing, bit-by-bit, in parallel, more slowly,
does it seem "faster" than if the images are downloaded, serially, more quickly?
Shahid,
I can't find anywhere in your question that your interest in TCP segment size, MTU, etc. has something to do with browsers and images. Did I miss something?
First of all, TCP segment size and MTU are two different things. TCP segment size is the number of TCP bytes sent in a "single packet" transmission event outside of how many segments you can send before expecting an ACKnowledgement. You could have a 1024-byte TCP segment and a 576-byte MTU . . . not a good combo. And this wouldn't happen if your network supports Path MTU Discovery and your workstations were configured to take advantage of Path MTU discovery. Second, I believe the value you've cited is actually the MTU not the TCP/IP [sic] segment size. The MTU defaults to 576 bytes only when the (microsoft's asumption) destination IP address is on different local IP subnetwork from the sending station. This can be modified to behave differently (EnablePMTUDiscovery in the registry). But I'm afraid I'm assuming too much about your network for this type of info to be useful.
If you adjust the TCP segment size you should make your TCP send buffer an even multiple of your TCP segment size or you won't be using memory space very efficiently. If you increase the TCP send/receive buffers (microsoft lingo = TcpWindowSize) you will effect performance whether you intend to or not. My assumption is that you are looking to tune TCP for your environment. If so, you need to provide quite a bit more detail about your setup - applications, topology, current problems or issues - or you will end up getting answers about how to improve your browser performance.
Actually, NT isn't very "TCP configuration parameter" friendly. Most flavors of UNIX, on the other hand . . .
"Unix is very user friendly. It's just picky about the friends it chooses."
Good luck.
Steve
I can't find anywhere in your question that your interest in TCP segment size, MTU, etc. has something to do with browsers and images. Did I miss something?
First of all, TCP segment size and MTU are two different things. TCP segment size is the number of TCP bytes sent in a "single packet" transmission event outside of how many segments you can send before expecting an ACKnowledgement. You could have a 1024-byte TCP segment and a 576-byte MTU . . . not a good combo. And this wouldn't happen if your network supports Path MTU Discovery and your workstations were configured to take advantage of Path MTU discovery. Second, I believe the value you've cited is actually the MTU not the TCP/IP [sic] segment size. The MTU defaults to 576 bytes only when the (microsoft's asumption) destination IP address is on different local IP subnetwork from the sending station. This can be modified to behave differently (EnablePMTUDiscovery in the registry). But I'm afraid I'm assuming too much about your network for this type of info to be useful.
If you adjust the TCP segment size you should make your TCP send buffer an even multiple of your TCP segment size or you won't be using memory space very efficiently. If you increase the TCP send/receive buffers (microsoft lingo = TcpWindowSize) you will effect performance whether you intend to or not. My assumption is that you are looking to tune TCP for your environment. If so, you need to provide quite a bit more detail about your setup - applications, topology, current problems or issues - or you will end up getting answers about how to improve your browser performance.
Actually, NT isn't very "TCP configuration parameter" friendly. Most flavors of UNIX, on the other hand . . .
"Unix is very user friendly. It's just picky about the friends it chooses."
Good luck.
Steve
Go to http://www.speedguide.net/Cable_modems/cable_patches.shtml
it's got a ton of patches that tweak your registry for fastest settings. It boosted my cable connection speed by at least 25%
it's got a ton of patches that tweak your registry for fastest settings. It boosted my cable connection speed by at least 25%
Greetings.
This question remains open today; perhaps just overlooked this or it just got lost in the volumes. If you've been helped to resolve this, please accept the comment which helped you as the accepted answer to then grade and close so that others may benefit from this information as it migrates to our PAQ Database. If more is needed, please update here via comments so that you can achieve your goal.
Your attention to finalizing this is very much appreciated.
Asta
This question remains open today; perhaps just overlooked this or it just got lost in the volumes. If you've been helped to resolve this, please accept the comment which helped you as the accepted answer to then grade and close so that others may benefit from this information as it migrates to our PAQ Database. If more is needed, please update here via comments so that you can achieve your goal.
Your attention to finalizing this is very much appreciated.
Asta
Gee thanks for the "C" NOT
> "C" ...
What did you expect from this expert, given his/her history:
Last 10 Grades Given: C B C C B B B C C B
???
He/she needs to read E-E's guidelines on what a 'C' really means.
What did you expect from this expert, given his/her history:
Last 10 Grades Given: C B C C B B B C C B
???
He/she needs to read E-E's guidelines on what a 'C' really means.