Degrade Your Own Network

cryptonix writes: "This device seems pretty cool. it attaches to your network and allows you to degrade network preformance (for testing purposes only of course). runs on windows and supports gigabit ethernet or 10/100 networks. There's more info at emprix's site about the PacketSphere." Alright, that's funny as hell, and frankly a really good idea.

Comments

Re:worthless

[Anonymous Coward]

I don't know how to put this, but you're an idiot. Seriously.

Network tools have existed for *decades* that introduce error in networks. What are they used for?

Well, let's say you're developing software that handles _anything_ on a network. Sure would be nice to know how it behaves when packets are dropped, delayed etc. Or let's say you're closer to the wire and want to know how the router chip you're programming behaves under simulated load.

But, if you're just a CONSUMER of technology, and don't actually use it for anything useful beyond your own entertainment, then perhaps you have a point; such a device is not useful and should be left to the professionals .

Dummynet?

[CWCarlson]

It sounds like this device does exactly what the Dummynet feature in FreeBSD (and others, possibly?) does. I've been throttling back NNTP grabs by Leafnode, big downloads, and so on for a while now, to keep my WAN connection from being flooded.

Of course, it doesn't exactly run on Windows...

--- Chris

We do this with Linux.

[victim]

Well, not as complete and not as a transparent etherenet level device. We don't do reordering
or packet multiplication and the linux box functions as a router.

The relevant piece you want to use is the `packet scheduler'. There are a variety of scheduling algorithms in there. You might use a command like...

tc qdisc add dev eth0 root tbf rate 1500Kbit buffer 15Kb/8 limit 100Kb
tc qdisc add dev eth1 root tbf rate 1500Kbit buffer 15Kb/8 limit 100Kb

... to throttle your network to T1 speeds. Note that you have to do both interfaces as the scheduler works on outgoing packets only.

I used to have a custom scheduler module that was a packet loser. It turns out to be a bad idea for tcp analysis. (Consider, most of the overloaded routers we meet are running some sort of fair queueing. They are deliberately causing loss to achieve a rate limitation. When you observe packet loss, it is not the loss that causes the limitation, it is the limitation causing the loss.)

For the industrious, as of linux 2.4 I believe a packet loser is much better to implement as a firewall module. Its on my `someday when I have time' list. I also plan a latency module. Nothing like latency to expose chatty network protocols. (cough sqlnet cough, "it worked fine in the development building, I don't know why your global users are complaining" :-)

Re:some people are dumb

[segmond]

Agreed, you are dumb! Read the damn article, the device doesn't degrade network by flooding, instead, it does so by perhaps making you lose every nth packet, causing duplicate packets, adding time delays, etc. Did you even freaking read the article? This is a must have for anyone who is running a real network. Try this in a real network with firewall and IDS deployed, they will not notice, no logs or alarms setting off, real life simulation. Sheesh, some people are dumb, people like you.

A good device for testing LAN/WAN

[sergente]

Having worked on some big LAN/WAN implementations in the past I can say I'd have liked to have this device. The features allow you to emulate "what'd happen if..." - always nice when you're setting up a few hundred workstations on a WAN and some Induhvidual says that a 1Mb dedicated line is sufficient : )

Looks expensive

[selectspec]

Wouldn't an AOL subscription be alot cheaper?

Re:Looks expensive

[angry old man]

Bagh,

Back in my day we didn't AOL or all of this fancy schmancy network performance degraders. If we wanted to slow down network performance, we would just hold the phone handset about 2 inches away from the modem cradle and then loudly shout. Nowadays, all you lazy kids with your fast 100 Mb connections complain when quake 3 doesn't get a ping rate less than 50. If it wasn't for all that wasted bandwidth, the internet would still be only used for DoD research like it was intended, and like any hardworking network should be used for.

Bagh!

For their purposes, it makes sense.

[BierGuzzl]

The purpose seems to be for testing that VoIP technology, for which nifty little controls on a windows desktop, to adjust latency, throughput, packet loss, etc are really useful. As it turns out, VoIP requires really good network quality to actually function properly.

So for applications that send large amounts of data, without much cpu overhead and harddrive io overhead, this gizmo is great -- but not for those situations where network load is also accompanied by high cpu load as well as many harddrive accesses. In fact, I'd go so far as to say that this thing is completely useless for almost all but the most bandwidth hungry network applications.

Re:What is that for??

[Lizard_King]

for starters, you can test how your business applications will run in a stressed environment. It may be hard to imagine, but a lot of software (custom code especially) works a bit differently under stressful conditions. Think about applications that have dependencies on data from other applications...how do they react when such data takes a bit longer to arrive? btw, this is only one example out of many ;]

correction

[rtscts]

runs on windows

IS Windows...

Hell Yeah!

[number one duck]

I can work for years by hiding that gizmo somewhere at work, fixing the problem then repeating somewhere else in the building.
Woohoo!

Network degradation

[kryps]

The slashdot effect will teach them what network degradation really means. ;-) kryps

BOFHs love it!!

[Tricolor Paulista]

If you were a true BOFH, what better way to upgrade your servers than by showing your beancounters the small "deficiencies" of your current network?