Month: January 2009

bash geeking

I am archiving my photos onto DVD’s so I thought I would be smart and create MD5 sums of the files so I could verify the DVD is still good. Except I screwed up a little. The files I created contained the following

MD5 (./034/DSC_4109.JPG) = 294b6282bfcaca127f680d88240d4192

So I had to do a little bash scripting to split the file and then compare the files, this is what I came up with

for a in `ls *.JPG`; do export MD5=`md5 -q $a`; export MD52=`cat $a.md5`; MD53=${MD5#*=}; if [ $MD5 == $MD53 ]; then echo "$MD5 $a good"; fi; done

So what should i do…..

So what should i do…..

My phone keeps locking up, not the sporadic rebooting I have come to live with in return for not being ensnared by windows mobile’s need to use a stylus for everything.

Instead it just hangs somewhere between 1xrtt and EVDO, no calls, no data, no email till I turn the radio on and off.

Should I kick the phone to the curb, and let it be another victim of Palm OS which has been due for replacement for years?

Should I try upgrading the firmware to that final verizon patch I have been ignoring?

Should I persevere and wait to see what palm is coming out with their New-ness announcement tomorrow in the hope that version 1 will be bug free and stable.

Or do I give the finger to verizon and go get an android G1 phone, with all its openness but with that uncomfortable right hand bump out when typing on the keyboard.

Network Speeds

Last night I needed to transfer a vmware image from a linux host to a windows laptop. I was surprised it took over an hour to do so considering it was on a wired network, so I decided to do some testing on my network.

I have two ubuntu linux hosts which I will be calling linux1, linux2. I also have a mac laptop (apple1), a windows laptop (win1), plus a windows vm running on the mac (win1-vm). All have onboard gigabit network interface cards and are connect to a single 10/100 24 port switch in the basement.

So the first thing to do is benchmark the network and get a baseline
linux1 to linux2

linux1:$ iperf -t 60 -c linux2
------------------------------------------------------------
Client connecting to linux2, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.1.1.50 port 45045 connected with 10.1.1.136 port 5001
[ 3] 0.0-60.1 sec 674 MBytes 94.1 Mbits/sec

and apple1 to linux2

apple1:$ iperf -t 60 -c linux2
------------------------------------------------------------
Client connecting to linux2, TCP port 5001
TCP window size: 129 KByte (default)
------------------------------------------------------------
[ 3] local 10.1.1.125 port 64143 connected with 1.1.1.136 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.0 sec 664 MBytes 92.9 Mbits/sec

Here is the output from the endpoint linux2

linux2:$ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 10.1.1.136 port 5001 connected with 10.1.1.50 port 45045
[ 4] 0.0-60.2 sec 674 MBytes 93.8 Mbits/sec
[ 5] local 10.1.1.136 port 5001 connected with 10.1.1.125 port 64143
[ 5] 0.0-60.0 sec 664 MBytes 92.9 Mbits/sec

This gives us a baseline of 92.9 Megabits to 93.8 Megabits per second, which look pretty good for a 10/100 Megabit per second switch.

Now to do some real world testing with scp
Transfer from linux2 to apple1

apple1:$ scp user@linux2:/usr/local/vm/test.vmdk .
user@linux2's password:
test.vmdk 100% 3549MB 10.5MB/s 05:39

Transfer from linux2 to linux1

linux1:$ scp user@linux2:/usr/local/vm/test.vmdk .
user@linux2's password:
test.vmdk 100% 3549MB 11.2MB/s 05:18

so we are getting 84 and 89.6 Megbits/s which are acceptable apple1's lower number might be related to having vmware fusion running on the same machine.

Now we test the same situation I had last night of transferring a file form linux2 to a windows host. I am using pscp V0.60

(win1-vm):\>pscp user@linux2:/usr/local/vm/test.vmdk .
test@linux2's password:
test.vmdk | 176000 kB | 936.2 kB/s | ETA: 01:01:34 | 4%

That gives us 0.914 Megabytes/s or 7.31 Megabits per second which is a far cry from 93.8 Megabits recorded by iperf

Putty also has a beta snapshot Version 2009-01-04:r8377 so I tried that

(win1-vm):>\pscp-b user@linux2:/usr/local/vm/test.vmdk .
user@linux2's password:
test.vmdk | 3634240 kB | 6975.5 kB/s | ETA: 00:00:00 | 100%

That gives us 6.812 Megabytes/s or 54.49 Megabits/s which is a lot better than V0.60 but still not as good as native scp to scp. The above pscp tests were on a windows vm on a mac so that might account for some of the slowness. The final test is for a transfer from linux2 to a dedicated Windows XP machine.


test.vmdk | 3634240 kB | 9665.5 kB/s | ETA: 00:00:00 | 100%

Which resulted in a respectable 9.44 Megabytes/s or 75.5 Megabits/s, still not quite as good as linux scp to scp but bearable.

So to conclude pscp V0.60 has some serious issues and should be avoided.