DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • The Battle Of New Industry Standards: Is WebRTC Making Zoom Redundant?
  • The Network Attach Problem Nobody Warns You About
  • The Bandwidth Tax Nobody Warned You About
  • Part II: The Network That Doesn't Exist: Zero Trust, Service Meshes, and the Slow Death of Perimeter Security

Trending

  • The Documentation Crisis Nobody Sees: Why AI Agents Are Breaking Faster Than Humans Can Document Them
  • Amazon OpenSearch Vector Search Explained for RAG Systems
  • How to Submit a Post to DZone
  • Is the Data Warehouse Dead? 3 Patterns From Enterprise Architecture That Answer This Question
  1. DZone
  2. Data Engineering
  3. IoT
  4. Simulate Network Latency, Packet Loss, and Low Bandwidth on Mac OSX

Simulate Network Latency, Packet Loss, and Low Bandwidth on Mac OSX

By 
Joe Miller user avatar
Joe Miller
·
Dec. 15, 12 · Interview
Likes (0)
Comment
Save
Tweet
Share
17.0K Views

Join the DZone community and get the full member experience.

Join For Free

Sometimes while testing you may want to be able to simulate network latency, or packet loss, or low bandwidth. I have done this with Linux and tc/netem as well as with Shunra on Windows, but I had never done it on Mac OSX.

It turns out that Mac OSX includes ‘dummynet’ from FreeBSD which has the capability to do this WAN simulation.

Here is a quick example:

  • Inject 250ms latency and 10% packet loss on connections between my workstation and my development web server (10.0.0.1)
  • Simulate maximum bandwidth of 1Mbps
# Create 2 pipes and assigned traffic to and from our webserver to each:
$ sudo  ipfw add pipe 1 ip from any to 10.0.0.1
$ sudo  ipfw add pipe 2 ip from 10.0.0.1 to any
 
# Configure the pipes we just created:
$ sudo  ipfw pipe 1 config delay 250ms bw 1Mbit/s plr 0.1
$ sudo  ipfw pipe 2 config delay 250ms bw 1Mbit/s plr 0.1

A quick test:

$ ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: icmp_seq=0 ttl=63 time=515.939 ms
64 bytes from 10.0.0.1: icmp_seq=1 ttl=63 time=519.864 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=63 time=521.785 ms
Request timeout for icmp_seq 3
64 bytes from 10.0.0.1: icmp_seq=4 ttl=63 time=524.461 ms

Disable:

$sudo  ipfw list |grep pipe
  01900 pipe 1 ip from any to 10.13.1.133 out
  02000 pipe 2 ip from 10.13.1.133 to any in
$ sudo  ipfw delete 01900
$ sudo  ipfw delete 02000
 
# or, flush all ipfw rules, not just our pipes
$ sudo ipfw -q flush

Notice that the round-trip on the ping is ~500ms.  That is because we applied a 250ms latency to both pipes, incoming and outgoing traffic.

Our example was very simple, but you can get quite complex since “pipes” are applied to traffic using standard ipfw firewall rules.  For example, you could specify different latency based on port, host, network, etc.

Packet loss is configured with the “plr” command.  Valid values are 0 – 1.  In our example above we used 0.1 which equals 10% packetloss.

This is a very handy way for developers on Mac’s to test their applications in a variety of network environments.  And you get it for FREE.  On Windows you need to buy a commercial tool to achieve this (at least that was true the last time I looked, in 2008.)


Network Bandwidth (computing)

Published at DZone with permission of Joe Miller. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • The Battle Of New Industry Standards: Is WebRTC Making Zoom Redundant?
  • The Network Attach Problem Nobody Warns You About
  • The Bandwidth Tax Nobody Warned You About
  • Part II: The Network That Doesn't Exist: Zero Trust, Service Meshes, and the Slow Death of Perimeter Security

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook