<div dir="ltr"><div>Hi Samuel,</div><div><br></div><div>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. </div>
<div><br></div><div>So the scenario is this:</div><div>* 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.</div><div>* 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. <br>
</div><div>* 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.</div>
<div><br></div><div>* The huge drawback of wireless over a wired network, is obviously the network capacity that will be severely affected.</div><div><br></div><div>The hypothesis is this:</div><div>* Clients won't need the "main XS" for all their collaboration activities, it will be handled by the AP at a classroom level.</div>
<div>* 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.</div><div><br></div><div>
i would like you to comment in both cases, if the XS <-> connection is wired and wireless/mesh.<br></div><div><br></div><div>- - - - </div><div><br></div><div>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:</div>
<div>* More efficient</div><div>* Easier to setup</div><div><br></div><div>Solutions would probably be tradeoffs between the two, but if there are things that help address both those issues, that's even better.</div>
<div>
<br></div><div>Cheers,</div><div>Anish</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Sep 14, 2013 at 7:55 PM, Samuel Greenfeld <span dir="ltr"><<a href="mailto:greenfeld@laptop.org" target="_blank">greenfeld@laptop.org</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"><div>I think you need to explain your proposed use case better.<br></div><div><br>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.<br>
<br></div>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.<br>
<div><div><br>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.<br><br></div></div>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Sep 14, 2013 at 10:17 PM, Anish Mangal <span dir="ltr"><<a href="mailto:anish@activitycentral.com" target="_blank">anish@activitycentral.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"><div><br></div><div class="gmail_extra"><div class="gmail_quote"><div>On Sat, Sep 14, 2013 at 7:08 PM, Samuel Greenfeld <span dir="ltr"><<a href="mailto:greenfeld@laptop.org" target="_blank">greenfeld@laptop.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">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.<br>
<br></div></blockquote><div><br></div></div><div>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. </div><div><div>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">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.<br>
<br><br></div></blockquote><div><br></div></div><div>The analogy doesn't run very well, as the AP is serving 20 users while the XS could be serving 200 or more. </div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Sat, Sep 14, 2013 at 9:31 PM, Anish Mangal <span dir="ltr"><<a href="mailto:anish@activitycentral.com" target="_blank">anish@activitycentral.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div dir="ltr">Hi,<div><br>
</div><div>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). </div>
<div><br></div><div>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. </div>
<div><br></div><div>If anyone's interested in hacking on this or has thoughts/feedback, please chip in :-)</div><div><br></div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>Cheers,</div><div>Anish</div></div>
<br></div></div>_______________________________________________<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/listinfo/server-devel</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div><br></div></div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Server-devel mailing list<br>
<a href="mailto:Server-devel@lists.laptop.org">Server-devel@lists.laptop.org</a><br>
<a href="http://lists.laptop.org/listinfo/server-devel" target="_blank">http://lists.laptop.org/listinfo/server-devel</a><br>
<br></blockquote></div><br></div>