1) Menu's dont cost me bandwidth or server CPU time. 2) Menu's do not contain sexually explicit or illegal scam material. 3) Reading the menu doesn't cause me to be the permanent target of 100 other restaurants. 4) Menu's may even be usefull.
In concept, they are certainly similar, though junk mail is far less annoying. Here in Australia, you can even put a "No Junk Mail" sign on your letterbox - something you cant do for spam.
We've seen many, many viruses in the last 5 years that have wreaked havoc, and not many of them have had a malicious payload. Most of the trouble seems to have been caused by the network congestion.
One day, people are going to find that clicking mindlessly on that "Hey, check this out!" email is going to fuck their home and corporate PC big time. Clicking on it two or three times wont help either.
What sort of coolant? Do you mean automotive coolant?
In comparison to water, auto coolant has: * Lower thermal capacity * Higher electrical conductivity
That basically makes it worse performaing, at higher risk. The only benefit is corrosion inhibitors, which are only good if you are using an aluminum block/radiator.
Water is perfectly fine for PC's - especially in an all copper system.
This is off topic, but that really depends on what sort of coffee you drink.
Personally, I drink instant for something to pass the time, but I think it tastes like crap. However, a good fresh espresso based coffee is absolutely delicious. Any time I walk past a cafe and and smell real coffee, my mouth waters.
The people that do watercooling, is there any maintenence to them at all?
Ive been watercooling for several years, and the only maintainence ive required is: 1) Very occasional top up of the water (maybe once a year). It s a sealed system, but some vapour must escape through the piping/connectors. 2) Cleaning the radiator every few/6 months. This is no different to fans/heatsinks, it's just that the location and airflow I use means my radiator gets clogged.
I agree - even a little maintainence is too much for many people - a factory watercooling system would need to be developed with this in mind. It's certainly not impossible to expect several years maintainence free.
For the benefit of other readers - Heat pipes are a completely different animal to the water cooling we're talkign about, though they have far greater potential.
Essentially, they're an evacuated pipe with some working fluid injected. This could be water, butane, ammonia or sodium (high temps). Because of the vacuumn, some of the liquid evaporates until equilibrium is reached.
So, we have a liquid/vapor environment. Add heat at one end and local equilibrium shifts, vaporising more liquid. Cool the other end, and local equilibrium goes the other way. The pressure diffence causes the vapor to travel at the speed of sound from one end to the other, whilst the liquid flows back the other way via gravity or wicking.
This leaves you with a device that is 1000 times more conductive than copper of the same dimensions. CPU one end, heatsink/radiator at the other, and there you go!
Clamps fail far less often than a dusty 5cm CPU fan.
Watercooling can be very reliable, you just have to take some care. Some tests before putting the computer into operation is also a good idea. That said, Ive heard of several people having leaks, without permanent damage to their systems.
A few keen hobbyists/overclockers have done it - often using mineral oil.
In reality, it's not practical, or necessary. In fact, it's just plain messy. Most components work fine with air cooling. It's just a few hot spots (CPU, GPU, HDD etc) that can benefit.
I can fit a 12x24 cm ratiator inside my case, and cool it with two 12cm AC fans. They are *very* quiet, and I have a well cooled, transportable system.
In terms of performance, I was using this on a heavily overclocked celeron 733 (running at 1100MHz, ~50W heat). Internal diode temps were about 12 - 14 degrees over ambient at full load. Compare that to my wife's system - a celeron 566 (running 850MHz or less, with much less than 50W output) with stock cooler. It would run more than 20 degrees over ambient, and the fan was bloody noisy.
A good exaple of head to head tests would be Dans Data massice cooler comparison -> http://www.dansdata.com/coolercomp_p10.htm.
In practical setups, a watercooled system can have significantly lower thermal resistance than air cooling - eg in dans's rigs, he can get as low as 0.3 degc/W for water cooling, and the best air cooled systems are 0.5degc/watt.
What this means is that you can make a trade off- get better or equivalent cooling, at lower noise levels. Ive been running water cooling for several years, and it's been reliable and performant for me, plus far quieter than my wife's stock air cooler.
The benefit of water comes from several aspects:
1) High thermal capacity - as you said, acts like an energy buffer.
2) Higher thermal conductivity than air - allows heat energy to be transferred faster.
3) Allows radiator (YES! you need a way of dissipating heat) to be located remotely from the CPU. This means you can have a much larger radiator, with far more surface area and airflow than would be possible with a CPU mounted heatsink.
Remember, water is just a transport mechanism - ultimately the heat has to escape to the air. If you build the radiator large enough, the temps will be lower than you could practicalally achieve with standard air cooling.
In my experience, night shift is far less stressfull:
- managers have gone home (yay! - no hassle) - less people around (who wants to work nightshift?) - its generally quieter, less distractions (see above) - better efficiency (see above) - can be less work (because no-one notices, or less customers)
Whilst the homemade winner was pretty good, im a bit suprised by some of the commercial entries.
eg: "Using a Stock Hyperlink 15dBi Omni at the base camp, and a stock Hyperlink 24dBi parabolic grid at the field site, with a confirmed distance of 10.1625 miles"
the WAFreenet (Perth, Western Australia) has several links of 18 to 22km (11.25 to 13.75 miles) - 30mW Clients with home modded 24dBi dishes (galaxy mods), connenecting to a 30mW AP with 14dB Waveguide. These links are about 8 - 10 SNR IIRC.
Our best is a link to the same AP from Rottnest island - 46 km! One connection was using an ipaq + cantenna with 2SNR, and another was with a modded satellite dish (overpowered at about 40dB EIRP), not sure of it's signal performance.
Several groups in the eastern states of Australia have achieved similar resulst.
If I only got 16km with a commercial 24dBi panel, i'd ask for my money back!
I would be curious to hear from anyone who knows what the scene is like in Perth for cheap, affordable world-class Internet bandwidth?
You can get some of it cheap, but it's not really world class.
256kbit ADSL with 2GB soft cap for A$50/month 1.5mbit ADSL with ~22GB soft cap for A$150/month Cable (only in some areas) with 10GB hard cap for A$300/month + A$0.10 per MB over cap
Reliability on the ADSL is pretty crap, many of the ISP's have experienced such huge takeup that their main data pipes cant meet the demand. Also, there are lot of places that cant get ADSL due to multiplexed/pair gain phone systems - Telstra only just released cheaper ISDN plans to combat this.
Telstra and Optus rolled out cables in competing areas, so there is a poor spread, covering only a small fraction of the city.
There's also satellite with ridiculous pricing, and a few wireless ISP's starting up.
The topic of buying more equipment was discussed with the HillsHub users. Unfortunately, we couldnt do it.
As I mentioned in the story, HillsHub is very popular due to it's location. It's a private property - owned by the Uncle of one of the wireless enthusiasts. They've been gratious enough to allow one waveguide and a dish on their roof, but that's it. Even if we could put more infrastructure there, there is channel usage and other surrounding AP's (noise/interference) to be aware of. There are real limitiations.
The hidden node issue was noticable to some degree with as low as 4 or 5 users. If we put three AP's at Hills Hub, I bet there would be more than that many users per AP.
As far as latency goes - it is a shame, but that's the price we're willing to pay. With 14 or so users, we're seeing under 200ms round trip latency to the central server - more from client to client. That's not terrible, but not completely suitable for gaming. Were trying to come up with some schedules for modifying the frottle parameters - choosing faster polling (lower latency) for game times, slower polling (higher efficiency) for leeching times.
That's right....we'll all go spend several hundreds dollars on 802.11g equipment, that wasnt even available when we started this project. We'll find it in the fairy shop next to the magical beans, then well go spend countless hours installing it, and throw our current investments in the bin.
Thanks, but get real.
PS - the token in this system doesnt get passed from client to client. The master hands out a control packet, the client sends data, sends a response packet, then the master moves on.
If the client overruns - not much we can do. If the token gets lost, the master just waits a moment and sends a control packet to the next client. It doesnt even need to be in order - busy clients can get more time, quiet clients less, or even skipped completely for several cycles.
Traffic shaping (which is all frottle is doing) helps ease this problem by reducing the amount of data clients try to send/recv in a given period of time, and thus reduces some of the contention.
Not true. Each client sends its data one at time, much like a token ring.
Yes, it's a bandaid solution, but your comments are just misleading. How about you read the documentation next time.
I wonder what happens when one of the client on one of the computers crashes and ceases to act as a polled client.
If people connect to the AP without frottle, essentially the collisions and packetloss appear whenever they are uploading. To discourage this, we generally firewall any non-frottle clients, using the frottle stats output in a script. Now, this doesnt stop people using the AP to repeat traffic at the MAC layer, bypassing our routed topilogy - though if this was a problem we could setup MAC filtering.
So, this system is completely succeptible to failure or circumvention. Good this is, we're all mates.
The frottle people should not say they implemented AP polling modes with a software firewall because that is not what they did!
I dont thik we ever said we did. We were quite clear that this was IP layer polling (not just traffic shaping either - it's co-ordinated).
Yes, we are "fakin' it", but unfortunately that is all we have to work with. Karnet, with their expertise and budget, have true AP polling with their Turbocell system.
Now, we dont claim to be RF experts, but from what I can determine our example IS a hidden node scenario - we have many geographically remote clients, connecting to the AP with directional antennas. Those clients are unable to hear each others transmissions, and hence are unable effect propper collision avoidance.
Once upon a time, in the mystical land of Oz, there was the quiet city of Perth. Broadband was expensive (cable was only in one suburb), and ADSL was only just beginning to roll out. WiFi has just been released, and a group of enthusiasts saw the potential.
A bunch of people got together, and through many donations, were able to buy their first public WAFreenet Access Point. Now - Perth is fairly flat, with a long ridge running down one side - perfect! The AP was setup on a private property with an incerible view of the city, and we named it HillsHub (we'll call it HH).
By about 5 clients, the hidden node issue started to get noticable. Easy, they turned on RTS, and it made an improvement.
Since it had such good visibility, HH began to get pretty popular. By about 10 clients it was really stuggling, and many of those clients had AP and clients of their own adding to the routed traffic. RTS just wasnt cutting it anymore - the RTS packets are subject to collisions aswell. In a desperate effort to regain some control, rate limiting was implemented, dropping speeds back to 10kB/sec during the day to maintain some reliability. However - during the night, a free for all would occur - some people would get 100's kB/sec, whislt others would be drowned out, near complete packetloss.
By 14 clients, the situation was ridiculous. We HAD to do something. We knew Kalrnet Turbocell (a polled system) would fix it, so we sold our soul (advertising on the e3 website) and negotiated a lower price - even then we needed to fork out A$150 each. We got together and pooled the cash, and just as we were about to buy, realised that the linux support was terrible - old, buggy kernels, binary driver only. We stopped in our tracks, and wondered what to do.
There were plenty of ideas about building our own kalrnet, but none of us were kernel programmers, so it seemed a bit out of reach. That was until one day, when I came up with a plan. I'd read that iptables could send packets to a userspace program, so inspired by some examples (countertrace), I set about building the first version of frottle using perl.
There was nothing new about the concept - polled systems and token rings are common knowledge in communications and networking. It wasnt difficult - it only took me a weekend, and that included the time spent learning perl (it was my first go). It was even operating at the wrong layer - using UDP control messages to schedule IP traffic. Regardless of all it's limitations, it worked, so I got the other WAFreenet members involved with testing and development. Radix picked it up and tried to continue development with C++, but had problems. Then, ChrisK took up the challege, and the result is the dynamic, performance C version we have released.
Halfway through development, WiCCP was released. This was a similar concept, but implemented as an loadable module/interface. We liked the concept better than our userspace app, so we trialled it ourselves. One of the perth guys (Brad) even got involved with development, improving the product. Still, whislt it was an implrovement on no QoS, it didnt seem to perform quite as well as frottle. This was the decider, so ChrisK prepared frottle for release.
So, there you have it. As a developer, I've been paying attention to the comments here. Many of you have given positive feedback, and for that we're thankfull. Unfortunately, some of you have decided it would be easier to point out the flaws...
Well, no shit sherlock! We're quite aware of frottle's limitations, the concept is far from origonal, and it really is a kludge. The inherent problems of 802.11b are still there, and all we've done is work around them. The thing is, no-one else had done it before - at least not for free, and not when we started. We've spent our own time on frottle in order to improve our situation, and help the performance of free community wireless networks the world over.
Criticise all you like, but the fact is, we have experienced an enourmous, measurable improvement to our network performance. As far as we're concerned, this is BIG news.
WiFI always has a man in the middle - it's called the AP. Client-Client always involves 2 radio hops. In our implementation, we've taken the step of shooting the packet over wired ethernet aswell, but it makes very little impact on performance. In fact, we found early on (before frottle) that it reduced packetloss).
Frottle can run in many modes, and doesnt need traffic to pass through the master, though it is more reliable to do so.
As far as Client-Client comms goes, we've always discouraged it for it's use of bandwidth, and before frottle it was the main cause of collisions. For this reason, we stick most of our resources at the master, meaning most data is only a single RF hop away.
Unfortunately, RTS/CTS is almost worthless in a situation that requires it - when you've got hidden nodes, the RTS mechanism can just as easily cause collisions.
The users of WAFreeNet (Perth, Australia) have just released some open source software (frottle) to combat this. Essentially it provides a polled/token operation at the IP layer, virtually eliminating collisions. This is a similar application to WiCCP, and we've been helping/competeing with the WiCCP developers. The other alternative is Karlnet Turbocell - expensive proprietarty software, firmware and hardware, with poor linux support.
I cant post any url's now - the websites wouldnt appreciate the slashdotting. For those of you than can find the sites for yourself, it may be well worth your time.
Slashdot Mirror
1) Menu's dont cost me bandwidth or server CPU time.
2) Menu's do not contain sexually explicit or illegal scam material.
3) Reading the menu doesn't cause me to be the permanent target of 100 other restaurants.
4) Menu's may even be usefull.
In concept, they are certainly similar, though junk mail is far less annoying. Here in Australia, you can even put a "No Junk Mail" sign on your letterbox - something you cant do for spam.
I agree - IIRC, viruses used to be malicious.
We've seen many, many viruses in the last 5 years that have wreaked havoc, and not many of them have had a malicious payload. Most of the trouble seems to have been caused by the network congestion.
One day, people are going to find that clicking mindlessly on that "Hey, check this out!" email is going to fuck their home and corporate PC big time. Clicking on it two or three times wont help either.
What sort of coolant? Do you mean automotive coolant?
In comparison to water, auto coolant has:
* Lower thermal capacity
* Higher electrical conductivity
That basically makes it worse performaing, at higher risk. The only benefit is corrosion inhibitors, which are only good if you are using an aluminum block/radiator.
Water is perfectly fine for PC's - especially in an all copper system.
This is off topic, but that really depends on what sort of coffee you drink.
Personally, I drink instant for something to pass the time, but I think it tastes like crap. However, a good fresh espresso based coffee is absolutely delicious. Any time I walk past a cafe and and smell real coffee, my mouth waters.
The people that do watercooling, is there any maintenence to them at all?
Ive been watercooling for several years, and the only maintainence ive required is:
1) Very occasional top up of the water (maybe once a year). It s a sealed system, but some vapour must escape through the piping/connectors.
2) Cleaning the radiator every few/6 months. This is no different to fans/heatsinks, it's just that the location and airflow I use means my radiator gets clogged.
I agree - even a little maintainence is too much for many people - a factory watercooling system would need to be developed with this in mind. It's certainly not impossible to expect several years maintainence free.
For the benefit of other readers - Heat pipes are a completely different animal to the water cooling we're talkign about, though they have far greater potential.
Essentially, they're an evacuated pipe with some working fluid injected. This could be water, butane, ammonia or sodium (high temps). Because of the vacuumn, some of the liquid evaporates until equilibrium is reached.
So, we have a liquid/vapor environment. Add heat at one end and local equilibrium shifts, vaporising more liquid. Cool the other end, and local equilibrium goes the other way. The pressure diffence causes the vapor to travel at the speed of sound from one end to the other, whilst the liquid flows back the other way via gravity or wicking.
This leaves you with a device that is 1000 times more conductive than copper of the same dimensions. CPU one end, heatsink/radiator at the other, and there you go!
Clamps fail far less often than a dusty 5cm CPU fan.
Watercooling can be very reliable, you just have to take some care. Some tests before putting the computer into operation is also a good idea. That said, Ive heard of several people having leaks, without permanent damage to their systems.
A few keen hobbyists/overclockers have done it - often using mineral oil.
In reality, it's not practical, or necessary. In fact, it's just plain messy. Most components work fine with air cooling. It's just a few hot spots (CPU, GPU, HDD etc) that can benefit.
Not necesarily true.
I can fit a 12x24 cm ratiator inside my case, and cool it with two 12cm AC fans. They are *very* quiet, and I have a well cooled, transportable system.
In terms of performance, I was using this on a heavily overclocked celeron 733 (running at 1100MHz, ~50W heat). Internal diode temps were about 12 - 14 degrees over ambient at full load. Compare that to my wife's system - a celeron 566 (running 850MHz or less, with much less than 50W output) with stock cooler. It would run more than 20 degrees over ambient, and the fan was bloody noisy.
A good exaple of head to head tests would be Dans Data massice cooler comparison -> http://www.dansdata.com/coolercomp_p10.htm.
In practical setups, a watercooled system can have significantly lower thermal resistance than air cooling - eg in dans's rigs, he can get as low as 0.3 degc/W for water cooling, and the best air cooled systems are 0.5degc/watt.
What this means is that you can make a trade off- get better or equivalent cooling, at lower noise levels. Ive been running water cooling for several years, and it's been reliable and performant for me, plus far quieter than my wife's stock air cooler.
The benefit of water comes from several aspects: 1) High thermal capacity - as you said, acts like an energy buffer. 2) Higher thermal conductivity than air - allows heat energy to be transferred faster. 3) Allows radiator (YES! you need a way of dissipating heat) to be located remotely from the CPU. This means you can have a much larger radiator, with far more surface area and airflow than would be possible with a CPU mounted heatsink. Remember, water is just a transport mechanism - ultimately the heat has to escape to the air. If you build the radiator large enough, the temps will be lower than you could practicalally achieve with standard air cooling.
In my experience, night shift is far less stressfull:
- managers have gone home (yay! - no hassle)
- less people around (who wants to work nightshift?)
- its generally quieter, less distractions (see above)
- better efficiency (see above)
- can be less work (because no-one notices, or less customers)
That is correct, and I was aware of the classes. Regardless, Im still suprised that some of the commercial gear was so ordinary.
Whilst the homemade winner was pretty good, im a bit suprised by some of the commercial entries.
eg: "Using a Stock Hyperlink 15dBi Omni at the base camp, and a stock Hyperlink 24dBi parabolic grid at the field site, with a confirmed distance of 10.1625 miles"
the WAFreenet (Perth, Western Australia) has several links of 18 to 22km (11.25 to 13.75 miles) - 30mW Clients with home modded 24dBi dishes (galaxy mods), connenecting to a 30mW AP with 14dB Waveguide. These links are about 8 - 10 SNR IIRC.
Our best is a link to the same AP from Rottnest island - 46 km! One connection was using an ipaq + cantenna with 2SNR, and another was with a modded satellite dish (overpowered at about 40dB EIRP), not sure of it's signal performance.
Several groups in the eastern states of Australia have achieved similar resulst.
If I only got 16km with a commercial 24dBi panel, i'd ask for my money back!
I would be curious to hear from anyone who knows what the scene is like in Perth for cheap, affordable world-class Internet bandwidth?
You can get some of it cheap, but it's not really world class.
256kbit ADSL with 2GB soft cap for A$50/month
1.5mbit ADSL with ~22GB soft cap for A$150/month
Cable (only in some areas) with 10GB hard cap for A$300/month + A$0.10 per MB over cap
Reliability on the ADSL is pretty crap, many of the ISP's have experienced such huge takeup that their main data pipes cant meet the demand. Also, there are lot of places that cant get ADSL due to multiplexed/pair gain phone systems - Telstra only just released cheaper ISDN plans to combat this.
Telstra and Optus rolled out cables in competing areas, so there is a poor spread, covering only a small fraction of the city.
There's also satellite with ridiculous pricing, and a few wireless ISP's starting up.
The topic of buying more equipment was discussed with the HillsHub users. Unfortunately, we couldnt do it.
As I mentioned in the story, HillsHub is very popular due to it's location. It's a private property - owned by the Uncle of one of the wireless enthusiasts. They've been gratious enough to allow one waveguide and a dish on their roof, but that's it. Even if we could put more infrastructure there, there is channel usage and other surrounding AP's (noise/interference) to be aware of. There are real limitiations.
The hidden node issue was noticable to some degree with as low as 4 or 5 users. If we put three AP's at Hills Hub, I bet there would be more than that many users per AP.
As far as latency goes - it is a shame, but that's the price we're willing to pay. With 14 or so users, we're seeing under 200ms round trip latency to the central server - more from client to client. That's not terrible, but not completely suitable for gaming. Were trying to come up with some schedules for modifying the frottle parameters - choosing faster polling (lower latency) for game times, slower polling (higher efficiency) for leeching times.
That's right....we'll all go spend several hundreds dollars on 802.11g equipment, that wasnt even available when we started this project. We'll find it in the fairy shop next to the magical beans, then well go spend countless hours installing it, and throw our current investments in the bin.
Thanks, but get real.
PS - the token in this system doesnt get passed from client to client. The master hands out a control packet, the client sends data, sends a response packet, then the master moves on.
If the client overruns - not much we can do. If the token gets lost, the master just waits a moment and sends a control packet to the next client. It doesnt even need to be in order - busy clients can get more time, quiet clients less, or even skipped completely for several cycles.
Traffic shaping (which is all frottle is doing) helps ease this problem by reducing the amount of data clients try to send/recv in a given period of time, and thus reduces some of the contention.
Not true. Each client sends its data one at time, much like a token ring.
Yes, it's a bandaid solution, but your comments are just misleading. How about you read the documentation next time.
I wonder what happens when one of the client on one of the computers crashes and ceases to act as a polled client.
If people connect to the AP without frottle, essentially the collisions and packetloss appear whenever they are uploading. To discourage this, we generally firewall any non-frottle clients, using the frottle stats output in a script. Now, this doesnt stop people using the AP to repeat traffic at the MAC layer, bypassing our routed topilogy - though if this was a problem we could setup MAC filtering.
So, this system is completely succeptible to failure or circumvention. Good this is, we're all mates.
The frottle people should not say they implemented AP polling modes with a software firewall because that is not what they did!
I dont thik we ever said we did. We were quite clear that this was IP layer polling (not just traffic shaping either - it's co-ordinated).
Yes, we are "fakin' it", but unfortunately that is all we have to work with. Karnet, with their expertise and budget, have true AP polling with their Turbocell system.
Now, we dont claim to be RF experts, but from what I can determine our example IS a hidden node scenario - we have many geographically remote clients, connecting to the AP with directional antennas. Those clients are unable to hear each others transmissions, and hence are unable effect propper collision avoidance.
Even better - use an algae suspension to produce glucose from the sun, then convert that glucose to electrical enercy.
There you go - a natural solar panel!
Frottle was released last week on e3, but we didnt want it getting slashdotted there.
I only just setup the sourceforge page yesterday (though we had it registered for some time before that).
Once upon a time, in the mystical land of Oz, there was the quiet city of Perth. Broadband was expensive (cable was only in one suburb), and ADSL was only just beginning to roll out. WiFi has just been released, and a group of enthusiasts saw the potential.
A bunch of people got together, and through many donations, were able to buy their first public WAFreenet Access Point. Now - Perth is fairly flat, with a long ridge running down one side - perfect! The AP was setup on a private property with an incerible view of the city, and we named it HillsHub (we'll call it HH).
By about 5 clients, the hidden node issue started to get noticable. Easy, they turned on RTS, and it made an improvement.
Since it had such good visibility, HH began to get pretty popular. By about 10 clients it was really stuggling, and many of those clients had AP and clients of their own adding to the routed traffic. RTS just wasnt cutting it anymore - the RTS packets are subject to collisions aswell. In a desperate effort to regain some control, rate limiting was implemented, dropping speeds back to 10kB/sec during the day to maintain some reliability. However - during the night, a free for all would occur - some people would get 100's kB/sec, whislt others would be drowned out, near complete packetloss.
By 14 clients, the situation was ridiculous. We HAD to do something. We knew Kalrnet Turbocell (a polled system) would fix it, so we sold our soul (advertising on the e3 website) and negotiated a lower price - even then we needed to fork out A$150 each. We got together and pooled the cash, and just as we were about to buy, realised that the linux support was terrible - old, buggy kernels, binary driver only. We stopped in our tracks, and wondered what to do.
There were plenty of ideas about building our own kalrnet, but none of us were kernel programmers, so it seemed a bit out of reach. That was until one day, when I came up with a plan. I'd read that iptables could send packets to a userspace program, so inspired by some examples (countertrace), I set about building the first version of frottle using perl.
There was nothing new about the concept - polled systems and token rings are common knowledge in communications and networking. It wasnt difficult - it only took me a weekend, and that included the time spent learning perl (it was my first go). It was even operating at the wrong layer - using UDP control messages to schedule IP traffic. Regardless of all it's limitations, it worked, so I got the other WAFreenet members involved with testing and development. Radix picked it up and tried to continue development with C++, but had problems. Then, ChrisK took up the challege, and the result is the dynamic, performance C version we have released.
Halfway through development, WiCCP was released. This was a similar concept, but implemented as an loadable module/interface. We liked the concept better than our userspace app, so we trialled it ourselves. One of the perth guys (Brad) even got involved with development, improving the product. Still, whislt it was an implrovement on no QoS, it didnt seem to perform quite as well as frottle. This was the decider, so ChrisK prepared frottle for release.
So, there you have it. As a developer, I've been paying attention to the comments here. Many of you have given positive feedback, and for that we're thankfull. Unfortunately, some of you have decided it would be easier to point out the flaws...
Well, no shit sherlock! We're quite aware of frottle's limitations, the concept is far from origonal, and it really is a kludge. The inherent problems of 802.11b are still there, and all we've done is work around them. The thing is, no-one else had done it before - at least not for free, and not when we started. We've spent our own time on frottle in order to improve our situation, and help the performance of free community wireless networks the world over.
Criticise all you like, but the fact is, we have experienced an enourmous, measurable improvement to our network performance. As far as we're concerned, this is BIG news.
WiFI always has a man in the middle - it's called the AP. Client-Client always involves 2 radio hops. In our implementation, we've taken the step of shooting the packet over wired ethernet aswell, but it makes very little impact on performance. In fact, we found early on (before frottle) that it reduced packetloss).
Frottle can run in many modes, and doesnt need traffic to pass through the master, though it is more reliable to do so.
As far as Client-Client comms goes, we've always discouraged it for it's use of bandwidth, and before frottle it was the main cause of collisions. For this reason, we stick most of our resources at the master, meaning most data is only a single RF hop away.
Unfortunately, RTS/CTS is almost worthless in a situation that requires it - when you've got hidden nodes, the RTS mechanism can just as easily cause collisions.
The users of WAFreeNet (Perth, Australia) have just released some open source software (frottle) to combat this. Essentially it provides a polled/token operation at the IP layer, virtually eliminating collisions. This is a similar application to WiCCP, and we've been helping/competeing with the WiCCP developers. The other alternative is Karlnet Turbocell - expensive proprietarty software, firmware and hardware, with poor linux support.
I cant post any url's now - the websites wouldnt appreciate the slashdotting. For those of you than can find the sites for yourself, it may be well worth your time.