/dev/urandom too slow on my system - Unix

This is a discussion on /dev/urandom too slow on my system - Unix ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: /dev/urandom too slow on my system

  1. /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
    #include
    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.

  2. Re: /dev/urandom too slow on my system

    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

  3. Re: /dev/urandom too slow on my system

    In article ,
    Rainer_Temme@nospam.hotmail_dot_com says...

    > dd if=/dev/urandom bs=1024 count=1024 >1m


    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.

  4. Re: /dev/urandom too slow on my system

    Rainer Temme wrote:
    > 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.


    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

+ Reply to Thread