dev/n0ll

Lekve

◄ Back

Next ►

Picture 1 of 13

Sometimes you surf around the internet, and suddenly you find something cool or interesting.
This time I came over something called Time-lapse.

From wiki;
Time-lapse photography is a cinematography technique whereby the frequency at which film frames are captured (the frame rate) is much lower than that which will be used to play the sequence back. When replayed at normal speed, time appears to be moving faster and thus lapsing.

And since we are in the planning stage of building a new house… how cool would it be to timelapse the house building?
Time to get some equipment. Silje had an old Canon 350D, but then we needed to get a new one for her……

Off to see what we could get, ended up with a brand new Canon EOS 555D.
It’s a big difference between the 350D and the 550D, and after some test picture, you can see the difference was huge! And while crawling around on the web, searching for cool things to do with the new camera, I came over something called HDR. I’ve heard about the technique before, but now I had the equipment to do it myself, check out my first HDR pictures above.

There are also some test “time-lapse” movie that will be published shortly.
(and there are even more gadgets incoming….)

Well, it wasn’t suppose to be that easy……

Getting some very mixed results.. it’s was time to get back on the test bench.
Playing around with iperf I knew that OpenVPN tunnel should be able to push enough bandwidth. Guess it was time to play around with the NFS options again…

Since I’m only interested in read speed, this is the only thing I tested.
To make variation in latency for the different test, I used only a 16MB file for testing.

Test command:

mount_nfs -o rsize=$rsize,vers=4.0alpha,ro,async,noatime $HOST://$RM /$LM
dd if=/path/to/testfile of=/dev/null bs=16k
umount /$L_mount
sleep 10

$rsize= rsize for testing (default, 1024,2048,4096,8192)
$HOST = NFS HOST
$RM = Remote NFS Mount Point
$LM = Local NFS Mount Point

Test run on a 30min interval and was doing during the night.

Initial conclusion is that I need to change my `rsize`… Will do some more testing during daytime, to see if variation in latency (usually more variation and bigger during day..) will effect the performance (it should do, but the best rsize will hopefully be the same….

It might be time to change out my low end router, a Linksys WRT54GL, witch is place between the client and internet. As you can see from the graph bellow the load is quite heavy.

I’ve been doing quite some testing earlier that evening, but you can clearly see the spikes in load when the test is do. Check the intervals just after midnight..

***UPDATE ***
Done some more testing, and here are the results

After first test, I could easily scrap 1024 and STD. But it was a close call with high rsize. It was time to check if even high size would matter.

In the second test, I also created a bigger testfile. Since the variation in speed and latency where to big to make a final conclusion.

The third test, I added yet a higher rsize. But as the results shows, I had found the highest already. When using 16384 the read speed slowed down again…..

Conclusion
mount_nfs -o rsize=12288,vers=4.0alpha,ro,async,noatime 192.168.0.1://media /mnt/media/

It’s a close call between 12288 and 8192… Not sure what is best… I’ll start using 12288 as it is slightly better on average…. Maybe I’ll do a intense test on only these to values on a later point….

This was originally a post from late February 2009, but I’ve recently got around playing with NFS over OpenVPN again… So here goes, the original post with some updates!

In my previouse post I got around fixing my speed issues with OpenVPN, now it was time to get my hands dirty with NFS. NFS is a great for LAN enviroment, but when it comes to transfer files over WAN, NFS needs to tuned! (side note: NFS should be tuned in any enviroment….)

If you have remotely touched the subject of tuning NFS, you will know that rsize/wsize and TCP vs UDP has been mention, and this article is not a exeption…. These options are vitale for tuning a NFS setup. I will not go into explaining all the different option and what they mean. I will basicly just explain how I got around tuning my setup.

In my scenario I’m only interreseted in reading performance, but the same test should work just fine for tuning write performance as well. Basicly I’m creating a dummy file using `dd`the bigger your file is, the more exact numbers you will get. But since you might be working over a slow WAN, be sensible!

The testing method

#Creating dummy file on server (will create a 64MB dummy file)
dd if=/dev/zero of=/some_path/testfile bs=8k count=8192

#Mount with or without options on client – variable as selfexplaing…
mount_nfs -o $options $server:/path $local_path

#Time a dummy file transfer on client
time dd if=$client_mount/$filename of=/dev/null bs=16k

Additionally I also started a ping between the host. This is essential, because latency has a big impact on performance.

Last time I was playing around with this, I used NFSv3, but now NFSv4 is getting more common, and it was time to tune my setup to fit NFSv4.Well first you need to setup NFSv4.

Server Setup

OpenVPN
OpenVPN Device: TUN
Protocol: UDP
MTU Size: 1500
Encryption: BF-CBC
LZO-Compression: “On”

NFS:
File: /etc/exports
V4: /mnt
/mnt/share1 -ro -network 192.168.0.0 -mask 255.255.255.0
/mnt/share2 -ro -network 192.168.0.0 -mask 255.255.255.0

Client Setup

OpenVPN
#Complete .conf file for OpenVPN Client
tls-client
client
dev tun
proto udp
tun-mtu 1500
remote xxx.xxx.xxx.xxx 1194
pkcs12 xxxxx.p12
cipher BF-CBC
verb 3
ns-cert-type server
comp-lzo

NFS:
mount command:
mount_nfs -o vers=4.0alpha,ro,async,noatime host://share1 /mnt/share1
mount_nfs -o vers=4.0alpha,ro,async,noatime host://share2 /mnt/share2

Test Results

Normal NFSv4
811 packets transmitted, 811 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 13.302/19.622/36.311/2.702 ms
67108864 bytes transferred in 734.698714 secs (91342 bytes/sec)

NFSv4 with ro,async,noatime
1176 packets transmitted, 1176 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 12.980/18.780/34.096/3.033 ms
67108864 bytes transferred in 586.729412 secs (114378 bytes/sec)

NFSv4 with ro,async,noatime and LZO-Compression
2747 packets transmitted, 2747 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 12.580/17.163/42.907/3.502 ms
67108864 bytes transferred in 427.970607 secs (156807 bytes/sec)

Same as above, just as a controll
1340 packets transmitted, 1340 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 12.447/17.406/725.741/19.685 ms
67108864 bytes transferred in 429.265232 secs (156334 bytes/sec)

This is just some raw data from my testing. The ping was started in another shell, just to get an idea on the latency while doing the proper transfer test. As

Conclusion:
I looks I’m now up at speed above 10Mbit/s…..
compared to my last result witch variated from 5-8 Mbit/s