Re: [Server-devel] Squid caching on the XSCE AND AP's
On Sat, Sep 14, 2013 at 10:18 PM, Anish Mangal 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 > 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 >> wrote: >>> >>> >>> On Sat, Sep 14, 2013 at 7:08 PM, Samuel Greenfeld >>> 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 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 cac
Re: [Server-devel] Squid caching on the XSCE AND AP's
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. Cheers, Anish On Sat, Sep 14, 2013 at 7:55 PM, Samuel Greenfeld 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 > wrote: > >> >> On Sat, Sep 14, 2013 at 7:08 PM, Samuel Greenfeld >> 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 >> > 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@lists.laptop.org http://lists.laptop.org/listinfo/server-devel >>> >> > > ___ > Server-devel mailing list > Server-devel@lists.laptop.org > http://
Re: [Server-devel] Squid caching on the XSCE AND AP's
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 wrote: > > On Sat, Sep 14, 2013 at 7:08 PM, Samuel Greenfeld 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 >> 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@lists.laptop.org >>> http://lists.laptop.org/listinfo/server-devel >>> >>> >> > ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Squid caching on the XSCE AND AP's
On Sat, Sep 14, 2013 at 7:08 PM, Samuel Greenfeld 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 > 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@lists.laptop.org >> http://lists.laptop.org/listinfo/server-devel >> >> > ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Squid caching on the XSCE AND AP's
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. 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. On Sat, Sep 14, 2013 at 9:31 PM, Anish Mangal 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@lists.laptop.org > http://lists.laptop.org/listinfo/server-devel > > ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
[Server-devel] Squid caching on the XSCE AND AP's
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@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
