<div dir="ltr">[cc += server-devel]<div><br></div><div>Yes, I think we need real world data at this point, with both eth and mesh mode XS setups.</div><div><br></div><div>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!</div>
<div><br></div><div>Best,</div><div>Anish</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Sep 15, 2013 at 10:03 AM, Jon Nettleton <span dir="ltr"><<a href="mailto:jon.nettleton@gmail.com" target="_blank">jon.nettleton@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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. <div>
<br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Do we have actual or theoretical information about the wireless networking hardware and school server specs?</div><div><br></div><div>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 :-)</div>
<div><br></div><div>Wireless is convenient as can be, but far from bullet proof.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Jon</div><div><br></div><div><br></div><div><br></div><div><br></div></font></span></div>
<div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">
On Sun, Sep 15, 2013 at 5:19 PM, Tony Anderson <span dir="ltr"><<a href="mailto:tony_anderson@usa.net" target="_blank">tony_anderson@usa.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
While I think monitoring the school server will be more productive, I<br>
believe a router with ddwrt or openwrt would be relatively easy to monitor.<span><font color="#888888"><br>
<br>
Tony</font></span><div><div><br>
<br>
<br>
On 09/15/2013 05:16 PM, David Farning wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sat, Sep 14, 2013 at 10:18 PM, Anish Mangal<br>
<<a href="mailto:anish@activitycentral.com" target="_blank">anish@activitycentral.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Samuel,<br>
<br>
Thx for pushing for more clarity, to be honest, this is very much an<br>
experiment at this point. I don't have a single line of argument, but I'm<br>
trying to look for ways in which things can be improved.<br>
<br>
So the scenario is this:<br>
* There is one central XSCE, which is providing the internet gateway, hosts<br>
a ton of content on a large hard disk and provides many services.<br>
* There are AP-nodes (consider one AP per classroom), which perform DHCP,<br>
and facilitate "within the classroom" collaboration. That AP "might" also be<br>
running a light xmpp server like prosody.<br>
* AP's in mesh mode running SECN are potentially much easier to setup than<br>
wired ethernet, so, for this experiment, consider that we're working with<br>
AP's in mesh mode. To be more specific, consider that they are running SECN.<br>
<br>
* The huge drawback of wireless over a wired network, is obviously the<br>
network capacity that will be severely affected.<br>
<br>
The hypothesis is this:<br>
* Clients won't need the "main XS" for all their collaboration activities,<br>
it will be handled by the AP at a classroom level.<br>
* Clients will need to access the content present on the XS. A lot of it<br>
could be similar looking content per class. So it might be beneficial to<br>
have that cached much closer to the students.<br>
<br>
i would like you to comment in both cases, if the XS <-> connection is wired<br>
and wireless/mesh.<br>
<br>
- - - -<br>
<br>
To look at it from another perspective, the problem i want to analyze is<br>
this. What are the critical path components in a XS infrastructure setup,<br>
and is there room for making them:<br>
* More efficient<br>
* Easier to setup<br>
<br>
Solutions would probably be tradeoffs between the two, but if there are<br>
things that help address both those issues, that's even better.<br>
</blockquote>
<br>
My guess is that while less intellectually interesting, the first step<br>
along this path (pun intended) is visually monitoring the bandwidth<br>
usage of Access Points connected to the School Server.<br>
<br>
Do you think it would be possible to look at the AP caching and AP<br>
monitoring as related projects which identify and correct bottlenecks<br>
in the school network?<br>
<br>
One the distinguishing characteristics between high end APs (some of<br>
which cost more than my car) and commodity APs is the quality of the<br>
monitoring software.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers,<br>
Anish<br>
<br>
<br>
<br>
On Sat, Sep 14, 2013 at 7:55 PM, Samuel Greenfeld <<a href="mailto:greenfeld@laptop.org" target="_blank">greenfeld@laptop.org</a>><br>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think you need to explain your proposed use case better.<br>
<br>
If the APs are all attached to the schoolserver via Ethernet there really<br>
is no reason for them to do any caching. Having additional caches for this<br>
would only complicate things and increase the number of potential points of<br>
failure.<br>
<br>
If these APs are effectively being small XS-relays (DHCP, Internet, etc.)<br>
for remote sites directly connected to the Internet and the main XS only<br>
provides leases/Moodle/etc. from a centralized site, caching on the APs<br>
could help.<br>
<br>
If you were running APs in a mesh mode I could see this potentially<br>
helping or hurting. If every AP along the way cached data those closest to<br>
the XS could be thrashing their caches a lot.<br>
<br>
<br>
<br>
On Sat, Sep 14, 2013 at 10:17 PM, Anish Mangal <<a href="mailto:anish@activitycentral.com" target="_blank">anish@activitycentral.com</a>><br>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Sat, Sep 14, 2013 at 7:08 PM, Samuel Greenfeld <<a href="mailto:greenfeld@laptop.org" target="_blank">greenfeld@laptop.org</a>><br>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Unless there are clients that are going though the router but are not<br>
going through the schoolserver, I think this risks more harm than good.<br>
<br>
</blockquote>
<br>
The reason this can be useful is not for internet browsing, but for the<br>
tons of GB of content (videos, maps, wikipedia) stored locally on the XS.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Going back to the microprocessor analogy, the Level 2 cache usually is<br>
much larger than the Level 1 cache, and only slightly slower. Most<br>
community routers using USB sticks will be much slower than a schoolserver,<br>
and will not have the RAM to cache anywhere close to the same number of<br>
files in memory as the schoolserver, or the storage space of a hard drive.<br>
<br>
<br>
</blockquote>
<br>
The analogy doesn't run very well, as the AP is serving 20 users while<br>
the XS could be serving 200 or more.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
On Sat, Sep 14, 2013 at 9:31 PM, Anish Mangal<br>
<<a href="mailto:anish@activitycentral.com" target="_blank">anish@activitycentral.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Hi,<br>
<br>
I think it was Tony (please correct me if I'm wrong) who pointed out<br>
that network capacity in a School Server setup can be a hindrance (esp<br>
considering 200 kids, and 20 kids per AP).<br>
<br>
This weekend, I attempted to run squid on a TP-Link router. I used a<br>
USB drive as a storage medium, and flashed the router with the OpenWRT SECN<br>
firmware. The initial results seem quite promising, and I'm going to explore<br>
this a bit further.<br>
<br>
If anyone's interested in hacking on this or has thoughts/feedback,<br>
please chip in :-)<br>
<br>
Drawing a "microprocessor" analogy, having a L1 cache on the XSCE and<br>
an L2 cache on the AP, and some smart fine tuning, we could potentially make<br>
much more efficient use of the network capacity we have.<br>
<br>
This can be REALLY advantageous if someone is planning to use the SECN<br>
firmware in the mesh mode (no ethernet cables whatsoever). The AP's wouldn't<br>
have to talk to each other as often, if they all have small cache memories<br>
embedded in them.<br>
<br>
Cheers,<br>
Anish<br>
<br>
______________________________<u></u>_________________<br>
Server-devel mailing list<br>
<a href="mailto:Server-devel@lists.laptop.org" target="_blank">Server-devel@lists.laptop.org</a><br>
<a href="http://lists.laptop.org/listinfo/server-devel" target="_blank">http://lists.laptop.org/<u></u>listinfo/server-devel</a><br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
Server-devel mailing list<br>
<a href="mailto:Server-devel@lists.laptop.org" target="_blank">Server-devel@lists.laptop.org</a><br>
<a href="http://lists.laptop.org/listinfo/server-devel" target="_blank">http://lists.laptop.org/<u></u>listinfo/server-devel</a><br>
<br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
Server-devel mailing list<br>
<a href="mailto:Server-devel@lists.laptop.org" target="_blank">Server-devel@lists.laptop.org</a><br>
<a href="http://lists.laptop.org/listinfo/server-devel" target="_blank">http://lists.laptop.org/<u></u>listinfo/server-devel</a><br>
<br>
</blockquote>
<br>
<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>