Free latency software for linux

Interbench is benchmark application is designed to benchmark interactivity in Linux.
Interbench is designed to measure the effect of changes in Linux kernel design or system configuration changes such as I/O scheduler, cpu and filesystem changes and options. With careful benchmarking, different hardware can be compared.
What does it do?
It is designed to emulate the cpu scheduling behaviour of interactive tasks and measure their scheduling latency and jitter. It does this with the tasks on their own and then in the presence of various background loads, both with configurable nice levels and the benchmarked tasks can be real time.
How does it work?
First it benchmarks how best to reproduce a fixed percentage of cpu usage on the machine currently being used for the benchmark. It saves this to a file and then uses this for all subsequent runs to keep the emulation of cpu usage constant.
It runs a real time high priority timing thread that wakes up the thread or threads of the simulated interactive tasks and then measures the latency in the time taken to schedule. As there is no accurate timer driven scheduling in linux the timing thread sleeps as accurately as linux kernel supports, and latency is considered as the time from this sleep till the simulated task gets scheduled.
Each benchmarked simulation runs as a separate process with its own threads, and the background load (if any) also runs as a separate process.
Enhancements:
- This release adds options to select benchmarked loads, manpages, and documentation updates.

Mixmaster is an anonymous remailer. Mixmaster is the type II remailer protocol and the most popular implementation of it.
Remailers provide protection against traffic analysis and allow sending email nonymously or pseudonymously. Mixmaster consists of both client and server installations and is designed to run on several operation systems including but not limited to *BSD, Linux and Microsoft Windows.
The current 2.9.x versions are the stable ones and widely deployed. The 3.0beta* releases are betas for the upcoming Mixmaster 3.0.
To download Mixmaster visit Sourceforges download center. Packages for the Debian GNU/Linux distribution can be found in the testing and unstable distributions on a mirror near you. Also see http://packages.debian.org/mixmaster.
For pingers and other remailer implementations see related Software.
Whats New in 2.0.4 Stable Release:
- Prefer pubring.asc over secring.pgp.
- Support an unpublished dest.alw file.
- Added MINLAT directive. Ensures randhopped messages are sent through remailers of latency of MINLAT time or greater (suggested by Steve Crook). Improved OpenSSL version checking in the Install script.
- Added Full stats download support.
- Fixed buffer overflow bug in keymgt.c
Whats New in 3.0 RC1 Development Release:
- Prefer pubring.asc over secring.pgp.
- Support an unpublished dest.alw file.
- Added MINLAT directive. Ensures randhopped messages are sent through remailers of latency of MINLAT time or greater (suggested by Steve Crook).
- Improved OpenSSL version checking in the Install script.
- Added full stats download support.
- Fixed buffer overflow bug in keymgt.c.

NetMate comes from Network Measurement and Accounting System and is a flexible and extensible network measurement tool (meter).
It can be used for accounting, delay/loss measurement, packet capturing and much more. The main advantage over other existing tools is that it can be easily extended due to its modular (class-based) structure and dynamic loadable packet processing and information export modules.
A GUI for controlling multiple meters and displaying measurement results is currently under development.
NMRSH is the NetMate Remote Shell which allows to remote control NetMate meters.
Main features:
- Flexibility and Extensibility
- Runtime loadable metric and export modules
- Modular architecture (C++ classes)
- Extensible Ruleset Format (XML-based)
- Portable Implementation
- GNU autotools
- OS tested: Linux (SuSE, Debian, Redhat), FreeBSD, Solaris
- Open Source (GPL)
- Configurable Multithreading
- IPv4 and IPv6 Support
- Multiple Classification Algorithms
- Automatic flow generation based on arbitrary packet attribute combinations
- Packet Sampling Support
- Secure Control Interface
- SSL Encryption
- Host-based Authentication (DNS, IP address)
- User-based Authentication (HTTP)
- Packet capturing using libpcap
- Support simultaneous measurement on multiple interfaces
- Currently only Ethernet, IPv4/IPv6, ICMP, TCP, UDP, data layer support
- Extensible to everything libpcap can capture
- Metric Modules
- Counter, bandwidth, jitter, port usage, packet length, RTP packet loss, packet ID generation (crc32 and md5), capture (tcpdump file), RTT (ICMP echo), text output (similar to tcpdump output), DNS latency, HTTP performance, TCP connection setup latency
- Export Modules
- Text file, binary file, SQL (under development), IPFIX (under development)
- Remote Control via Shell Tool or Standard Web Browser
- Interactive or batch processing of meter commands
Enhancements:
- Minor changes and bugfixes were made.

