Slashdot Mirror
Simulating Network Latency?
ixmo asks: "I've just come around an interesting problem: to simulate low-bandwidth network links without buying expensive WAN simulators, I can connect two old Cisco routers back to back with serial cables, and control the bandwidth via the 'clock rate' IOS command, but how can I simulate network latency? Is there some OS tool or patch (for Linux/OpenBSD) that allows for tuning of network delay? Any hints?"
FreeBSD has dummynet; I'd guess OpenBSD has something similar.
You can get m0n0wall and stick it on random hardware. I think you then have to recompile the kernel to enable dummynet.
We use a Soekris 4501. It'll only bridge upto about 50mbit of traffic, but if you want to simulate T1 speeds it'll be fine. Beefier hardware (the soekris box is roughly a 133MHz 486) will probably let you max out at wire speed.
not even a kernel patch, a loadable module included in the base.
Network emulator
CONFIG_NET_SCH_NETEM:
Say Y if you want to emulate network delay, loss, and packet re-ordering. This is often useful to simulate networks when testing applications or protocols.
For openbsd you can throttle bandwidth right in PF.
Just cap whichever queue you want at whatever rate you want.
AMEN TO THAT. All my friends in the area and I are on Comcast (still better than DSL, considering price), and a few in particular seem to have outages every week or so. There are random incidents of packet loss every few days that cause Trillian to drop my AIM connection. It's really quite annoying, but for the price (compared to a quality T1) you can't complain much.
The NIST ATM simulator (public domain) might be useful. You need to provide some personal info to download it, but that isn't verified.
Nistnet is another tool that simulates delay.
-jim
Howabout using a traffic shaper I should do what you want.
Shaper is a traffic shaper and a packet filter for a server and for a gateway. With only limited configuration information, that are to be supplied, this script can control which and how information flow through the box.
http://www.chronox.de/
There are other ones as well type shapper at freshmeat.
Google is sometimes a very good tool for finding things like this out, without having to submit a question to Slashdot. A Google for simulating network latency and a click on the first link turns up a thread on a FreeBSD mailing list that provides the answer: Dummynet.
Dummynet can absolutely do it. Put a PC with BSD & Dummynet and two ethernet interfaces in to simulate delay/loss/BW restrictions/etc. Very configurable. You can chose which packets are affected.
Worst problem: fixed delay, not bell-curve/whatever. You can roughly approximate delay variance by several rules of varying probabilities. Also, loss is random not bursty. For most testing, this is fine.
It can take a little while to get used to configuring it. Don't forget to make it act like a network in both directions!
Connect the machines using PPP over a pair of Ricochet modems, available on eBay for a song. They include a neat little command for developers:
AT~I13 -- WAN Simulation Command and Information Display
This command enables the Ricochet modem's WAN simulation feature.
Syntax:
AT~I13
You can use this function to test various transport protocols in the presence of network delay and packet loss. This simulation only affects the modem's transport modes, i.e., LIGHT/PPP/SLIP/STREAM. If you are going to reset the WAN simulation values, then you should reboot the modem because it is not built to reset and process incoming packets at the same time. WAN simulation affects the processing of received packet, therefore, when testing the simulation needs to be set at both ends of the connection.
The incoming packets are processed in the following order. First, the drop percentage value is checked and the modem drops that N% immediately. Second, the base delay is added to a random percentage of the variable delay. Then the packet is inserted on a time ordered delivery queue. If the variable delay component is great enough, a large number of incoming packets will be reordered.
Note:
In WAN simulation, there are fewer (Time to Live) TTL expirations than in an real network because packets ending up on the delivery queue is not expiring based on the TTL value.
I don't know the science behind it, but I did used to work in a manufacturing plant for a certain very large computer manufacturer (whose name has 3 letters in it), and the part numbers for monitors for southern and northern (and in at least 1 case, equatorial) units was in fact different for precisely this reason.
To be fair though, I did try out a nothern hemisphere monitor once (I am in Australia) and don't remember noticing any difference.
There are variations between the magnetic lines of the earth all over the place though (look at a map of variations between 'true north' and 'magnetic north'), maybe a northern hemisphere monitor in the southern hemisphere would start to show discoloration at the extremes of these.
I think the degauss function of a monitor is to neutralise any magnetic field built up in the grid or mesh of the monitor, rather than do anything about the magnetic field of the earth itself.
Dummynet can absolutely do it. Put a PC with BSD & Dummynet and two ethernet interfaces in to simulate delay/loss/BW restrictions/etc. Very configurable. You can chose which packets are affected.
You betcha. At a job I previously had, supporting TCP/IP for a large Unix producer, I had a FreeBSD box set up for just this purpose. It only had one ether interface, and was in a different part of the building from the test lab, but that didn't matter; I'd use PPP over TCP to connect to the test machines.
I'd use it to test how different OSs (including our own) would handle different bandwidth*delay products, packet loss, etc. For instance, one I found out that a customer was having problems with a lossy WAN connection to an NT server. I experimented with high packet loss percentages, and changed the rules to narrow down the problem. Turns out that NT won't retransmit a FIN packet, at least not back then.
When I left that job, my coworkers insisted that I show them how to set up that box to run those kinds of experiments.
Quite an educational experience, too. It's one thing to read Richard Stevens describing congestion avoidance algorithms; it's something else to watch them in action.
simulate lightening by plugging a network cable into a 220V plug
Enter the Etherkiller.
http://snad.ncsl.nist.gov/itg/nistnet/
nuff said...
Article: http://groups.google.ca/groups?hl=en&lr=&ie=UTF-8& selm=ucggua1ghi9ic1%40corp.supernews.com&rnum= 12
Sometimes the "writing on the wall" is blood spatter...
I'm shocked no-one has posted this!
It's been in the kernel for while, though I don't know much about using it. I never bothered even looking at it (had no need) until a coworker wanted to use it (on Thursday) to do some testing and asked me about it.
Here's the chunk of Kconfig:
config NET_SCH_DELAY
tristate "Delay simulator"
depends on NET_SCHED
help
Say Y if you want to delay packets by a fixed amount of
time. This is often useful to simulate network delay when
testing applications or protocols.
To compile this driver as a module, choose M here: the module
will be called sch_delay.
Please reply to this if you have been able to get this working... the tuning parameters to tc we found give errors (and yes, we built installed the latest iproute2 tarball).
Then again, we only spent a few minutes playing with it (he had to leave).
- Preferences: Solaris 10 (servers), Ubuntu (desktops), Solaris 11 (personal servers) -
If you've got an offsite broadband connection you can stick a PPTP server on (I use PopTop, http://www.poptop.org or http://poptop.sf.net ), try making a VPN connection out to that server and then back in. I've found that operating stuff over VPN at work tends to introduce significant latency (more than running over an 802.11b wireless bridge, which is also quite noticable compared to a hardwired Ethernet connection), so if you can VPN out and back in, you should have a fair amount of latency involved. If out-and-back-in doesn't work, just in (i.e. test machine A offsite, operating via VPN, talks to test machine B which is onsite) should still introduce noticable latency.
(This does, of course, assuming that you're testing with routable protocols)
One of the reasons you have to calibrate your own monitor's picture rotation is because it is affected by the local geomagnetic field.
http://blog.nexusuk.org
I know they have it because I wrote it and conducted many of the studies while I was at USWest Advanced Technologies. Ownership transferred to MediaOne Labs when USWest split itself in two. At that time, we licensed it to a variety of other groups under the best terms I could get out of our big-company lawyers: use for whatever you want internally, modify as desired, but no redistribution. There's a patent for it, one that's quite broad and that dummynet probably infringes. MediaOne didn't care, the patent was applied for so that no one else could get one and force us to stop using our own program. For those who care about prior art arguments, TTBOMK NETSIM predates both dummynet and NIST's nistnet software. When AT&T bought MediaOne, the Labs survived but in reduced form. Licensing of NETSIM stopped, although we continued to use it internally. When Comcast bought AT&T Broadband, most of the staff at the Labs were laid off. I turned over the complete documentation, source code, and an operating NETSIM installation on my way out the door. However, I would be surprised if any of that made the trip from Denver to Philadelphia, so in all probability, the program is no longer available.
Some days I hate big corporations.
It is kind of a pain. You need to adjust QoS settings to cause congestion or delay. 2 ways: One mark the traffic you want to be delayed and then pump a bunch of traffic through the pipe at the same time. Apply QoS to the unmatched traffic (say a ttcp stream is good). This will provide a real world latency and will be hard to predict how much latency. The second way is to manually mess with the low latency queing settings for an interface (decrease queue size is one way), beware this will foobar your performace so keep a backup config or don't accidentally put the router into production. This will let you do more predictable latency tests, but you still may need a stream of data to really bork up the latency. You can always do the bandwidth command on an interface and introduce pinhole congestion as well (may add latency), but that may not be what you are looking for... and I'm sure occured to you already. -Andrew more info available on www.cisco.com http://www.cisco.com/en/US/tech/tk39/tk824/technol ogies_configuration_example09186a008009461f.shtml
and search for QoS as well, and then use the techniques in an inverse manner.