Hi guys does this TCP Optimizer works ?


http://www.speedguide.net/downloads.php

 

Frankly I'm dubious on the benefits of something that look like it has very little bang for the buck.

 

Frankly I'm dubious on the benefits of something that look like it has very little bang for the buck.

Well i tried TCP Optimizer on one of my machines with win 10 just for the hack of it and i see no visible benefits, but i don't see no cons either.

 

Are you sure it is not gathering data from your system and phoning home?

 

Are you sure it is not gathering data from your system and phoning home?

How is that possible?

 

How is that possible?

Are you kidding?

 

Are you kidding?

No.nobody can get in my router including me.

 

Frankly I'm dubious on the benefits of something that look like it has very little bang for the buck.

For the general Internet use it's worthless but for local file sharing on networks adjusting the MTU, etc ... for jumbo frames might increase throughput for older windows versions on dumb ethernet hardware.
https://en.wikipedia.org/wiki/Jumbo_frame

 

No.nobody can get in my router including me.

Think about who 'me' is. 'Me' is your computer (talking to the router that sees an authorized machine) with an unknown program installed that might have direct access to your hardware. (keyboard port, memory, hard-drive, etc ...)

 

How is that possible?

What? Are you living in a bubble?

You download something, install it, and your router won't do anything to prevent it from contacting an arbitrary server.

 

For the general Internet use it's worthless but for local file sharing on networks adjusting the MTU, etc ... for jumbo frames might increase throughput for older windows versions on dumb ethernet hardware.
https://en.wikipedia.org/wiki/Jumbo_frame

The are well known problems with jumbo frames and like everything else frame size and frame handling rates are always a tradeoff.

 

The are well known problems with jumbo frames and like everything else frame size and frame handling rates are always a tradeoff.

I've used them before on NAS systems (high bandwidth streaming video RAID 60 servers that could max out a Gigabit Network Connection easily) I designed where all components were certified to pass jumbo packets. I mainly used Intel NIC's and Linux servers as routers to eliminate network incompatibility.
http://www.intel.com/support/network/sb/CS-001911.htm
http://www.adaptec.com/en-us/solutions/raid_levels.html#8

 

Snake oil.

 

I've used them before on NAS systems (high bandwidth streaming video RAID 60 servers that could max out a Gigabit Network Connection easily) I designed where all components were certified to pass jumbo packets. I mainly used Intel NIC's and Linux servers as routers to eliminate network incompatibility.
http://www.intel.com/support/network/sb/CS-001911.htm
http://www.adaptec.com/en-us/solutions/raid_levels.html#8

Also:
Jumbo frames only supported on gig interfaces.
Jumbo frames Not supported by all devices.
To get the full benefit all routers and switches between sending and receiving devices must have Jumbo frames enabled.

 

Built into TCP/IP, under the hood, is a mechanism to break large chunks of data into fragments for transmission and reassembly. The fragments do not have to arrive in order or even by the same route and number of hops. If a fragment gets lost the reassembly could take a while. Losing frames and fragments has differing effects on throughput and is one of the tradeoffs, in choosing an "optimal" packet size. In my estimation the reliability of the link and the speed of the server have greater impact on throughput from the clients perspective.

 

Also:
Jumbo frames only supported on gig interfaces.
Jumbo frames Not supported by all devices.
To get the full benefit all routers and switches between sending and receiving devices must have Jumbo frames enabled.

Been there, done that. The primary use of the system was to capture full HD satellite streams (>20mpbs) from several birds. Each orbital position had a dedicated system to capture many transponder data streams, decrypt them in software while indexing a database and storage on the main NAS server. The HD video files on the server were then streamed to many client display computers with full video manipulation capability in real-time. No, it wasn't for any agency but the people who used it would not like to be known.

 

Built into TCP/IP, under the hood, is a mechanism to break large chunks of data into fragments for transmission and reassembly. The fragments do not have to arrive in order or even by the same route and number of hops. If a fragment gets lost the reassembly could take a while. Losing frames and fragments has differing effects on throughput and is one of the tradeoffs, in choosing an "optimal" packet size. In my estimation the reliability of the link and the speed of the server have greater impact on throughput from the clients perspective.

Very true but we wanted to eliminate every bottleneck.

In my case we optimized the data blocks on the disk (using the XFS or ZFS file system), the controllers, the Linux disk buffer and the NIC drivers to eliminate fragmentation by adapter teaming dual NIC boards with dual gateway routing tables for redundant data paths. When running full bore every activity light was full on non-stop but that was in a local area network, any remote connection like a Internet connection had limited speed access.

https://en.wikipedia.org/wiki/XFS

If you run Linux and need speed for large multi-media files XFS is the way to go. I still use it for most file systems at home.

# /dev/sdb1  /sdb  xfs  defaults,nobarrier  0  0
UUID=c6c89f1a-2fd5-4991-9614-0df23332e8e0  /sdb  xfs  defaults,nobarrier  0  0
# /dev/sdc1  /sdc  xfs  defaults,nobarrier  0  0
UUID=c9b78823-88af-403f-b611-947b69ebef48  /sdc  ext4  defaults  0  2
# /dev/sdd1  /sdd  xfs  defaults,nobarrier  0  0
UUID=f9c22803-9ede-4d4b-93fa-988168477cf5  /sdd  xfs  defaults,nobarrier  0  0
# /dev/sde1  /sde  xfs  defaults,nobarrier  0  0
UUID=fe889b62-8ada-4d98-bc55-f378df2cf1d8  /sde  xfs  defaults,nobarrier  0  0
#/dev/sda1  /sda  xfs  defaults,nobarrier  0  0
UUID=bb4285e8-ebec-42a6-82e4-538456e6eef0  /sda  xfs  defaults,nobarrier  0  0
UUID=f57bed72-fd54-4a84-992d-474f8c989468  /sdf  xfs  defaults,nobarrier  0  0

 

Very true but we wanted to eliminate every bottleneck.

In my case we optimized the data blocks on the disk (using the XFS or ZFS file system), the controllers, the Linux disk buffer and the NIC drivers to eliminate fragmentation by adapter teaming dual NIC boards with dual gateway routing tables for redundant data paths. When running full bore every activity light was full on non-stop but that was in a local area network, any remote connection like a Internet connection had limited speed access.

Not sure of the relevance of the fstab in post #17 other than to show file system type.
What was the resultant network throughput? Frame size?

 

Not sure of the relevance of the fstab in post #17 other than to show file system type.
What was the resultant network throughput? Frame size?

Only to show that I still use the file system for cases where video streaming is important. (8 cameras with 3MP ipcams on the home system)

xfs_info /dev/sdf3
meta-data=/dev/sdf3 isize=256 agcount=4, agsize=169958016 blks
= sectsz=512 attr=2, projid32bit=0
= crc=0 finobt=0 spinodes=0
data = bsize=4096 blocks=679832064, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=0
log =internal bsize=4096 blocks=331949, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0

I can't remember what the benchmarks were at standard 9000 byte MTU jumbo frames on back to back loop testing for different block sizes and configurations. I had the data using mrtg and iptraf but it's long gone now.

 

The current home switch (10K Jumbo frame capability) is this so yes the network can handle jumbo frames.
http://www.tp-link.com/en/products/details/cat-42_TL-SG1024D.html