[kwlug-disc] netalyzr/ispgeeks interpreting [was: Re: Reliable Broadband speed test]

[Cedric Puddy]

I can't recall what tuning opportunities exist for PIX 501's (presumably running 6.3(5) or so, if I remember the "latest" version number right).  

As an aside, we are selling 10 user ASA-5505 boxes for less than $600 these days (and there is always eBay!), and they are a drop in replacement for PIX boxes (same config language -- you just load your old config on the new box via tftp, it converts it to the new format.  You do a bit of tidy up, and you're back in the game.).  

I just double-checked icsi Netalyzer via my ASA-5505 at the office, and it's passing all the buffer warnings without any special tuning.  (There are also some little niggles, such as the out-of-the-box overly restrictive ICMP settings that it's reminding me to fix too :)

As has been remarked before, Tomato can be really cheap n' *very* easy when it comes to QoS, generally runs well.

Alternatively, a pfsense/IPCop/etc can make really full featured replacements.  I keep meaning to download and explore Vyatta as a possible software firewall, since they make so much noise about being a commercial grade alternative to Cisco and friends, and do have a freely downloadable Core edition.

(Oh, and I'd just like to say it would really make me happy if a industry consortium would make OpenVPN an across-the-board standard -- I'm really not happy about this proprietary-one-manufacturer-at-a-time thing that's going on with SSL VPN offerings these days.)


-Cedric






On 2011-03-07, at 10:52 AM, unsolicited wrote:

> Cedric Puddy wrote, On 03/07/2011 9:22 AM:
>> On 2011-03-05, at 7:51 PM, unsolicited wrote:
>>> Cedric Puddy wrote, On 03/04/2011 2:51 PM:
>>>> ispgeeks.com has a speed test that exposes more of the
>>>> underlying data from which speed estimates are typically
>>>> derived, so I usually use theirs -- it gives me enough
>>>> additional information that I can you usually get a bit better
>>>> idea of how the line is actually performing. The
>>>> http://netalyzr.icsi.berkeley.edu/ also identifies lots of interesting potential issues that could be holding up the train
>>>> on a given broadband link (including buffer-bloat).
>>> OK, that's just way cool.
>>> Interestingly: <<<<< Network buffer measurements (?): Uplink 1100
>>> ms, Downlink is good
>>> We estimate your uplink as having 1100 msec of buffering. This is
>>> quite high, and you may experience substantial disruption to your
>>> network performance when performing interactive tasks such as
>>> web-surfing while simultaneously conducting large uploads. With
>>> such a buffer, real-time applications such as games or audio chat
>>> can work quite poorly when conducting large uploads at the same
>>> time. Is this an allusion to the asynchronous nature of the (ISP)
>>> service? [8/512]. i.e. Rogers is accomplishing upload rate
>>> limiting via buffering / dropping?
>> No, this talking specifically about buffering on (probably) your
>> router.  When you go and send a stream of packets at a rate higher
>> than your connection speed, your router has two choices: a) use
>> memory (a buffer) to queue up the packets, and then flush out that
>> buffer as quickly as it can given the speed of the connection that
>> it has to send them over b) start refusing packets
>> If it does (a), then the important question is "how much data will
>> it queue up?".  If you've got a 512 kbit/sec upstream, and you go
>> and queue up 768 kbits, then it's obviously going to take more than
>> 1000 ms for it to work through that queue, assuming that no other
>> packets are attempted to be sent in the meantime etc.  Besides
>> that, unless you are running QoS, generally queues are not
>> re-ordered after the fact so once a packet tags onto the end of
>> that huge queue, then it's going to take 1+ seconds before it
>> escapes.
>> On the other hand, if the router would limit it's queue to ~100 or
>> 200 ms of data (queue some debates about the best number!), and
>> just start refusing packets (there are various algorithms to
>> determine which packets to drop), then the TCP congestion control
>> mechanisms would do their work, and you'd get a much more
>> responsive connection.
>> Check out the The Bufferbloat Project at
>> http://www.bufferbloat.net/projects/bloat/ if you are interested in
>> seeing what some of the active work on this issue looks like.
> 
> Thank you for this.
> 
> A DOH! moment. Or, more likely, connecting the dots - as to WHICH
> buffer is being referred to.
> 
> It's long been time to retire my venerable PIXie (501) - your note
> just reinforces that, however, it's getting me by for the moment.
> 
> Since myth, lmce, asterisk, egroupware, et al, all want to be top dog
> next to the ISP, I've long been intending to get around to a new box,
> which would presumably solve this issue. But the learning curve, or
> rather, curveS, makes it all a little daunting. But I recognize I'll
> have to go through the learning curve / translation to the linux-speak
> of what I already know one, hopefully LAST, time. Let alone the need
> for a new subnet, migration strategy, and so on and so forth.
> 
> So many curves, so little time ...
> 
> _______________________________________________
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org

|  CCj/ClearLine - Unix/NT Administration and TCP/IP Network Services
|  118 Louisa Street, Kitchener, Ontario, N2H 5M3, 519-489-0478
\________________________________________________________
   Cedric Puddy, IS Director            cedric at thinkers.org
     PGP Key Available at:              http://www.thinkers.org/cedric