You only get that kind of performance out of a Cisco when you spend big bucks. Really, really big bucks. You figure a quad-processor Compaq with same-day service is going to be more expensive than a big Cisco router with tepid performance these days?
Fully depends on the load you plan to place on it. If you're using something with custom ASICs, it's probably a multi-gigabit switch and you're not going to beat the performance of one of those with any off-the-shelf hardware. Mind you, if your target is a Cisco 2924, then go for it... they'll only handle a little over 1Gbps of actual switched traffic...
FYI, I had a 7204 VXR and the Linux solution easily outperforms it.
Still have it, I never throw anything away...
cisco 7204VXR (NPE400) processor (revision A) with 114688K/16384K bytes of memory. Processor board ID 21280102 R7000 CPU at 350Mhz, Implementation 39, Rev 3.3, 256KB L2, 4096KB L3 Cache 4 slot VXR midplane, Version 2.1 Last reset from power-on Bridging software. X.25 software, Version 3.0.0.
PCI bus mb0_mb1 (Slots 0, 1, 3 and 5) has a capacity of 600 bandwidth points. Current configuration on bus mb0_mb1 has a total of 600 bandwidth points. This configuration is within the PCI bus capacity and is supported.
Cisco has the worst-performing L7 switches on the market until you get into the really large-dollar stuff (which they bought from another company). Use Extreme, Foundry or Big Iron and be much happier.
Cisco's routers are cheap, mostly Intel-based systems with PC-quality hardware and low performance for the dollar. If you are routing mostly Ethernet (which most do these days), you can build a multi-hundred-megabit Linux router very inexpensively and get more performance out of it than a 7x00 series Cisco router.
Bleah. This is tripe. Most Cisco routers have cheap, slow Intel processors in them.
Until you get up into the gigabit speeds, regular PC hardware is just as good or better. The only thing you have to watch for in the multi-hundred-megabit routing loads is that you don't have a lot of access control lists - which is also an issue you will run into with any router you might choose. Spending some time sizing the buffers and other kernel parameters is also important, because a stock Linux kernel is not set up to be a network core router.
I've got over 2,000 L2TP connections going into a single 2.4Ghz Intel box running Linux. Performance is significantly better than the Cisco 7204 that it replaced, and it's a lot cheaper and more flexible to support.
Now, in the multi-gigabit routing tasks, do yourself a favour and get a L7 switch with custom ASICs. Extreme, Foundry and others will be happy to sell you one. Cisco's stuff is crap, right up until you get their million dollar badasses which they bought from another party (go figure).
> If you buy in bulk, transit is availble for under $20 a Mbps.
B.S.
First, you don't mean bulk. You mean *BULK* As in, connecting to a FIX directly.
But that ignores the real costs. You also have to pay for network infrastructure and maintenance, then amortize the cost of it over some period of years. $20/mo doesn't even begin to represent the real costs, if you can find it at that price - then there's the likelihood that you are buying oversold bandwidth at that price (think: Cogent).
Motorola has its head squarely up its ass when it comes to community and its customers. They are a lumbering elephant of a company stuck in 1980s mentality.
>He set up a server in his bedroom which he gave friends accounts on to subsidize >his bandwidth addiction, and it's since grown into a respectable-sized ISP with >several full-time employees.
Your friend is an ISP's worst nightmare. Buy bandwidth cheaper than the ISP can buy it, put themselves into business and compete with a huge cost advantage.
Well, fair enough but I honestly would not have recommended anything less than SLES v9 to anyone. SUSE went through a transition period around that time and its roots have always been DEEP into the desktop side of things.
> Answer: SLES 8 was the most recent at the beginning of the study time period - > July 1, 2004
True. But a second point would be to mention that SUSE is not a server distribution. Meaning that its packages, etc. are not set up for gentle updates. Which you found out. RedHat, Debian, Libranet would have been better choices.
I have over 20 Linux servers, I didn't run into these issues. Coincidentally I've just had my first ever issue with updating GlibC (because I went from 32 to 64 bits when I did).
I usually do a kernel upgrade when glibc is upgraded, and reboot the system. That gives me a fresh environment.
>Answer: All the components used were available in the time-correct period of the >study. For example, if they installed a component in the simulated September 2004 >time period then that version was available in September 2004.
Interesting. Was this possible with Windows?
> Answer: They did know that GLIBC could break things and tries to minimize the > breakages (see study)
I read the study. To me, they looked like bumbling newbies.:)
> At that time, SLES 9 was hot off the compiler.
*nix systems almost always upgrade incrementally. It's highly doubtful that SLES 9 would be more buggy than SLES 8. The case could be made for the opposite, and you can be sure that most of SLES 9 was venerable packages going through minor point revisions. This is just the *nix way.
> Answer: Not sure there's anything to respond to here...
Ah but there is. I recently resurrected an Ultra 10 SPARC box (see above GlibC issue), which is just about as non-standard as it gets for a Linux install. I was able to install it in one afternoon, which included building a custom kernel with only the components I wanted, and updating over 600 packages to their most current versions from our Debian APT-proxy (which wasn't populated with SPARC packages, sadly). I also installed a Jabber server, Apache2 with PHP/PEAR, MySQL 5.x, DJBDNS, Courier-IMAP and compiled a few packages which aren't usually in Debian, and had it operating. I also mirrored the boot drives. All in one afternoon.
And several "experienced" Linux admins had trouble making MySQL work on SUSE?
- which chose an ancient linux distribution - which tried to use bleeding-edge software on an old OS software platform - which didn't know that glibc updates can break things - which apparently didn't upgrade the system first if that's what they had in mind - which took more than an afternoon to set up a linux system - which were stymied by basic systems administration - which appeared to be unaware of the tools available such as webmin
Wow. That's why I hire kids fresh out of highschool. They're so much more advanced than "experienced professionals" available to this guy.
OK, getting that out of the way, obviously this crew of nitwits couldn't tie their own shoes with encouragement and instructions. If I were the computing engineers involved, I wouldn't be writing any articles or letting anyone know that I failed totally to understand modern computing. Doesn't look good on the resume.
Then you'll know this virus was distributed on purpose or the core distribution was hacked and the hackers distributed it on purpose.
You'll also know that the virus isn't infecting *anything* unless you're running as root or you're using a version of kernel and glibc that have specific flaws to allow the virus to do something as a regular user. Are they using a kernel and software from 2001? Maybe, for all I know, but that's pretty irresponsable if they are.
This is such a non-issue for anyone except the stunned distributor that sent around the CDs. Not the first time it happened to the Windows world, either.
Anyone who thinks Symantec isn't acting in a *VERY* self-serving manner in the past few days worth of FUD is kidding themselves.
I kid you not, Symantec has been saying "Don't use the Mac, it's insecure! Or Linux! Or Mozilla! They're not secure, oh noes!!!"
Guess why... maybe it's because they don't have products for those operating systems... or maybe it's because there are no virii in the wild, and they haven't been able to figure out how to write good enough virii for those OS' to scare people into buying their shitty product?
You're absolutely spot-on. It's anti-capitalist and thoroughly socialist for cities to roll out wi-fi. I will stifle competition, and it will further mean that the rich will support the poor (socialism again).
So yes, "free" wi-fi is un-American. And I'm not even American.
Slashdot Mirror
If you're not paying at least $100s of dollars a month, you aren't getting any sort of guarantees.
You only get that kind of performance out of a Cisco when you spend big bucks. Really, really big bucks. You figure a quad-processor Compaq with same-day service is going to be more expensive than a big Cisco router with tepid performance these days?
Fully depends on the load you plan to place on it. If you're using something with custom ASICs, it's probably a multi-gigabit switch and you're not going to beat the performance of one of those with any off-the-shelf hardware. Mind you, if your target is a Cisco 2924, then go for it... they'll only handle a little over 1Gbps of actual switched traffic...
Certainly have heard of CEF. And have witnessed first-hand how bad it usually works in a big Internet environment.
Let's see...
--
IP CEF with switching (Table Version 271518), flags=0x0
1030 routes, 0 reresolve, 0 unresolved (0 old, 0 new), peak 3
1033 leaves, 27 nodes, 152040 bytes, 269271 inserts, 268238 invalidations
0 load sharing elements, 0 bytes, 0 references
universal per-destination load sharing algorithm, id 26B36E8A
2(0) CEF resets, 1425 revisions of existing leaves
Resolution Timer: Exponential (currently 1s, peak 1s)
2250 in-place/0 aborted modifications
refcounts: 9206 leaf, 7168 node
Adjacency Table has 888 adjacencies
2 incomplete adjacencies
--
It does speed things greatly. Load on the 2.4Ghz Linux box that replaced it is 0.07 right now, with 1800 L2TP connections.
FYI, I had a 7204 VXR and the Linux solution easily outperforms it.
Still have it, I never throw anything away...
cisco 7204VXR (NPE400) processor (revision A) with 114688K/16384K bytes of memory.
Processor board ID 21280102
R7000 CPU at 350Mhz, Implementation 39, Rev 3.3, 256KB L2, 4096KB L3 Cache
4 slot VXR midplane, Version 2.1
Last reset from power-on
Bridging software.
X.25 software, Version 3.0.0.
PCI bus mb0_mb1 (Slots 0, 1, 3 and 5) has a capacity of 600 bandwidth points.
Current configuration on bus mb0_mb1 has a total of 600 bandwidth points.
This configuration is within the PCI bus capacity and is supported.
Cisco has the worst-performing L7 switches on the market until you get into the really large-dollar stuff (which they bought from another company). Use Extreme, Foundry or Big Iron and be much happier.
Cisco's routers are cheap, mostly Intel-based systems with PC-quality hardware and low performance for the dollar. If you are routing mostly Ethernet (which most do these days), you can build a multi-hundred-megabit Linux router very inexpensively and get more performance out of it than a 7x00 series Cisco router.
Bleah. This is tripe. Most Cisco routers have cheap, slow Intel processors in them.
Until you get up into the gigabit speeds, regular PC hardware is just as good or better. The only thing you have to watch for in the multi-hundred-megabit routing loads is that you don't have a lot of access control lists - which is also an issue you will run into with any router you might choose. Spending some time sizing the buffers and other kernel parameters is also important, because a stock Linux kernel is not set up to be a network core router.
I've got over 2,000 L2TP connections going into a single 2.4Ghz Intel box running Linux. Performance is significantly better than the Cisco 7204 that it replaced, and it's a lot cheaper and more flexible to support.
Now, in the multi-gigabit routing tasks, do yourself a favour and get a L7 switch with custom ASICs. Extreme, Foundry and others will be happy to sell you one. Cisco's stuff is crap, right up until you get their million dollar badasses which they bought from another party (go figure).
> IMHO, Windows is still the better choice for a lot of people.
Yeah, but you're just some Slashdot poster.
I -honestly- had diet coke fly out my nose after seeing that headline. Thanks a lot for the burning proboscis!
> If you buy in bulk, transit is availble for under $20 a Mbps.
B.S.
First, you don't mean bulk. You mean *BULK* As in, connecting to a FIX directly.
But that ignores the real costs. You also have to pay for network infrastructure and maintenance, then amortize the cost of it over some period of years. $20/mo doesn't even begin to represent the real costs, if you can find it at that price - then there's the likelihood that you are buying oversold bandwidth at that price (think: Cogent).
Yet another run-around-and-kill-stuff "RPG" minus the role-playing!
The world will never be the same.
Motorola has its head squarely up its ass when it comes to community and its customers. They are a lumbering elephant of a company stuck in 1980s mentality.
>He set up a server in his bedroom which he gave friends accounts on to subsidize
>his bandwidth addiction, and it's since grown into a respectable-sized ISP with
>several full-time employees.
Your friend is an ISP's worst nightmare. Buy bandwidth cheaper than the ISP can buy it, put themselves into business and compete with a huge cost advantage.
Well, fair enough but I honestly would not have recommended anything less than SLES v9 to anyone. SUSE went through a transition period around that time and its roots have always been DEEP into the desktop side of things.
> Answer: SLES 8 was the most recent at the beginning of the study time period -
:)
> July 1, 2004
True. But a second point would be to mention that SUSE is not a server distribution. Meaning that its packages, etc. are not set up for gentle updates. Which you found out. RedHat, Debian, Libranet would have been better choices.
I have over 20 Linux servers, I didn't run into these issues. Coincidentally I've just had my first ever issue with updating GlibC (because I went from 32 to 64 bits when I did).
I usually do a kernel upgrade when glibc is upgraded, and reboot the system. That gives me a fresh environment.
>Answer: All the components used were available in the time-correct period of the
>study. For example, if they installed a component in the simulated September 2004
>time period then that version was available in September 2004.
Interesting. Was this possible with Windows?
> Answer: They did know that GLIBC could break things and tries to minimize the
> breakages (see study)
I read the study. To me, they looked like bumbling newbies.
> At that time, SLES 9 was hot off the compiler.
*nix systems almost always upgrade incrementally. It's highly doubtful that SLES 9 would be more buggy than SLES 8. The case could be made for the opposite, and you can be sure that most of SLES 9 was venerable packages going through minor point revisions. This is just the *nix way.
> Answer: Not sure there's anything to respond to here...
Ah but there is. I recently resurrected an Ultra 10 SPARC box (see above GlibC issue), which is just about as non-standard as it gets for a Linux install. I was able to install it in one afternoon, which included building a custom kernel with only the components I wanted, and updating over 600 packages to their most current versions from our Debian APT-proxy (which wasn't populated with SPARC packages, sadly). I also installed a Jabber server, Apache2 with PHP/PEAR, MySQL 5.x, DJBDNS, Courier-IMAP and compiled a few packages which aren't usually in Debian, and had it operating. I also mirrored the boot drives. All in one afternoon.
And several "experienced" Linux admins had trouble making MySQL work on SUSE?
...these were highly experienced Linux admins.
- which chose an ancient linux distribution
- which tried to use bleeding-edge software on an old OS software platform
- which didn't know that glibc updates can break things
- which apparently didn't upgrade the system first if that's what they had in mind
- which took more than an afternoon to set up a linux system
- which were stymied by basic systems administration
- which appeared to be unaware of the tools available such as webmin
Wow. That's why I hire kids fresh out of highschool. They're so much more advanced than "experienced professionals" available to this guy.
First of all... blue screens?
OK, getting that out of the way, obviously this crew of nitwits couldn't tie their own shoes with encouragement and instructions. If I were the computing engineers involved, I wouldn't be writing any articles or letting anyone know that I failed totally to understand modern computing. Doesn't look good on the resume.
Then you'll know this virus was distributed on purpose or the core distribution was hacked and the hackers distributed it on purpose.
You'll also know that the virus isn't infecting *anything* unless you're running as root or you're using a version of kernel and glibc that have specific flaws to allow the virus to do something as a regular user. Are they using a kernel and software from 2001? Maybe, for all I know, but that's pretty irresponsable if they are.
This is such a non-issue for anyone except the stunned distributor that sent around the CDs. Not the first time it happened to the Windows world, either.
Anyone who thinks Symantec isn't acting in a *VERY* self-serving manner in the past few days worth of FUD is kidding themselves.
I kid you not, Symantec has been saying "Don't use the Mac, it's insecure! Or Linux! Or Mozilla! They're not secure, oh noes!!!"
Guess why... maybe it's because they don't have products for those operating systems... or maybe it's because there are no virii in the wild, and they haven't been able to figure out how to write good enough virii for those OS' to scare people into buying their shitty product?
You decide. I already have.
They made it with Frontpage.
Right you are. Bandwidth is expensive.
And frankly, few sites DO have the bandwidth to really push a broadband connection.
You're absolutely spot-on. It's anti-capitalist and thoroughly socialist for cities to roll out wi-fi. I will stifle competition, and it will further mean that the rich will support the poor (socialism again).
So yes, "free" wi-fi is un-American. And I'm not even American.
You've forgotten about transparent web proxies.
I'm with you. The Debian APT package management is in every way superior to RPM in my experience.
Not mine. Worked like a charm. Version 3.3.2 on Gentoo Linux 64bit