On Fri, 2009-11-13 at 07:45 -0600, Mike wrote: > If it would run on say a MT 450G, and > the price was right, you'd sell a bunch! I'd buy several for my network.
After installing this on an RB600 moving about 4k pps I saw it move CPU from an average of about 60% up to about 80-100% (more often 100 than 80). On an RB1000, moving about 8k pps, we went from about 30% to an average of about 60%. I guess the point is, it just depends on how many users and how many packets you'd be moving through. I would be comfortable installing this on an rb450G with 3-500 users and up to about 3k pps (maybe more, but not much more). Does that help? > An agnostic approach to bandwidth management is MY preferred way to > deal with network congestion. If the pipe is getting clogged, look > for long duration threads and delay those packets in deference to > those short duration network transactions. Let the web pages load > fast, let users retrieve email fast, but if there is congestion, take > the headroom away from the bandwidth hogs until the congestion frees up. That's exactly what this system does. It just looks for what appears to be "non-interactive" traffic and moves it toward the bottom of the priority chain. It does NOT set speed limits on anything. It is just a priority scheduler that is much more intelligent than anything I've seen done in Mikrotik. > We currently have such a device running on our network that has made > a dramatic difference in the dynamics of how our network > operates. The device already exists. It's called a > NetEqualizer. There are a couple things about the NetEq your OS will > no doubt fix and add value to a net op. One thing that is a HUGE difference is that I can do nearly everything the NetEq does, for a FRACTION of the cost. This system, for what it's worth, is available for $175 installed on your hardware. > The second place your OS would correct a shortcoming of NetEq is > again moving it away from the core. At the core, every connection > from a separate subnet, say from a distant tower deployment will look > like they come from a single IP instead of from the many who might be > using the tower. NetEq will still identify each thread as unique, > UNLESS multiple users happen to be connected to the same distant IP > address like Google, or MSN, or others. If the appliance were to be > moved to the remote tower site, it could do its own "agnostic" > conditioning of bandwidth BEFORE it gets on the backbone. FWIW, traffic is not classified by IP. It is classified by connection. I use PCQ in my system, however, so the "equalization" technique would segment traffic in the queues by IP. This is something that could be overcome, if we changed to something like RED queues (which is designed to follow/track individual "flows" instead of equally managing IP addresses), but I am convinced that PCQ is the best approach to what I am trying to accomplish with this system. > So Butch, if there is good value in the system; its affordable, and > will run on affordable hardware, and works well, count me in for > several of them. As I said, I think at $175, it is very affordable considering what it does. -- ******************************************************************** * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/ * Network Engineering * * http://www.wispa.org/ * Wired or Wireless Networks * * http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE! * ******************************************************************** -------------------------------------------------------------------------------- WISPA Wants You! Join today! http://signup.wispa.org/ -------------------------------------------------------------------------------- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
