Depends whether you are asking me or Jeremie. We dont use caching to save upstream badnwidth, currently. The reason is that our upstream transit costs are way less expesnive than our last mile and transport costs. At one point, I calculated our unlicensed transport costs to be close to $180 per mbps (inlcuding colo/roof leases), but our transit costs at the same time averaged under $10/mb. (actually down to $3/mb now all costs factored). Now, this is all changing, as we add more licensed higher capacity backhauls and higher capacity last mile. Today my last mile/transport costs are much much lower, but I haven't calculated that recently. Caching would not have saved us money or prevented bottle necks for download traffic. However, it very well could save us money caching our customers on-net web servers, reducing last mile traffic. Obviously, it would be the opposite situation for other WISPs that had high transit/transport costs and low last mile costs.
Tom DeReggi RapidDSL & Wireless, Inc IntAirNet- Fixed Wireless Broadband ----- Original Message ----- From: "Glenn Kelley" <[email protected]> To: "WISPA General List" <[email protected]> Sent: Thursday, May 20, 2010 11:51 AM Subject: Re: [WISPA] Bandwidth > Well Put. > > Have you guys thought about - (sorry jumping in the back end here) > adding squid or caching? > > I have seen some major drops on bandwidth when caching is put in place > - up to 30+% > > On the other hand - squid is not a replacement for the additional > bandwidth. > > > On May 20, 2010, at 10:43 AM, Tom DeReggi wrote: > >> For Ethernet colision detection type networks, you are correct. >> That is what many WISPs forget when deploying PtMP. They incorrectly >> think a >> CDMA 25mb link will double their 10mb TDD link as they scale. They >> learn >> that as customer get added, the capacity is not nearly as much as they >> thought.. >> >> But with Ethernet backbones it does not always work the same, for two >> reasons.... >> >> 1) There is only one end device, so its not possible for collisions, >> and >> collision avoidance algorythms aren't really needed. >> 2) If using TDD Ethernet, transmits are scheduled, without the >> typical >> overhead of Ethernet. >> >> I can run successfully run a bandwidth test of 95mb over a 100mb >> Cogent >> fiber circuti, and with a Tlink-45 set 36mbps mod, tested to pass >> 30mbps >> with radio tests, I can count on passing 30mbps through it. >> So again, it comes down to the design and technology of the backbone. >> >> Tom DeReggi >> RapidDSL & Wireless, Inc >> IntAirNet- Fixed Wireless Broadband >> >> >> ----- Original Message ----- >> From: "Scott Reed" <[email protected]> >> To: "WISPA General List" <[email protected]> >> Sent: Thursday, May 20, 2010 11:08 AM >> Subject: Re: [WISPA] Bandwidth >> >> >>> Old rule of thumb for Ethernet, because it is based on collision >>> detection, is 70-75% is the max you want. Above this and collisions >>> often become an issue. I assume the same is true for the faster >>> links >>> as well. >>> >>> Jeremie Chism wrote: >>>> At what percentage of your backbone usage do you look at adding more >>>> capacity. At peak times I run at 65-70 percent of capacity. Just >>>> looking for suggestions. >>>> >>>> Sent from my iPhone >>>> >>>> >>>> -------------------------------------------------------------------------------- >>>> 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/ >>>> >>>> >>>> >>> >>> -- >>> Scott Reed >>> Sr. Systems Engineer >>> GAB Midwest >>> 1-800-363-1544 x2241 >>> 1-260-827-2241 >>> Cell: 260-273-7239 >>> >>> >>> >>> -------------------------------------------------------------------------------- >>> 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/ >> >> >> >> -------------------------------------------------------------------------------- >> 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/ > > > > -------------------------------------------------------------------------------- > 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/ -------------------------------------------------------------------------------- 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/
