On Thu, 2009-11-12 at 10:40 -0800, Joe Miller wrote: > Make it a plug-n-play for us non Mikrotik people and I would say "sold".
DONE! LOL. I don't sell a "script". I sell the installation of a system, which will include installation, configuration, customization (to an extent) and basic instruction and troubleshooting "guide". This system is very complex and not a simple "plug and play" type approach. I promise to make it easy on you, as a customer, though. :-) > ----- Original Message ---- > From: Butch Evans <[email protected]> > To: WISPA General List <[email protected]> > Sent: Thu, November 12, 2009 11:39:20 AM > Subject: Re: [WISPA] Netflix, Hula starting to creat issues with network. > > On Thu, 2009-11-12 at 10:54 -0500, [email protected] wrote: > > I looked at http://www.mikrotik.com/download/l7-protos.rsc but didnt find > > anything existing for L7 and netflix. Does anyone have one they are using? > > I don't think one exists. It's one reason I'm working on the "smart > QOS" system. It will react even when we encounter an "unknown" > protocol/service. I've been "packet sniffing" all morning looking for > various streaming services. Currently, I can accurately detect youtube > (and all other similar services), Hulu (a very easy one) and a few > others. I did a test just a few minutes ago with my current > implementation. Here's how it worked: > > 1. Set my bandwidth to 1M download speed ("total_down_speed") > 2. Guarantee speed of 768k for "primary" or "normal" traffic queues > 3. Guarantee speed of 256k for "secondary" or "bad" traffic queues > 4. Priority queues within each of those (priority1-priority8) > 5. mangle rules do the following: > a. Set http to prio1_normal > b. watch http traffic for "large downloads" or streams > c. Set downloads >10M<20M to prio4_normal after the first 10M has > downloaded (streams at the same point) > d. Set downloads >20M to prio1_bad > > In my test, I started 2 downloads and one stream (netflix, actually). > These 3 shared about equally 1M of bandwidth, with each getting around > 300k (give or take a little). After they reached the 10M download, they > were moved to pro4_normal. When that happened, I started another > download, which took nearly all of the 1M available bandwidth (because > it was priority1). The video stream was choking a little, but was > mostly working, the other downloads were the same (stop/go). Once the > "new" download reached it's 10M plateau, it was sharing the 1M pipe with > the other 3 downloads and all got about 256k (the video was better). > When the video and other 2 downloads reached the 20M plateau, they were > moved (automatically) to the "bad" queues at priority1. What that did > to my downloads was this: > > 1. The Prio1 queues in "normal" would allow me to surf like there was > nothing else going on. > > 2. My last download was getting 768k (the guarantee for "normal" queues) > > 3. My "bad" queues (the stream and the first 2 downloads) were sharing > the remaining 256k (guarantee for "bad" queues). > > I was not specifically identifying netflix in my application, but it was > being "caught" by the large download queues. I am still working out a > "best practices" approach to managing this traffic, but thought I would > share what I have so far. What do you think of my results so far? > > -- -- ******************************************************************** * 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: [email protected] Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
