Slashdot Mirror
Ask Slashdot: Low Cost IP-based Traffic Shaping?
Deuteron
asks: "Hi! I work for an ISP and we're about to
deploy wireless net access and need a way to limit people
to the bandwidth they pay for. We're planning on starting
out with offering 128k, 256k, and 1M links. The wireless
hardware itself
(Breezecom if you're
interested) will handle the 1M part for us. The tricky
part is the lower speeds. I've done some extensive checking
and haven't found any IP or MAC address based shapers as
of yet. Can anyone point me to some free or extremely low
cost solutions? Any leads would be greatly appreciated!"
Has anyone seen pricing on these devices? I have been thinking of getting a T1 to the home and wiring a few neighbors to cover costs. This would be a better solution. We are tired of 10k/s RR cable modems and ADSL d/c's.
Try telling that to customers paying for 1M access when you have users only paying a fraction of the price for 256K and getting the same services because the system isn't overloaded. This would also kill your ability to judge the limits of the system when you have all your slower connections connecting at top speed and coming near to your bandwidth limit when you should only be hitting 50%.
You can do that, and make your customers happy - but then why would any of them buy the 1M connection? Word will get around and suddenly you'll have everyone on 128K connections, using 1M.
Not a great way to make a profit.
Download Linux 2.2.x, and when you compile it, enable experimental and look at the QoS stuff. It does exactly what you need.
> If you want to limit traffic, then I personally would do it at the router level.
> Doing it at a OS level (like linux) is even worse.
No, the idea is to use Linux _as_ a router.
These features in the 2.2.x series that allow "shaping" - would they be useful to the end user trying to juggle various connections over, say, a PPP link? Right now it is basicly impossible for me to browse web pages while FTPing a file. I'd love to some how give my web browser priority over my FTP client. Anyone know if this sort of tweaking is possible?
It seems to me that he could limit his bandwidth going out using this, however he couldn't limit the amount of bandwidth coming in.
Actually it's pretty simple. On incoming data to an IP address you add in a slight delay. This will lower the data rates.
Ever FTPed to an overworked subnet?
Granted it might take a while to get the delay factor correct without losing connections.
Se simplest/small solution is to build
a picobsd floppy with dummynet support
in the kernel,pipes are configured as follows:
ipfw pipe NNN config bw B delay D queue Q plr P
where the bandwidth B can be expressed in bit/s, Kbit/s, Mbit/s, Bytes/s,
KBytes/s, MBytes/s , delay in milliseconds, queue size in packets or
Bytes, plr is the fraction of packets randomly dropped.
after that you just use ipfw to define:
ipfw add pipe 1 tcp from any to server 80 in via de0
ipfw add pipe 1 tcp from server 80 to any out via de0
The suggestion of allowing customers full use of the bandwidth, assuming they are not taking away bandwidth from users paying for more bandwidth, has been done before and exists today in frame relay. It just means that at certain times the available bandwidth for some users will be cut back to their respective level and others won't.
hey,
Sorry about all that, its http://www.c-spec.com
Don't you just love the internet now days, you type random numbers, and you probally get either a porn site, or someone trying to sell your something.
(not in this case, but in most cases...)
--azop
"I shot an arrow in the air, where it lands I know not where"
The way space should be looked at.
Depends on how far you need to go. I'd suggest the Cylink (now P-Com) T1/E1 products. I have some of their lower speed models and they are very nice. Basically they are spread spectrum radios with a V.35 interface that connects up to a router nicely. Go with the higher frequencies if you can see the other end from the antenna mount point. The 5.8GHz devices are a good choice for LOS paths, otherwise I would have to suggest the 900MHz devices for non-LOS. It is possible to have these work over non-LOS paths but for any distance (say 5-6 miles or so) you're going to need some high gain yagi antennas.
check out www.packeteer.com. This will do what you need it to do, although its not free/cheap.
...and him setting up his own wireless T1 is much cheaper than you.
That's assuming that he's using one base unit and several remote units attached to it. If he is smart, has the ooney, and buys one base per remote, then it's prefectly fine.
Wow... California must pay better than Texas
I thought the latest versions of LRP do this.
"It's in there"
Jim Burnes
Sure you can limit in the upstream and downstream to the internet, but unless you have hardware which supports bandwidth limits it won't work. First off all clients will have the ability to TX and RX at 1Mbps and can still saturate the channel you are using (I'm assuming 2.4GHz here). The hardware on the client end would need some sort of speed selection otherwise it really doesn't matter. Of course if it's the internet side of things you are worried about getting congested then a traffic shaper will be of some use here, but to me the biggest problem will be on the radio end. The only real suggestion I can offer would be to get new hardware that supports speed options. That's really the only way to do it and have it work well. I seriously doubt that this hardware currently exists, at least commercially. There are some cards that are speed selectable, but the problem is you need both ends to run at the same rate. Unless you put up seperate nodes for each class of bandwidth you are after that's not going to work either. I personally think commercial wireless internet services suck only because they tend to ruin the band for others. A large subscriber base would certainly do this.
Dont use shaper! use CBQ! It's new in 2.2 and does all that shaper does and much more. The only problem with CBQ is documentation, or rather, the lack thereof. But it isn't that hard...
Linux's CBQ can do more then routers and more then a lot of traffic shapping devices. It will handle the kinds of loads you are talking about with ease (I use 21264 systems to do fair queue and priorit on multiple 100Mb's streams)..
TCP/IP has some build in flags, which indicate what this packet wants (low latency or high bandswidth), so you could delay packets when a user close to his limit, and delay only those things like FTP traffic leaving Quake packets intact. Problem here is that poorly designed games don't set these bits. In is also a way out to drop packets completely ;)
...not like @Home or AOL would ever deem pedophilia as inproper use or abuse :)
Or would you like to be sued because you were using mIRC? It has an ident server (BTW, it's _standard_ on Unix-like systems too, so prohibiting it should be wrong). It also has a DCC server (doesn't matter that it uses the client connection you have open, it's a server). And I believe the ICQ client has some builtin servers too.
I'm looking at the BreezeAccess sales slander right now.
Looks pretty impressive, offering:
CIR
MIR
QoS
VLAN
RADIUS (auth and billing)
H.323 VoIP
Sectored Antennas
High Density (700 simultanious users per site)
5km to 15km coverage
1 to 3 mbps customer end
54mbps aggergrate bandwidth per access point
and
all in the unlicense 2.4ghz spectrum.
Now, it all depends on how low they can get their cost per customer end unit (sales stuff say "low cost", but we all know that means unaffordable for joe-six pack in the wireless world).
This could be the next best thing since sex.
Does anybody have more information????
Wow, that was a great piece of advice ! "Buy a Dell". I wonder if you ever bought one of their PCs or if you only read their ads ? If you need an expensive, poorly designed and ever crashing machine (we had 20 of them at the office, but had to replace half of them), yeah you should buy a Dell. Thanks for your nice advice, Chris!
Honestly who cares. I've known people who consistently run 1.2kW to 3kW on CB radio where the maximum power output is 4W. It's not really a big deal. It would cost the FCC so much to do massive "oh my god, you're running 5W on ISM, nieghborhood scans" and also be very hard to do in the first place. The antenna regulation is a joke. To be honest I think this sort of stuff comes around because of telcos and such. They don't want you to be able to communicate at high speeds without paying. I say everyone should startup or get involved in some sort of free community networking. 1W is probably OK for most situations, but not all the time. As a side note here, 902-928MHz is also a amatuer radio band as well. Hams aren't restricted to 1W. I'd also like to add that the military may use this band, although I don't know why they'd want to, at high power levels. What I'm trying to say here is, that if say 500mW over the limit, or a higher gain antenna is what is keeping you from setting up a RF link, then I know what direction I would be leaning in.
Also you might want to look into differnt switching types, such as netflow switching. Although netflow adds some overhead for things like stats gathering, it also becomes more efficent if you are going to have a large access list on an interface because it only matches the first packet in a data stream against the list, and if it passes allows the rest. Check out the CCO doccumentation for the gorey details.
The only disadvantage is that, I believe, it requires a 7200+ platform to run it on. But you'd probably have at least that as a core/backhaul router to your upstream if you're backhauling with much more than 4xT1.
Well... (not an anonymous coward, just forget my password - i'm hazard)
2.2 is _not_ a development kernel. Its a stable release.
Its up to you to decide to not trust Linux on a critical server, but it doesn't mean that your decision is right.
Linux _CAN_ be trusted. 350+ day uptimes on several of boxes I administer prove that. And QoS works fine, and its free, and under GPL. Most recommendations for BSD is to use ET/BWMGR, which is whopping $500 !! (not speaking that it comes without source)
Please, let's compare systems from a technical point of view! What I see is that most BSD opponents seem to insist that Linux is unstable and thats all. Where's the proof?
Hi,
:)
I've been working with BreezeCom units myself, for the same reason. We too wanted to do trafic shaping, for all the obvious reasons. I first tried the Linux driver, but it was not accurate, had poor performance and I had to hack the driver myself. All of that might have changed since I tried it, but I still went with FreeBSD's dummynet. It's part of the firewall, so you get full controll. You can limit bandwith based on IP, port or whatever you'd like. People tend to like the port limiter, as you can say "this ip can use 50k for web, and as much as it's like for other stuff, but combined it can not exceed 100k". That will make sure you cannot use more than 50k for telnet, and a maximum of 100k. Thus you can use f.eks 90k for ftp if there's little web trafic (10k).
Just some examples.
Oh, and you should really look at FreeBSD's cbq too
(if you want to talk to me about this, please mail me at delta@xti.org)
I know for a fact that the ability to set MIR/CIR/BURST parameters is on its way RSN.
(I've seen beta code and yes, it works well).
I only hear about breezecom.
But how about lucent's WaveLAN?
Or any other brands...
You're wrong,
BSD tcp/ip stack doesn't outperform linux one,
The proof of that is that BSD use 2 copies by packet ( with BPF use ) since LINUX just do 1 copy.
LINUX tcp/ip stack outperform BSD one.
You can use FreeBSD with ipfw and dummynet
it'll do what you need to do
http://www.freebsd.org
A lot of the tools discussed can be used to limit the maximum bandwidth used by a link. But can they be used to specify and minimum bandwidth on a link?
If you have a 1mb/s pipe to the 'net and have several machines using that link but you want to guarantee service for some applications, e.g. guarantee at least 64kb/s for real video applications. So that when someone has got a large ftp job on (e.g. downloading a Unix distribution) it doesn't destory the link for other services.
You're an idiot. Period. End of thread.
Spread spectrum doesn't have as many problems in the areas that you mention, mulitpath distortion, etc. than your typical narrowband dataradios. Building a small CSMA amplifier may be easier than you think. There are many amplifier IC modules designed specifically for this. I've seen some that would work with just 3 external components. You're right though, higher gain antennas and low power are much better than low gain+high power. Why waste the power when you don't need it. Sure i'd be pissed if someone was pumping 25W just to go 5 miles, but I don't really feel that going over the limit just a little is something to be concerned about.
A client transmitting faster then he is allowed will have his packets dropped. TCP will then back off and slow down. If they are transmitting something without congestion control, it will lose packets and not work right.
Create a CBQ node for each one and filter into them with u32.
Oops!!! That's CBQ.init that you search for at Freshmeat. And you also need to pick up the IProute2 package to get it all working.
We are doing this exact thing to offer internet service to several companies off of out T-1 connection. Class based queueing works much better than the traffic shaper. To use it, get the cbqinit script off of Freshmeat, and turn on the experimental stuff under the 2.2.x kernels to enable class based queueing. After you do this, sizing the traffic is as easy as editing a text file to mandate bandwith on a per network or per class basis. It is much easier to configure and in my opinion shapes the traffic much better than the traffic shaper.
darkdave@uwyo.edu
Posted by Vik Olliver (at home):
:v)
It depends on which country you are in. New Zealand for instance has a per Mb charge for overseas traffic.
Vik
Performing it straight on an interface shouldn't hurt too much - although I gotta admit, I've got no numbers to back me up here.
Matching per IP address is rather CPU intensive though, according to the documentation.
Dave
--
[These links are long. If they get broken, go to www.cisco.com and search for "Committed Access Rate".]
Some of the more interesting versions of the Cisco IOS (the 11.1CA and CC tree I think, and v12 if you're feeling brave) will perform incoming and outgoing traffic shaping. The closest to what you'd like is probably Committed Access Rate.
It can be applied directly to an interface to limit all IP traffic, or you can define an access list so that it will limit all traffic that matches a particular protocol, QOS flag... or your customer's IP subnet.
This last option is useful to limit a customer's access to the internet at large while still giving them full speed access to, say, your local mail or FTP server. You perform the limit on your connection to the rest of the world, using a different rate limit for each customer.
The v12.0 documentation is linked above, or check this CCO search.
Dave
--
AFAICS Breezecom offer wireless E1(or T1) links which are synchronous....
Ah, a code bigot.
:)
;) But don't talk about stability problems that don't exist because you think a particular branch of code is better, but don't have proof. That's bigotry.
I agree with you that the original code has been around forever, and that that might make it more stable... But this argument doesn't necessarily hold. Sendmail has been around forever too, but it's never been stable. Linux hasn't been around forever, but I've never had a problem with any kernel TCP/IP code.
In fact, the only kernel code I have a problem with is any new, contributed, unimportant features. I don't care if my cheap TV card doesn't work properly with my cheap video card as long as I have a working ethernet connection over my cheap ethernet card...
I don't think the Linux TCP/IP stack is a new, experimental, or partially working feature. Even if someone changed a few lines of code, that's why the development model works the way it does. Maybe if it had a problem in 2.1.1xx, it got fixed by 2.2.1, eh? That's what code freeze and stable version means.
Anyhow, if you're all gung-ho about using a "stable version", use a distribution based off of 1.2.13, or 2.0.36 or something. Or use XENIX, a true SYSV derivative.
pb Reply or e-mail; don't vaguely moderate.
The Breezecom stuff is directional point-to-point, and not shared, so it's perfectly safe to sell the whole bandwidth of a connection.
It is not very known, but sophisticated QoS and ;)
t ing/ and download latest iproute from there.
bandwidth limiting is available in 2.2. Try going to Networking options->QoS and fair queuing in kernel configuration and I'm sure you'll see lots of options with hard-to-understand descriptions
For the software and docs, go to ftp://ftp.proxad.net/mirrors/ftp.inr.ac.ru/ip-rou
It is not very known, but sophisticated QoS and ;)
t ing/ and download latest iproute from there.
bandwidth limiting is available in 2.2. Try going to Networking options->QoS and fair queuing in kernel configuration and I'm sure you'll see lots of options with hard-to-understand descriptions
For the software and docs, go to ftp://ftp.proxad.net/mirrors/ftp.inr.ac.ru/ip-rou
First of all, as far as I remember bwmgr is available for Linux now as well.
Secondly, I use Linux 2.2 and QoS on several routers, with not-so-good hardware. How unmature it may be, it works.
And finally, I think you do advocacy in a wrong way. I dont have anything *BSD, but advocacy like this doesn't encourage me to try it. If you wrote a couple of advantages of what FreeBSD has now and how do you use IMHO it would give a much better effect.
As I recall this a kernel feature in Linux now, in the 2.2.x series...please correct me if i am mistaken...I have not seen any information on implementing this however...
The Terminus Group / Jeep Geekgirl (o)|||(o)
Having read all of the above comments I feel that I should let you know how we are doing it here.
Initially, all connections will be run as fast as the network can run. ie a 128k link will run as fast as a 1mb link until we have enough customers to justify an upgrade of our central router.
We then plan the following:-
The faster connections (512k+) will all be managed at router side using the CIR functions with static information.
The slower (64k - 256k)connections will all be managed through bandwidth limiting on our Linux boxes.
I am happy to provide any further information as required.
See the traffic shaper pseudo device support in Linux-2.2.x. According to it's documentation it can shape from about 9600 to 256kb per pseudo-device. Documentation lives at:t xt
/usr/src/linux/Documentation/networking/shaper.
You might also want to look into the Linux Firewalling code if you're going to use it for traffic shaping as well. See:
filter and ipmasq.txt in the same directory.
Cheers!
J. Maynard Gelinas
You only actually need to choke the users down to what they've paid for when there is actual contention. If you let them have the full capabilities of the hardware the rest of the time, it costs you nothing and can only make them happier.
Dummynet is useful, but also available for FreeBSD is the AltQ package. This adds several additional QOS-style packet queuing disciplines, such as WFQ (weighted fair queuing) and CBQ (class-based queuing), that are bettm er to use to implement a BW/traffic shaping device.
l
See http://www.csl.sony.co.jp/person/kjc/software.htm
Here's a product that should do what you need:
http://www.etinc.com/bwmgr.htm
I would highly, highly reccommend that you use FreeBSD, especially if you are in a commercial/ISP environment. Linux is great and all but you can't beat FreeBSD's rock-solid tried-and-true TCP/IP stack. http://www.freebsd.org
good luck!
I've got a collection of all the documentation I've been able to find on the 2.2.x network stack, including the QoS stuff.
It's all at my linux 2.2 site, check it out. Hope it helps.
Yes, you can limit downstream bandwidth. Routers have QoS, the linux kernel has several shapers to choose from, etc. But upstream might be more difficult. A malicious customer could simply type ping -s 1500 -f www.somewhere.com, and flood the entire wireless link he/she was on. There isn't an easy way to fix this. You can, however, confinscate their equipment and/or report them to the FCC for causing harmful inteference if they do decide to take down the link. I know that several cablemodems use snmp to inject QoS filters at the hardware level. Maybe there's similar offerings for other NICs. It could help during an emergency, and also to help limit upstream bandwidth.
--
I want to get a T1 connection to my residence in the San Fernando Valley area of Southern California.
How good would a wireless T1 be, and how much would it cost? I'm considering a wired T1, but it's a bit pricey for an individual.
I'd also like to hear any feedback on cheaper wired T1 providers. I'm considering SoftAware - I know they're good, but $ 1,500 a month (all inclusive) is a little much.
D
----
I was under the impression that it was only
possible to set QOS on outgoing connections. The
problem here is on incoming large packets hogging
the modem line. A 1500 packet can take a significant
amount of time to receive.
I wondered about dropping the MRU to force smaller packets and
more fragmentation, but of course efficiency also drops.
- Richard.
You might want to consider offering access to the 1 meg network in an open manner, but surcharge bandwidth usage (K transfered) above a point. I assume you could use IP accounting to manage this. You could also set it up so that when a new user brings up a new machine, a program watching the ARP tables could see the dynamic ARP entry, add a firewall rule to block all requests but port 80 and DNS. Then redirect port 80 to a local page where they can "log in." After they log in, create a static ARP entry for them and tie the accounting for their IP. If you do a search, MIT has done something like this on their network.
Good Luck
Dan
I'm assuming you'll have to have the traffic shaper on the LAN side of the wireless network. This means that your QOS and bandwidth restrictions will happen on the wrong side of your wireless network. Since you're not differentiating your speeds at the wireless side, all customers will be competing for the wireless bandwidth at the same speed. I'd be pretty upset if I was paying you full price for high bandwidth but couldn't get it.
There's an introductory article in the June 1999 Linux Journal that may help...
Check out the Packeteer PacketShaper. (www.packeteer.com). I've used this product before, and it's well worth the cash you pay for it.
I don't know what kind of budget you have, but considering that you are planning on implementing this in a business, I highly suggest you go with a hardware solution. As I don't work for Packeteer, I suggest you call their sales staff for more info.
Hello there,
there's a solution available for linux 2.2.x
and freebsd 3.0.1 at:
http://www.etinc.com
The license costs $500 per MAC Addr.
It works great.
I don't know that the traffic shaper device is appropriate. It seems that it only works on a subinterface basis, which suggests the need for a single sub-interface per subscriber.
This sounds like a waste of IP addresses to me. I would also worry about the ability of the kernel to support large numbers of subinterfaces in an efficient manner.
Given the cost of a cisco, it makes sense to consider doing the QOS stuff on another box.
The previous poster suggests that you only throttle when bandwidth contention is an issue, suggesting that it will build goodwill.
I would suggest the opposite. You will certainly have a surplus of bandwidth when you roll out your service. If you open things up wide to everyone then you will probably have some very happy customers for a few months, and they will doubtless tell their friends. Soon you will have a growing customer base of people who are coming to expect more than they pay for. Then you have to start throttling down bandwidth. People are now getting less than they were getting before. Even if they are getting what they paid for, a lot of people are going to feel like they are getting shortchanged and they will start complaining vocally.
Maybe this isn't such a bad thing though. If you build a subscriber base quickly on word of mouth because you are giving away spare bandwith then you might be better off than if you build the subscriber base more slowly, or you have to advertise to build it quickly. It depends on how much the malcontents cost you once you have to start throttling connections, vs the costs of slower growth, or the costs of advertising. Unfortunately, the cost of the former is hard to predict.
As for dealing with the daily peaks of bandwidth utilization, again, I think people will tend to react better to consistant performance throughout the day or week, rather than wide fluctuations. On the other hand, if it is possible to allow maximal thruput on short (10-40k) spurts and throttle it down on longer downloas, then it becomes more difficult for people to quantify and less likely to engender ill will.
As a hard core Linux user..
The nice thing about FreeBSD is that when the docs say it supports some hardware, it really supports it. FreeBSD contains very little or no beta or prerelease code, particularly in the kernel -- unlike most GNU/Linux distributions.
The Linux and FreeBSD development models are significantly different, and neither is really better than the other. FreeBSD values rock solid stability and extensively tested code more than Linux's fast and radical growth and support for peripherals.
Personally, I use Linux because I want my workstation on the "bleeding edge" of technology, so that I know what's going on.. and so that I can use my cheap TV card with my cheap video card. I also think that the dynamic nature of the Linux kernel will assist with advancing new technologies more than the "conservative" FreeBSD. However, it is still important to advance the "old" technologies...
Both operating systems are very stable and fast, and as server OS's they both give the commercial systems a run for their money. Neither have significant stability problems. But FreeBSD is sometimes faster and it never claims to support hardware that is really only half-supported. I have not had a stability problem with either OS, but if reliability and performance were my top priority, I would at least consider FreeBSD.
People have posted very good points about the pros/cons of bandwidth limiting.
I feel that the best solution, (the one that would make ME happy) would be to allow the full bandwidth available to the client, unless things get busy. Then, you enforce a CIR, like in frame relay.
And, you make it VERY CLEAR when you sell the service that this is how things work!
Also, there are lots of posts about linux traffic shaping, and other free solutions. There are several commercial products that do this for you. One is called the iPATH. It's not horribly expensive, and allows you to do many interesting things with ethernet/IP.
Also... regarding traffic.
I am a firm believe that the proper way and the only long-term way to deal with bandwidth is to charge people based on what they use. Chare a relatively small monthly fee for the hookup, and charge a fair rate for the bandwidth used.
I get REALLY mad when I read my cablemodem contract and it says 'you can NOT run a server of ANY kind, shaw@home is for casual, home use only.
Who the heck made THEM the god of deciding what 'Internet USE' is? They provide me with a certain amount of bandwidth to my house. I can FTP things UP to people all day long.. but if I put up a server so they can request things themselves, I risk losing my connection. It is for 'attended use only'... what???
They make it out like someone who does more than surf for porn and read email is 'abusing' their service.
You know, if they chargedbased on bandwidth, they wouldn't have a problem. I would be MORE than willing to pay a fair rate for the bandwidth I use, as a tradeoff for them providing me with proper service.
Well. its like any other area of life. "If other people are breaking the laws, then the laws must not mean much, so its OK if I do it too.." kind of thinking usually dosen't work well.
:-)
There's often reasons behind the laws, that put
them there in the first place. Oh, sorry about the "its the telcos, preventing competition" bit, these restrictions have been there (in one form or other) for much longer than those current issues.
Another thing, if you are going to operate illegally and possibly interfere with other services (the real reason the rules are there), I'd pick a piece of band that DIDN'T have Hams around to notice and probably seek you out over it, rather than someplace not so traveled.
Another another thing.. being an engineer and knowlegable in radio (and a Ham), there are problems with just upping your power. Narrower bandwith (like voice) = more sensitive recievers, and better range for same power = lower data rate in data mode. Higher bandwidth = faster data rates = less sensitive recievers = less range for same power/antenna situation. Its more of a challange for hi bandwith radio. Also, and worst, is the situation of multipath, and one station interfering with many others due to too much power. Digital signals need very clean signals, typically.. noise that you can hear and understand voice with can totally obliterate a digital connection. Having signal bounce back off mountains, tall buildings, airplanes, etc. can mess up a normally clear path, and that gets worse fast with more power.
There's much to consider in something like this, too much for a short mail. Basically, low power and lots of antenna gain (which equals directivity, i.e. dishes or beams) is the better direction to go. There is a website that has a paper on these issues, written by a Ham researcher in digital high speed Ham networks, if you are really interested. I belive its called the "Higher speed Packet" page, Packet radio being the commonly used digital mode of networking.
Search on Packet Radio, high speed, to find it..
Anyway, I don't mean to say you shouldn't try something, since I really don't know the ISM laws,
it may not be a problem to add antenna gain, and leave power the same, depends on how they wrote
it up. That would work better, be cheaper, and the more directional you get the less interference you cause to whoever is your neighbors. Antennas are pretty easy and cheap to make, once you know a little bit about whats what. Get a copy of the Amateur Radio Handbook at the local library, or buy one, for starters...
Didn't mean to write a book, but didn't want to see a place where common courtesy was also the better result way to go get by..
Hope it helped...
FreeBSD has a feature called dummynet. See the
following URL: http://www.iet.unipi.it/~luigi/ip_dummynet/
His point was that linux _as_ a router is much less efficient and more error prone than a dedicated router.
I thought that there was a one (1) watt limit to the 900 MHz band, and you would need a license for anything else. Using a yagi to transmit would place 800 mW above that limit (ERP in one direction). However, just using a yagi to receive would not. Also, I don't see how you could use an amplifier legally on 900 MHz without a license.
The FCC changes rules a lot, so I am not up on all of them. The question I have, besides the 160 KHz band (again 1 watt and not enough bandwith), part 15 devices (most require FCC type approval and FCC id numbers, and only let you have milliwatts-has that changed?),
what other band besides 1 watt 900 MHz is there for high bandwith unrestricted use???
yeah, I know about light too. Just RF.
There is these little black vans with just 'FCC' on the side. I really didn't believe that they existed until I saw one with its 10 or more antenna on top.
Higher power is not a problem until you start interfering with somebody's TV set. They end up bitching to the FCC. Then the FCC sends the little black van to your area.
I never thought that they ever caught anybody. Until I saw some press clippings about some guy whose equipment was confiscated and he paid a hefty fine.
Well you say, I am not going to interfere with somebody's TV, the frequency is too high.
Then you end up interfering with somebody's cell site, or somebody's direct TV, in the future it will be TV all over again with HDTV micro signals. But I can guarantee before you interfere with any of the above, there is one thing you _will_ interfere with -
Aunt Myrtles old electric organ down the street. Every neighborhood including yours has one - an electric organ. They will pick up _any_ miss directed RF no matter the frequency. They are especially good with hi-power CB.
I personally don't use CB. I did have one once, and when I did turn it on, a couple of times. It seemed that there was this guy who would flip his multi-KW on at 8 oclock and slam my needle. Then he would go about making these weird slow throat noises with reverb mixed in.
It's those dumbshits that piss me off. I suppose I could have triangulated him quite easily with a couple of electric organs - or toasters for that matter. Then I could have stuck a needle in his coax and smoked his ass out - just never got around to it.
Just this last fourth some worker was killed when the fireworks spontaneously ignited that was being set up. It has been theorized that stray RF was to blame. My experience with the CB idiot certainly has me thinking. Frequency too high or just a little more power?? Just don't interfere with a plane's navigation system and send it down.
I think that might not be the right URL..
From www.e-spec.com:
"e-spec is a proprietary Application Framework developed specifically for building Windows* based
Product Selection Software programs"
It doesnt say a thing about wireless comm..
I also tried www.e-spec.net (doesnt exist)
and www.espec.com (something about environmental
testing labs)
Wireless Network Solutions
Check out the network management part. I know that what you are asking is very possible.
This will hurt latency, affecting online games, telnet sessions, etc. Remember, you want to limit bandwidth, but not hurt their network experience.
How about just giving them 1M burst, and charging them if they use more than their allotment over a one month period?
- =^o.o^=
Linux Router Project supports traffic shaping, although I've yet to set it up. If the breezecom routers dont do it you may be able to build a Linux router that'll traffic shape and do wireless to 2megabit too. see the Linux Wireless Router Howto
This may also be a cheap solution to some of the other replyers who were interested in wireless routers if your into DIY!
-- Greg
Slashdot, would a spell-checker for posting be too much to ask? It's not rocket science!
This sounds like an exploratory question for someone who hasn't yet come up with a business plan. Are you truly expecting to provide a huge amount of bandwidth to thousands of customers and then try to use a free linux program to enforce your ToS? I'd love to see you succeed with this, because the latest Linux kernels have some traffic shaping in them, and you could help out the coders with a real world test bed.
:-(
Why then aren't you taking advantage of Breezecom's built in Maximum Information Rate Class of Service? Do they charge too much for the management software? Have you even talked with their account reps? Their whole business is aimed at ISPs trying to do exactly this same thing. Breezecom modems emulate a serial connection, but their cheaper LAN products emulate an ethernet link. Their modems have a built in rate limiter, their LAN replacement is only aimed at office environments and not ISPs. It sounds like you have chosen the cheapest products, and are now trying to add something for nothing.
To properly implement a per user CoS, you must assign a static IP address to each end station, and possibly lock it down to a MAC address. Then you can set up a traffic shaper for each customer with little hassle. Easiest way to do is have different customers in different subnets, so all the 128k people are on one subnet, 512k on another. Rule writing is easiest that way. If you try to do CoS on systems dynamically grabbing an IP address (DHCP or equiv), you will spend all your time writing custom code to match addresses to customers to ToS to shaper rules and so on. Avoid it.
The best solution for packet shaping is Packeteer, who make a great box with a fairly good interface. The cost isn't that high compared with how much you will spend trying to implement the same thing with free software. Just buy one of their boxes and throw it in line with your ISP, then configure it a little and you can mostly forget it.
The next solution is Cisco, who have a bunch of different options built into their IOS for crude packet shaping. Presumably at some point you will have to buy a big Cisco router, probably when you get more than 50-100 customers. Since you are an ISP, what routers are you using now?
The cheap but limited solution is the latest linux kernel with IP Chains and Class Based Queueing. It should scale to handle a few subnets, each having its own CoS, but may not do 512k or higher. Crude, but should keep your bean counters happy until you have enough paying customers to afford something to cover a bigger user base.
Also check out NetBSD shaping, since I haven't yet.
No matter what you do, always enforce your bandwidth policy from the beginning, because you will lose all of your original customers later when you start to enfore the policy. Never give customers free bandwidth even if it is available, you are asking for a customer relations headache down the road if you do. Poor customer relations is the main reason small ISPs go out of business. This is the voice of experience learned the hard way
Remember, packet shaping is a one way process, if you want to limit the connection from the user back towards the internet, you have to install something at the customer end, either a small box or software on their machines. A nightmare you probably shouldn't touch.
Good luck, and tell us what solution you end up with and how it works. We geeks are a curious bunch.
the AC
Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on
http://lwn.net/1998/1119/shaper.html
I also work for an ISP using the same product. And the Station Adapters or Access points and wireless Bridges you are using have software built in that will limit the speed. We have sevral customers that on 128 k connections that work fine. If you read the manual it will tell you how.
If you are sending all the signals to a seprate building and then bouncing them down to your server room I suggest doubling up on the antennas and using the uni24 (http://www.breezecom.com/Products/ant24dbi.htm) that way it won'tbe a bottleneck
I have a setup with a few Breexe nodes, and some leased line customers.
;)
My setup is a linux box connected to the net, static routing, so that each MAC is forced to a certain IP, and then shaper, some of the connected people have a few boxes, then I just shape them all through one device, so that they share their own alloted bandwith.
Shaper (as far as I know) only shape outgoing (to the local people) trafic, had some trouble with morons uploading tons, so I use a spare box in between my "Breeze hub" box and my backbone, with lots of virtual IPs, each shaper device uses its own def route to one of the virtuals, so then I can shape both ways. Maybe not the most elegant, but it works
Check out NistNet. It should do everything you are looking for.
http://osi.ncsl.nist.gov/itg/nistnet/
Wayne Walker Unix/Linux Advocate, SysAdmin, MUD addict in remission
Perfect for low-profiling your high-traffic web server from the packet-sniffing cable modem ISPs.
Perfect when used with TCP wrapper and " DENY".
With RedHat Traffic Shapping and TCP Wrapper (for blocking ISP's port scan and compliance with AUP server ban), one can get a very fine industrial type web server that is at least accessible and suppresses your traffic profile to those below your neighbor kid's Quake Server or MP3 FTP site.
This might not be the appropriate forum but.... my company worked on this project (a traffic shaper kernel module) for over a year and we didn't have the resources to test and sell the product. The features we have implemented are a lot more advanced than what is currently in the 2.2.X kernels like: 1. Bandwidth regulation based on: IP address or ranges of IPs TCP or UDP service 2. Bursting for any or all the bandwidth shaping rules 3. Real-time bandwidth statistics 4. dynamic configuration of bandwidth shaping rules
If your intent to saturate your local market with the Breezecom product (and I hope you do) you will see a significant reduction in performance because of the dwell time that the hoppers must sit when they collide. The more hoppers, the more times that they will collide, the more frequently your clients will have dwell periods. The end result is a significant performance hit. Sadly, the solution you are looking for is automatically built into the product that you will be using.
A well developed and planned network might allow you to use the product with some limited success without too much colliding.
I am interested in learning how you will tackle some other issues.
Paul
You may contact me directly at paul@rli.net or give me a call at 580-250-4247.
www.rli.net