[c-nsp] Cisco 2811 performance issue - dual(new) isp

harbor235 harbor235 at gmail.com
Mon Dec 19 22:34:40 EST 2011


Vinny,

I agree, now that I think about it, it would not be compression but my *NIX
box does support
auto scaling, that has be available for some time. I also am familiar with
stack tuning and have done
so on my box. However, most modern stacks do not require as much as the old
days, again, I agree.
I am curious what the optimizer really does?

Perhaps it is increasing the tcp/udp send and receive buffers to achieve
the desired results for the test. I do remember
that I also did not get the results they stated unless I used their speed
test tool. I just ran the test again
and on my 25/25 I received 2/2. Verizon optimizer is only availble for

Guess I will have to grab a packet capture and find out what really is
going on. I just never received the results they indicated
I would receive.

Ha!!, found this:

*What does the Broadband Tuner do exactly?*

The installer increases the default values for the size of the TCP send and
receive buffers. With larger buffers more data can be in transit at once. A
startup configuration file is also updated so that these changes will
persist across restarts.

The system parameters are sysctl variables that are set as follows:
net.inet.tcp.sendspace: 131072
net.inet.tcp.recvspace: 358400
kern.ipc.maxsockbuf: 512000

This change has a system wide effect and is applied even if the network is
not high speed connection with a high latency, with the exception of modem
connections for which the system uses small default TCP buffer sizes.

thanx,

Mike




On Mon, Dec 19, 2011 at 5:21 PM, Vinny Abello <vinny at abellohome.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mike,
>
> I don't believe Verizon FiOS uses compression. Neither would the Windows
> machine plugged directly into the hand off, so it would not compress or
> decompress data in communicating with Verizon's hardware. Compression of an
> entire link is CPU intensive and doesn't scale well, especially at higher
> speeds. I think it would be much much easier for Verizon to provide more
> bandwidth than to provide more hardware with faster CPU's to aggregate all
> the customers. Compression can take place between web servers and web
> browsers, but that has nothing to do with the ISP's speed.
>
> The Verizon speed optimizer turns on TCP 1323 extensions, adjusts the TCP
> receive window and adjusts the MTU to 1492. None of these things involve
> compression. Most of them involve enabling settings in the operating system
> (which should be on by default in newer versions of Windows) to take
> advantage of the size of the pipe. They are also transparent to routers in
> the middle (except the MTU) including the 2811. I think the optimizer is
> mostly for older versions of Windows. I'm suspecting you are seeing slow
> throughput on your *nix box because it may not have 1323 extensions enabled
> to support window scaling and selective acknowledgements... or perhaps you
> just have a simple duplex mismatch somewhere. It's very difficult to scale
> the bandwidth without these things especially when latency is introduced.
> You might want to look into seeing if a sysctl or similar knob can turn
> them on and try again. All the recent *nix OS's I have seem to have this
> enabled already by default.
>
> The last thing I heard about ISP's and compression was from years ago
> using that Propel software which was for dial-up and slower broadband
> connections. The compression was lossy though and would decrease the
> quality of most images. If I remember correctly, there are speed tests out
> there that will run with highly compressible vs uncompressible data for
> contrast just to verify. I'm sure there could be some oddball compression
> things being done out there by some ISPs, but Verizon FiOS isn't one of
> them based on all the information I've come across over the years since
> I've followed their roll out.
>
> On the topic of the 2811, what features are enabled? This can have a huge
> impact on throughput. With just straight IP routing and firewall features
> enabled, I used to get 40 to 50Mbps out of an 1841 without any problems.
> This was of course maximizing the MTU size to achieve this. IPS features
> usually drag the speed down quite a bit as do a lot of types of protocol
> inspection. It's all about PPS rather than Mbps. The closer to the MTU the
> packet size is, the higher throughput you'll achieve. 5000 pps @64 bytes vs
> 5000 pps @1500 bytes is pretty much the same to the router for just packet
> forwarding, but the difference is 320Kbps vs 7.5Mbps when it comes to
> throughput.
>
> - -Vinny
>
> On 12/19/2011 1:21 PM, harbor235 wrote:
> > The provider is using compression to get you the 50/5 number. The 2811
> > represents the true bandwidth allocation.
> >
> > Did they ask you to go to a provider site to optimize your laptop?
> > Verizon did that to me, they told me I have 25 symteric although
> > I only get 8 symetric when I use my *NIX box to validate.
> >
> > Mike
> >
> > On Mon, Dec 19, 2011 at 1:06 PM, Adam Atkinson <ghira at mistral.co.uk>
> wrote:
> >
> >> I saw a 2811 flattened recently by MTU / MSS issues, so
> >> would be curious to see "show ip traffic"
> >>
> >> ______________________________**_________________
> >> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> >> https://puck.nether.net/**mailman/listinfo/cisco-nsp<
> https://puck.nether.net/mailman/listinfo/cisco-nsp>
> >> archive at http://puck.nether.net/**pipermail/cisco-nsp/<
> http://puck.nether.net/pipermail/cisco-nsp/>
> >>
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (MingW32)
>
> iEYEARECAAYFAk7vuPYACgkQUyX7ywEAl3paKwCdFs3mqyXPmwruJHz5M3yGZiM4
> Z9QAnipmc8mERRuBJ41wzYZNfJjj/CzP
> =w69e
> -----END PGP SIGNATURE-----
>


More information about the cisco-nsp mailing list