Satellite can track many remote machines with dynamic IP addresses in situations where public DNS services are inappropriate. Satellite can log and alert an admin immediately when a site comes online or needs attention.
The Satellite archive also includes an RPM spec file. RPM users can build a binary package ready to install by running:
rpm -tb satellite-1.0.2.tar.gz
You will find the binary rpm under /usr/src/rpm/RPMS/i386 or /usr/src/redhat/RPMS/i386.
Reasons for Satellite
Public DNS services are often used to track clients with changing IP addresses, but DNS solutions suffer from several problems:
Failure
Public DNS servers regularly fail due to overloading and system administration problems.
No notification
There is no notification when a system goes online. Instead you must poll DNS regularly to see when a system comes online.
Latency
Updating can take from several minutes to several hours before the change is made public. On systems with small idle timeouts it is often impossible to find the current IP address via DNS.
No history
Public DNS services only keep track of the current address and dont record past times or changes in a central location.
Enhancements:
- Minor code improvements. -e no longer searches PATH.
- --with-port removed. Default now found from /etc/services.
- Documentation updates

countertrace project is a userland, iptables QUEUE target handler for Linux 2.4 kernels running Netfilter, which attempts to give the illusion that there are multiple, imaginary IP hops between itself and the rest of the world.

The imaginary hops that countertrace projects also have the ability to introduce accumulative, imaginary latency.

How it works:

Netfilter provides a mechanism for passing packets for processing to a userland program, which can examine the packet and determine if it should be permitted through or dropped on the floor. countertrace utilizes this mechanism to drop received packets which have a TTL less than the number of hops its attempting to project, and then generates ICMP time-exceeded messages for those dropped packets with the source address of the bogus hop. If latency is also being simulated, the generated time-exceeded messages are queued for the specified period of time before being sent.

Requirements:

countertrace requires the NetPacket, Time::HiRes, and IPTables::IPv4::IPQueue perl modules, available from CPAN, the Net::RawSock and a Linux 2.4 kernel with iptables (CONFIG_IP_NF_IPTABLES) and QUEUE target (CONFIG_IP_NF_QUEUE) support. If latency is not being simulated, iptables TTL match support (CONFIG_IP_NF_MATCH_TTL) may also be useful.

Configuration:

The countertrace program takes only one command line argument, the name of its configuration file. To get started, the only configuration file command you need to know about is the "hop" command, which takes the form of "hop < address > [latency]". Hops must be added in the order in which they are to be simulated. Latency is accumulative -- at run time, the latency for each hop is determined by calculating the sum of all previously specified latency values. Additional configuration commands are available for specifying how much information is logged for each received packet; see the example-hops-configuration file for more information.

In addition to configuring countertrace itself, iptables must also be configured to pass packets to countertrace for processing using the iptables QUEUE target. If latency is not being simulated, the iptables TTL match support can be used to only pass packets to countertrace which have a TTL less than or equal to the number of hops being simulated. Otherwise, more than likely youll want all received packets to pass through countertrace, so that the latency will appear to be uniform when tracerouting, in addition to when transferring data. However, the danger is that if the countertrace program dies for any reason, iptables will drop any packets which would have been queued for userland processing, rendering the box unreachable to the outside world. To avoid the problem, it may be wise to specify at least one "backdoor" address from which packets will be accepted without passing through countertrace.

For an example startup script, see the example-startup-script.sh file.

Mednafen is an OpenGL command-line driven multi-system emulator with many advanced features.

Mednafen emulates the Atari Lynx, GameBoy, GameBoy Color, GameBoy Advance, NES, PC Engine (TurboGrafx 16), and SuperGrafx and has the ability to remap hotkey functions and virtual system inputs to a keyboard, a joystick, or both simultaneously.

Save states are supported, as is real-time game rewinding. Screen snapshots may be taken at the press of a button, and are saved in the popular PNG file format.

Due to the threaded model of emulation used in Mednafen, and limitations of SDL, a joystick is preferred over a keyboard to play games, as the joystick will have slightly less latency, although the latency differences may not be perceptible to most people.

SWF::Builder::Character::Sound is a SWF Sound character.

SYNOPSIS

my $sound = $mc->new_sound( ring.mp3 );
$sound->play;

This module creates SWF sound characters from MP3 or raw Microsoft WAV files.

$sound = $mc->new_sound( $filename )

loads a sound file and returns a new sound character. It supports only MP3 now.

$sound->play( [ %options ] )

plays the sound.

Options:

MovieClip => $mc, Frame => $frame

MovieClip(MC) is a parent movie clip on which the sound is played. If MC is not set, the sound is played on the movie clip in which it is defined. Frame is the frame number on which the sound is played.

Multiple => 0/1

avoids/allows multiple playing. If 0, dont start the sound if already playing.

Loop => $count

sets the loop count.

In => $in_msec, Out => $out_msec

In sets the beginning point of the sound and Out sets the last in milliseconds.

Envelope => [ $msec1, $volumelevel1, $msec2, $volumelevel2, ... ]

sets the sound envelope. Volume level is set to $volumelevel1 at $msec1, and $volumelevel2 at $msec2, ... Volume level can take a number from 0 to 32768, or a reference to the array of volume levels of left and right channels.

$sound->stop( [ MovieClip => $mc, Frame => $frame ] )

stops playing the sound. It can take MovieClip and Frame options as same as the play method.

$sound->start_streaming( [ MovieClip => $mc, Frame => $frame ] )

starts the streaming sound, which synchronizes with the movie timeline. It can take MovieClip and Frame options as same as the play method.

$sound->Latency( $msec )

sets the sound latency in milliseconds.