[Server-devel] [XSCE] Re: Squid caching on the XSCE AND AP's

Anish Mangal anish at activitycentral.com
Sun Sep 15 14:17:36 EDT 2013 

[cc += server-devel]

Yes, I think we need real world data at this point, with both eth and mesh
mode XS setups.

I'm trying to ping people who have a XS setup in either of these
configurations, but if someone is willing to share data/logs and/or install
sar on their server, it would be very useful and much appreciated!

Best,
Anish



On Sun, Sep 15, 2013 at 10:03 AM, Jon Nettleton <jon.nettleton at gmail.com>wrote:

> I agree that if the AP's are connected to the schoolserver via switched
> ethernet there should not be any reason to use a proxy.  Even modest
> hardware and 10Mb/s ethernet can easy saturate 802.11 b and maybe g
> wireless.
>
> If everything is connected via wifi, well there are some severe
> bottlenecks that could possibly be alleviate by proxy.  With a single band
> wifi connection we are looking at packets at best going client send frame
> to ap, ap waits until it is done with client, ap sends frame to school
> server, and then back again. The AP is really working like a wireless
> extender in this case so you are down to half the theoretical bandwidth.
> Now extract that out to 20 kids on 10 APs all trying to transfer data to a
> server on a single channel of the wireless spectrum.  RTS/CTS will help to
> alleviate some of the collisions requiring re-broadcasts but that is still
> a pretty saturated channel.  If the AP's have dual radios then you could
> speed things up by having the school server talk to all the AP's on one
> channel and the AP's talking to the students on another.  I would also
> recommend tuning the wireless ACK timeout, as the default on most routers
> is way to long for this much traffic and will only cause additional
> throughput loss.
>
> The Cubox-i has a broadcom wireless chip in it.  I have been told twice
> which model but keep forgetting and my logs are on another computer.  I
> will hopefully be able to put it through it's paces by the end of this
> coming week.
>
> Do we have actual or theoretical information about the wireless networking
> hardware and school server specs?
>
> Ideally we would need stats on both the school server and all the WAP's.
>  It is probably easiest to collect data from the school server first, so I
> think it would make sense to enable SAR on the school server as it is
> pretty low impact and will give you metrics on just about everything you
> need to know with the server, CPU usage, IO, Memory, etc.  If you see bad
> performance and the server looks fine then it is most likely your wireless
> configuration.  Or of course you have a cheap AP and someone is running a
> microwave oven near it, or talking on a  2.4ghz cordless phone :-)
>
> Wireless is convenient as can be, but far from bullet proof.
>
> -Jon
>
>
>
>
>
>
> On Sun, Sep 15, 2013 at 5:19 PM, Tony Anderson <tony_anderson at usa.net>wrote:
>
>> Hi,
>>
>> While I think monitoring the school server will be more productive, I
>> believe a router with ddwrt or openwrt would be relatively easy to
>> monitor.
>>
>> Tony
>>
>>
>>
>> On 09/15/2013 05:16 PM, David Farning wrote:
>>
>>> On Sat, Sep 14, 2013 at 10:18 PM, Anish Mangal
>>> <anish at activitycentral.com> wrote:
>>>
>>>> Hi Samuel,
>>>>
>>>> Thx for pushing for more clarity, to be honest, this is very much an
>>>> experiment at this point. I don't have a single line of argument, but
>>>> I'm
>>>> trying to look for ways in which things can be improved.
>>>>
>>>> So the scenario is this:
>>>> * There is one central XSCE, which is providing the internet gateway,
>>>> hosts
>>>> a ton of content on a large hard disk and provides many services.
>>>> * There are AP-nodes (consider one AP per classroom), which perform
>>>> DHCP,
>>>> and facilitate "within the classroom" collaboration. That AP "might"
>>>> also be
>>>> running a light xmpp server like prosody.
>>>> * AP's in mesh mode running SECN are potentially much easier to setup
>>>> than
>>>> wired ethernet, so, for this experiment, consider that we're working
>>>> with
>>>> AP's in mesh mode. To be more specific, consider that they are running
>>>> SECN.
>>>>
>>>> * The huge drawback of wireless over a wired network, is obviously the
>>>> network capacity that will be severely affected.
>>>>
>>>> The hypothesis is this:
>>>> * Clients won't need the "main XS" for all their collaboration
>>>> activities,
>>>> it will be handled by the AP at a classroom level.
>>>> * Clients will need to access the content present on the XS. A lot of it
>>>> could be similar looking content per class. So it might be beneficial to
>>>> have that cached much closer to the students.
>>>>
>>>> i would like you to comment in both cases, if the XS <-> connection is
>>>> wired
>>>> and wireless/mesh.
>>>>
>>>> - - - -
>>>>
>>>> To look at it from another perspective, the problem i want to analyze is
>>>> this. What are the critical path components in a XS infrastructure
>>>> setup,
>>>> and is there room for making them:
>>>> * More efficient
>>>> * Easier to setup
>>>>
>>>> Solutions would probably be tradeoffs between the two, but if there are
>>>> things that help address both those issues, that's even better.
>>>>
>>>
>>> My guess is that while less intellectually interesting, the first step
>>> along this path (pun intended) is visually monitoring the bandwidth
>>> usage of Access Points connected to the School Server.
>>>
>>> Do you think it would be possible to look at the AP caching and AP
>>> monitoring as related projects which identify and correct bottlenecks
>>> in the school network?
>>>
>>> One the distinguishing characteristics between high end APs (some of
>>> which cost more than my car) and commodity APs is the quality of the
>>> monitoring software.
>>>
>>>  Cheers,
>>>> Anish
>>>>
>>>>
>>>>
>>>> On Sat, Sep 14, 2013 at 7:55 PM, Samuel Greenfeld <greenfeld at laptop.org
>>>> >
>>>> wrote:
>>>>
>>>>>
>>>>> I think you need to explain your proposed use case better.
>>>>>
>>>>> If the APs are all attached to the schoolserver via Ethernet there
>>>>> really
>>>>> is no reason for them to do any caching.  Having additional caches for
>>>>> this
>>>>> would only complicate things and increase the number of potential
>>>>> points of
>>>>> failure.
>>>>>
>>>>> If these APs are effectively being small XS-relays (DHCP, Internet,
>>>>> etc.)
>>>>> for remote sites directly connected to the Internet and the main XS
>>>>> only
>>>>> provides leases/Moodle/etc. from a centralized site, caching on the APs
>>>>> could help.
>>>>>
>>>>> If you were running APs in a mesh mode I could see this potentially
>>>>> helping or hurting.  If every AP along the way cached data those
>>>>> closest to
>>>>> the XS could be thrashing their caches a lot.
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Sep 14, 2013 at 10:17 PM, Anish Mangal <
>>>>> anish at activitycentral.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Sep 14, 2013 at 7:08 PM, Samuel Greenfeld <
>>>>>> greenfeld at laptop.org>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> Unless there are clients that are going though the router but are not
>>>>>>> going through the schoolserver, I think this risks more harm than
>>>>>>> good.
>>>>>>>
>>>>>>>
>>>>>> The reason this can be useful is not for internet browsing, but for
>>>>>> the
>>>>>> tons of GB of content (videos, maps, wikipedia) stored locally on the
>>>>>> XS.
>>>>>>
>>>>>>
>>>>>>> Going back to the microprocessor analogy, the Level 2 cache usually
>>>>>>> is
>>>>>>> much larger than the Level 1 cache, and only slightly slower.  Most
>>>>>>> community routers using USB sticks will be much slower than a
>>>>>>> schoolserver,
>>>>>>> and will not have the RAM to cache anywhere close to the same number
>>>>>>> of
>>>>>>> files in memory as the schoolserver, or the storage space of a hard
>>>>>>> drive.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> The analogy doesn't run very well, as the AP is serving 20 users while
>>>>>> the XS could be serving 200 or more.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Sep 14, 2013 at 9:31 PM, Anish Mangal
>>>>>>> <anish at activitycentral.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I think it was Tony (please correct me if I'm wrong) who pointed out
>>>>>>>> that network capacity in a School Server setup can be a hindrance
>>>>>>>> (esp
>>>>>>>> considering 200 kids, and 20 kids per AP).
>>>>>>>>
>>>>>>>> This weekend, I attempted to run squid on a TP-Link router. I used a
>>>>>>>> USB drive as a storage medium, and flashed the router with the
>>>>>>>> OpenWRT SECN
>>>>>>>> firmware. The initial results seem quite promising, and I'm going
>>>>>>>> to explore
>>>>>>>> this a bit further.
>>>>>>>>
>>>>>>>> If anyone's interested in hacking on this or has thoughts/feedback,
>>>>>>>> please chip in :-)
>>>>>>>>
>>>>>>>> Drawing a "microprocessor" analogy, having a L1 cache on the XSCE
>>>>>>>> and
>>>>>>>> an L2 cache on the AP, and some smart fine tuning, we could
>>>>>>>> potentially make
>>>>>>>> much more efficient use of the network capacity we have.
>>>>>>>>
>>>>>>>> This can be REALLY advantageous if someone is planning to use the
>>>>>>>> SECN
>>>>>>>> firmware in the mesh mode (no ethernet cables whatsoever). The AP's
>>>>>>>> wouldn't
>>>>>>>> have to talk to each other as often, if they all have small cache
>>>>>>>> memories
>>>>>>>> embedded in them.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Anish
>>>>>>>>
>>>>>>>> ______________________________**_________________
>>>>>>>> Server-devel mailing list
>>>>>>>> Server-devel at lists.laptop.org
>>>>>>>> http://lists.laptop.org/**listinfo/server-devel<http://lists.laptop.org/listinfo/server-devel>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ______________________________**_________________
>>>>> Server-devel mailing list
>>>>> Server-devel at lists.laptop.org
>>>>> http://lists.laptop.org/**listinfo/server-devel<http://lists.laptop.org/listinfo/server-devel>
>>>>>
>>>>>
>>>>
>>>> ______________________________**_________________
>>>> Server-devel mailing list
>>>> Server-devel at lists.laptop.org
>>>> http://lists.laptop.org/**listinfo/server-devel<http://lists.laptop.org/listinfo/server-devel>
>>>>
>>>>
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/server-devel/attachments/20130915/facc8e0b/attachment.html>

More information about the Server-devel mailing list