/dev/urandom too slow on my system

Hello,

I've been experimenting with the Linux TCP stack in "long fat pipes"
scenarios (large delay bandwidth product).

Initially, I just ran the following command.

# dd if=/dev/zero bs=409600 count=1000 | nc -q1 10.13.13.67 6666

I got surprising results (transmitting faster than the channel's
max capacity). It seems that some VPN routers are able to perform
on-the-fly data compression.

So I turned to /dev/urandom instead of /dev/zero.

But it appears /dev/urandom is too slow to generate data at
Fast Ethernet speeds on my system:

# dd if=/dev/urandom bs=40960 count=1000 > /dev/null
1000+0 records in
1000+0 records out
40960000 bytes (41 MB) copied, 12.1306 seconds, 3.4 MB/s

Since I don't need "cryptographically-strong" randomness, I suppose
my next option would be to use stdlib's rand().

Something along the lines of...

#include <stdlib.h>
#include <unistd.h>
int main(void)
{
char buf[400];
int i;
for (i=0; i < 400; i += 4) *(int *)(buf + i) = rand();
write(STDOUT_FILENO, buf, sizeof buf);
return 0;
}

Comments? Suggestions?

Regards.

Don't forget, that /dev/random and /dev/urandom do
produce random data by doing a certain amount of cryptographic
calculations. This isn't necessarily fast.

For your purposes, it should be more than good enough to
produce say one megabyte of random data with
dd if=/dev/urandom bs=1024 count=1024 >1m

and then catenate this block again and again until
the result is large enough for your purposes.

cat 1m 1m 1m 1m 1m >5m
cat 5m 5m 5m 5m 5m >25m
cat 25m 25m 25m 25m>100m

and then finally netcat the result to
the desired destination.
If your random block is large enough, the compression
protocol in the vpn routers (very likely IP-COMP if
IPsec is involved) will not be able to take any
advantage of it.

Rainer

In article <fuss8n$9u9$1@daniel-new.mch.sbs.de>,
[email]Rainer_Temme@nospam.hotm[/email]ail_dot_com says...
[color=blue]
> dd if=/dev/urandom bs=1024 count=1024 >1m[/color]

I understood him to mean that he wants to compute the random data on the
fly as opposed to reading it from disk to avoid having the file system
and disk system limitations be the upper limit on his throughput. He
wants to choke the pipe and the disk may be slower than the disk.

HOWEVER, your suggestion still has merit as he doesn't have to write to
disk, but lay out a huge random array in memory and loop through that
instead.

--Carlos V.

Rainer Temme wrote:[color=blue]
> If your random block is large enough, the compression
> protocol in the vpn routers (very likely IP-COMP if
> IPsec is involved) will not be able to take any
> advantage of it.[/color]

If it is IP-COMP, then according to RFC 2393,

'Each IP datagram is compressed and decompressed by itself without any
relation to other datagrams ("stateless compression"), as IP
datagrams may arrive out of order or not arrive at all.'

In this case, you need only have a sequence of random bytes as large
as the largest possible datagram. So, not very large.

- Logan