Mike Miller wrote, On 08/27/10 15:00: > On Fri, 27 Aug 2010, Mr. MailingLists wrote: >> dd if=/dev/random of=175MBFile bs=1024k count=175> >> scp 175MBFile chickenclucker:~/ >> 175MBFile 100% 175MB 35.0MB/s 00:05 >> scp -C 175MBFile chickenclucker:~/ >> 175MBFile 100% 175MB 9.7MB/s 00:18 >> >> time gzip -c 175MBFile > 175MBFile.gz >> 12.513s >> 183500800 Aug 27 11:58 175MBFile >> 183556808 Aug 27 11:58 175MBFile.gz >> >> dd if=/dev/zero of=175MBFile bs=1024k count=175 >> scp 175MBFile chickenclucker:~/ >> 175MBFile 100% 175MB 35.0MB/s 00:05 >> scp -C 175MBFile chickenclucker:~/ >> 175MBFile 100% 175MB 35.0MB/s 00:05 >> >> time gzip -c 175MBFile > 175MBFile.gz >> 0m2.552s >> 183500800 Aug 27 12:03 175MBFile >> 178393 Aug 27 12:03 175MBFile.gz >> >> Interesting results and I learned something new today (I friggan love when that happens!). > > > Me too because I don't think I've ever used dd. > > Related question: I'm pretty sure there's a way to pipe the stdout to ssh > and have it transfer to /dev/null on the other end so that you can compare > speeds for arbitrarily large transfers without making files. Anyone know? > > dd if=/dev/zero bs=1024k count=4000 | ssh ... > > I think if you were to make your file much bigger, maybe several > gigabytes, you'd see a big benefit of compression. It's not a realistic > example though because your file is just the same null character repeated > a gazillion times. So, on your network, running at 250 Mbps or so, you > probably never want to use compression. > > Mike > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > I believe that would be: dd if=/dev/zero bs=1M count=1000 | ssh user at server dd of=/dev/null If you execute a command via ssh directly, it will receive any pipes that were locally assigned to ssh. e.g.: ssh user at server echo 'hello world' > response.txt This creates a response.txt file on the local system in the current directory even though the command was executed on the remote server. ssh user at server 'echo "hello world" > response.txt' This creates a response.txt file on the remote server, notice that the entire command was enclosed in 's, including the the stdout redirection. cat bigfile|gzip|ssh user at server 'gunzip|tr a-z A-Z|gzip' >bigfile.gz This is a bit ridiculous, but you can start to see some uses for all this. Assuming you have good bandwidth to a faster machine, you could offload some tasks to a remote server. Of course if that were true, you would probably be better off with netcat or /dev/tcp, as they don't have the overhead of encrypting the stream, but you would have to trust the network they are going over with your cleartext data. Chris Frederick