More days later...
Update: many of the bugs and glitches I mention below have been fixed in Docker version 8.
I was able to access the FMS server running in the VirtualBox image on my MBA but only from within the image. Couldn't access it from my browser running on my MBA.
I tried a variety of hacks. The first one was to ignore dvm/vagrant and use VB's console to change the networking setting for Adapter 1 to bridge => en2: Display Ethernet. This allowed me to set the IP address to one within my LAN and I was able to access FMS in my browser.
But this required manual intervention and I wanted the image to be as automatic as possible. So I tried editting ~/.dvm/Vagrantfile to created a public network and to set the adapter to bridge. But this caused a conflict error message to halt the startup. I tried a variety of changes and none remove the conflict.
Eventually I realised that the default setting (192.168.42.43) address is accessible to the browser running on my MBA. Not sure why I didn't check this first. Unfortunately it's not accessible by other browsers on my LAN (192.168.1.*) but it's only for development so I'm happy.
Then I used Intercity's note about flattening the Docker image. It dropped from approx. 2GB down to 750MB. Still quite large but better.
Then I tried to push the image to Docker's public repository. And I'm still trying... The upload keeps timing out, or the Docker DNS's disappear or something else.
Intercity's flattening note also shows how to export the image to a tarball and reimport it and I've at least got a tarball with which I can re-import the image as needed.
So lots of "learning experiences". I still think Docker might be the best devel tool since the cloud appeared but still many rough edges for people who use Macs.
Friday, January 24, 2014
A Dockerfile for FixMyStreet.
This is going to be a long and rambling report of how I go about writing a Dockerfile to build FixMyStreet (FMS) as an (almost) stand-alone web app. I'm making this up as I go so there will probably be lots of false turns.
Two days later...
Well, I've wasted another two days of my life in futility. It seems that, at least on my MBA, the Mac OS X client has a fatal flaw: the connection to the VirtualBox image seems to drop after about ten minutes. It took me a day to realise that it was the Mac client that was faulty. I must have run and re-run the docker build a few hundred times, trying to isolate the fault.
And then in desperation I tried dvm ssh to log in to the boot2docker image running in VirtualBox. From there I copied my Dockerfile into the login directory and ran docker build and docker run from the login shell. And it ran without dropping the connection once. D'oh!
However it wasn't plain sailing from there. The final manual instruction is to run a script which installs all the requisite Perl modules. The script uses Miyagawa's Carton module to manage all the dependencies of the 84 modules used to build FMS. I ran the script both as a Dockerfile command and by logging into the container and running the script from the commandline.
No matter what I tried, modules were failing to compile (i.e. the gcc compiler was fatally crashing). Once again I wasted many hours Googling for the error messages until I found out the unexplained gcc crashes are usually from lack of RAM. Sure enough the default RAM for the container was only 512MB. In ~/.dvm/dvm.conf on my MBA I was able to change the RAM to 1024MB (my MBA has 4GB, plenty to spare). And at last all the Perl modules compiled and installed without complaint.
Finally, there were some Postgresql initialisation commands. These can only be performed when the postgres daemon is running so I decided to echo the commandline instructions into ~/.bashrc (along with a couple of useful aliases) so that when I run the image and fire up a bash shell, the remaining initialisation is performed upon my first login. I can then manually delete the instructions and I have an initialised and running instance of FixMyStreet.
Update: .bashrc only needs to start Postgres and FMS, other initialisations are now in the Dockerfile.
Image and Dockerfile: https://index.docker.io/u/garyaj/fms/
Some preliminaries
I'm developing using Docker on my MacBook Air and deploying the image on Google Compute Engine. I installed the following on my MBA:
- VirtualBox
- Vagrant
- dvm (installs and fires up boot2docker, a minimal Linux image in VirtualBox and runs docker in daemon mode)
- Docker client for Mac OS X (connects to docker daemon running in VirtualBox, WARNING: Client is faulty, see below)
- FixMyStreet (git clone --recursive https://github.com/mysociety/fixmystreet.git)
In the fixmystreet repository there is a Debian install script: commonlib/bin/install-site.sh, which I "translated" into Dockerfile commands as much as I was able to.
Then I followed the FMS manual installation instructions but once again I translated them to the equivalent Dockerfile instruction.
Two days later...
Well, I've wasted another two days of my life in futility. It seems that, at least on my MBA, the Mac OS X client has a fatal flaw: the connection to the VirtualBox image seems to drop after about ten minutes. It took me a day to realise that it was the Mac client that was faulty. I must have run and re-run the docker build a few hundred times, trying to isolate the fault.
And then in desperation I tried dvm ssh to log in to the boot2docker image running in VirtualBox. From there I copied my Dockerfile into the login directory and ran docker build and docker run from the login shell. And it ran without dropping the connection once. D'oh!
However it wasn't plain sailing from there. The final manual instruction is to run a script which installs all the requisite Perl modules. The script uses Miyagawa's Carton module to manage all the dependencies of the 84 modules used to build FMS. I ran the script both as a Dockerfile command and by logging into the container and running the script from the commandline.
No matter what I tried, modules were failing to compile (i.e. the gcc compiler was fatally crashing). Once again I wasted many hours Googling for the error messages until I found out the unexplained gcc crashes are usually from lack of RAM. Sure enough the default RAM for the container was only 512MB. In ~/.dvm/dvm.conf on my MBA I was able to change the RAM to 1024MB (my MBA has 4GB, plenty to spare). And at last all the Perl modules compiled and installed without complaint.
Finally, there were some Postgresql initialisation commands. These can only be performed when the postgres daemon is running so I decided to echo the commandline instructions into ~/.bashrc (along with a couple of useful aliases) so that when I run the image and fire up a bash shell, the remaining initialisation is performed upon my first login. I can then manually delete the instructions and I have an initialised and running instance of FixMyStreet.
Update: .bashrc only needs to start Postgres and FMS, other initialisations are now in the Dockerfile.
Image and Dockerfile: https://index.docker.io/u/garyaj/fms/
Wednesday, January 8, 2014
One RN104 was a disaster. The perils of small sample sizes.
Netgear support over the days following my report of the problems I was having with the RN104 was awesome. They tried everything, kept me informed at all stages and eventually asked me to return the old one and get a replacement.
The replacement now has an uptime of 26 days and hasn't skipped a beat.
Moral: don't generalise based on a sample of one. (Of course I could quibble about how the faulty unit got past QA in the first place...)
The replacement now has an uptime of 26 days and hasn't skipped a beat.
Moral: don't generalise based on a sample of one. (Of course I could quibble about how the faulty unit got past QA in the first place...)
Thursday, November 21, 2013
ReadyNAS RN104 is a disaster.
You get what you pay for they say. In my upset about almost losing a year's data from my ReadyNAS NV+ I purchased an RN104, Netgear's latest version of "consumer level" NAS. I was kind of hoping that after all these years of development the system software would be more stable than that on the NV+.
After much googling and angst I was finally able to copy my data from the stalled NV+ onto my new 104 and I thought it was all plain sailing after that.
Three weeks later and I'm ready to demand my money back for the 104. It has stalled at least once a day for the past three weeks, sometimes twice, even three times. Thankfully redundancy in the disks has allowed resynching (if it doesn't stall first) so I haven't lost any data (yet) but basically I've got a very power hungry brick. Obviously its performance as a file server is very poor while it's resynching.
I don't think Netgear support has the slightest clue about why it's happening. The ReadyNAS forum is full of complaints about the stalling. I've filed a support request but so far none of the replies has indicated they have any idea why it stalls.
It might be snapshots, it might be automated backups, it might be power supply under load, it might be the anti-virus software (not enabled in my case), it might be CPU too hot under load...
At the moment my old NV+ is sitting next to the 104 looking very smug. At least it only has unrecoverable stalls once a year or so...
As an indicator of how clueless Netgear support people are, I posted a complaint on the forum about the iTunes server in OS6 being compiled to serve only Windows boxes. It serves up FLAC files with the bytes reversed for a Mac and all one hears is a deafening squeal. "Thanks for the heads up" was the reply from Netgear. They never tested it!
After much googling and angst I was finally able to copy my data from the stalled NV+ onto my new 104 and I thought it was all plain sailing after that.
Three weeks later and I'm ready to demand my money back for the 104. It has stalled at least once a day for the past three weeks, sometimes twice, even three times. Thankfully redundancy in the disks has allowed resynching (if it doesn't stall first) so I haven't lost any data (yet) but basically I've got a very power hungry brick. Obviously its performance as a file server is very poor while it's resynching.
I don't think Netgear support has the slightest clue about why it's happening. The ReadyNAS forum is full of complaints about the stalling. I've filed a support request but so far none of the replies has indicated they have any idea why it stalls.
It might be snapshots, it might be automated backups, it might be power supply under load, it might be the anti-virus software (not enabled in my case), it might be CPU too hot under load...
At the moment my old NV+ is sitting next to the 104 looking very smug. At least it only has unrecoverable stalls once a year or so...
As an indicator of how clueless Netgear support people are, I posted a complaint on the forum about the iTunes server in OS6 being compiled to serve only Windows boxes. It serves up FLAC files with the bytes reversed for a Mac and all one hears is a deafening squeal. "Thanks for the heads up" was the reply from Netgear. They never tested it!
Tuesday, October 29, 2013
Mounting Sparc-based ReadyNAS Drives on a Raspberry Pi
dbott at http://home.bott.ca/webserver/?p=306 gives a simple process for mounting ReadyNAS disks on a Linux box. Unfortunately, that Linux box is presumed to be a Debian Linux PC with at least a few spare disk trays.
In my case, my ReadyNAS NV+ stalled and wouldn't reboot. I installed the latest firmware (4.1.12) a couple of days ago and I am thus suspicious about the cause of the stalling...
However it was obvious from the way the boot process happened that the disks were OK. The NV+ simply refused to read them. I was fed up. A similar event happened just over a year ago and I am tired of this potentially complete loss of data. In the light of my experience last year I at least had a full backup on my old Drobo 1 but the backup itself took so long I was only running it monthly.
I googled for info about reading ReadyNAS Sparc disks and found the above link. I don't have a spare Linux box sitting around. I do, however, have a Raspberry Pi which was running my backups to the Drobo and was thus doing nothing.
Courtesy of dbott's notes, I realised I had to install fuse-ext2 and lvm2 on the RPi in order to read the disks. I used apt-get to install lvm2 but there didn't seem to be a .deb package for fuse-ext2.
I googled once more and found this:
http://loveraspberrypi.blogspot.com.au/2013/07/modify-raspberian-image-file-on-mac-osx.html which is actually the reverse of what I want. I want to read an ext2 disk on an RPi. This article tells how to read an RPi SD card on a Mac. However it contains the critical link to the fuse-ext2 source:
http://alperakcan.net/?open=projects&project=fuse-ext2. And then I had to install the GNU devel toolchain (apt-get install autoconf automake libtool libfuse-dev ext2fs-dev).
Finally the configure/make/install process succeeded and I thought I had plain sailing from there. I put disk 1 from the NV+ into a USB docking station and connected it to the RPi via a powered USB hub connected to one of the USB ports. Then I followed dbott's instructions. Unfortunately vgscan told me there were two disks missing from the set. Which was correct of course. I needed at least three of the four disks from the NV+ to make the virtual volume.
After a hasty visit to my local computer parts shop, I installed the remaining two disks using SATA to USB cables connected to the hub and was delighted to run vgscan and see the three disks.
Finally I ran
fuse-ext2 -o ro -o sync_read /dev/c/c /mnt/media
and was delighted to see the "unreadable" volume fully accessible with all my files listed.
In my disgust :) I went out and bought a ReadyNAS RN104. I'm quite happy with the Netgear hardware. I just hate their crappy (firm|soft)ware. So I'm hopeful that the latest firmware (OS6) will be a bit more stable than that on the NV+. I'm currently letting the RN104 format some disks and then I hope to be able to transfer all the files from the USB disks to the RN104. I'll add an update if/when it completes.
Update: Initially I tried a simple 'cp -r' from the llvm filesystem on the RPi to the RN104 filesystem. It stalled. So, realising that there was quite a high probability of the copy stalling again, I'm using rsync because it can pick up where it stopped if the llvm volume disappears, which for some reason, it seems to do occasionally. (Actually I suspect the cause of the stalling is the WD Green disks spinning down to "save power" and then not recovering quick enough when they are needed. This might also have caused the NV+ problems. Not sure how to verify this. The WD Greens are definitely not on the recommended list for the RN104.) I'm about 1/3rd through the data transfer and am listening to some of my music from the new server so it looks like I'll be able to pick up without data loss. Phew! what a relief!
Update2: I finally discovered that one of the power packs for the SATA to USB cables was faulty. Actually, the pack was OK. But two of the connecting cables were faulty. What can I expect for $20? Anyway, I swapped the mains cable and fixed the moving pin in the 12v/5v connector. And the uploads have been much more stable since. But the RPi still occasionally stalls. And I have to pull the power plug to restart the RPi and twice the SD card was corrupted. I had to re-copy the image to the SD card using dd. Restore still not completed but the most important files have copied.
In my case, my ReadyNAS NV+ stalled and wouldn't reboot. I installed the latest firmware (4.1.12) a couple of days ago and I am thus suspicious about the cause of the stalling...
However it was obvious from the way the boot process happened that the disks were OK. The NV+ simply refused to read them. I was fed up. A similar event happened just over a year ago and I am tired of this potentially complete loss of data. In the light of my experience last year I at least had a full backup on my old Drobo 1 but the backup itself took so long I was only running it monthly.
I googled for info about reading ReadyNAS Sparc disks and found the above link. I don't have a spare Linux box sitting around. I do, however, have a Raspberry Pi which was running my backups to the Drobo and was thus doing nothing.
Courtesy of dbott's notes, I realised I had to install fuse-ext2 and lvm2 on the RPi in order to read the disks. I used apt-get to install lvm2 but there didn't seem to be a .deb package for fuse-ext2.
I googled once more and found this:
http://loveraspberrypi.blogspot.com.au/2013/07/modify-raspberian-image-file-on-mac-osx.html which is actually the reverse of what I want. I want to read an ext2 disk on an RPi. This article tells how to read an RPi SD card on a Mac. However it contains the critical link to the fuse-ext2 source:
http://alperakcan.net/?open=projects&project=fuse-ext2. And then I had to install the GNU devel toolchain (apt-get install autoconf automake libtool libfuse-dev ext2fs-dev).
Finally the configure/make/install process succeeded and I thought I had plain sailing from there. I put disk 1 from the NV+ into a USB docking station and connected it to the RPi via a powered USB hub connected to one of the USB ports. Then I followed dbott's instructions. Unfortunately vgscan told me there were two disks missing from the set. Which was correct of course. I needed at least three of the four disks from the NV+ to make the virtual volume.
After a hasty visit to my local computer parts shop, I installed the remaining two disks using SATA to USB cables connected to the hub and was delighted to run vgscan and see the three disks.
Finally I ran
fuse-ext2 -o ro -o sync_read /dev/c/c /mnt/media
and was delighted to see the "unreadable" volume fully accessible with all my files listed.
In my disgust :) I went out and bought a ReadyNAS RN104. I'm quite happy with the Netgear hardware. I just hate their crappy (firm|soft)ware. So I'm hopeful that the latest firmware (OS6) will be a bit more stable than that on the NV+. I'm currently letting the RN104 format some disks and then I hope to be able to transfer all the files from the USB disks to the RN104. I'll add an update if/when it completes.
Update: Initially I tried a simple 'cp -r' from the llvm filesystem on the RPi to the RN104 filesystem. It stalled. So, realising that there was quite a high probability of the copy stalling again, I'm using rsync because it can pick up where it stopped if the llvm volume disappears, which for some reason, it seems to do occasionally. (Actually I suspect the cause of the stalling is the WD Green disks spinning down to "save power" and then not recovering quick enough when they are needed. This might also have caused the NV+ problems. Not sure how to verify this. The WD Greens are definitely not on the recommended list for the RN104.) I'm about 1/3rd through the data transfer and am listening to some of my music from the new server so it looks like I'll be able to pick up without data loss. Phew! what a relief!
Update2: I finally discovered that one of the power packs for the SATA to USB cables was faulty. Actually, the pack was OK. But two of the connecting cables were faulty. What can I expect for $20? Anyway, I swapped the mains cable and fixed the moving pin in the 12v/5v connector. And the uploads have been much more stable since. But the RPi still occasionally stalls. And I have to pull the power plug to restart the RPi and twice the SD card was corrupted. I had to re-copy the image to the SD card using dd. Restore still not completed but the most important files have copied.
Wednesday, June 19, 2013
Direct Digital Synthesis (DDS) on the GA144 (Part 2)
I found out why I couldn't get two nodes to run with my start script. I was too impatient. I'd forgot that I had the serial connection to the Eval board running at only 115kbps. The command to install the code in the various nodes visits all the nodes and it was simply taking forever and I assumed the IDE had stalled.
Anyway, I took the delay word out of node 617 and put a simple counting loop in node 616 which asserts the 'right' port (which is common to the nodes) when the loop finishes. Then node 617 waits till its 'right' port is asserted, then continues with code to load the sine value into the DAC port.
This makes the sine wave much more stable. With the value of 500 in the go loop the sine wave is precisely 799.9Hz and stays rock solid on that value. I doubt if a crystal would make it much more stable but I'll try a crystal next.
With the following code, make sure 866 and 868 are loaded in block 200 to ensure they are compiled. Then '870 load' will start the app.
866 list
Anyway, I took the delay word out of node 617 and put a simple counting loop in node 616 which asserts the 'right' port (which is common to the nodes) when the loop finishes. Then node 617 waits till its 'right' port is asserted, then continues with code to load the sine value into the DAC port.
This makes the sine wave much more stable. With the value of 500 in the go loop the sine wave is precisely 799.9Hz and stays rock solid on that value. I doubt if a crystal would make it much more stable but I'll try a crystal next.
With the following code, make sure 866 and 868 are loaded in block 200 to ensure they are compiled. Then '870 load' will start the app.
866 list
sine wave generator,617 node 0 org,0 , 40 , 80 , 120 , 170 ,,220 , 280 , 370 , 511 ,,hart 3300; -.00433 .07943 -.64589 1.57079,cos tri 2* 2* . triangle dup *. 2 poly
-281 , 5203 , -42329 , 37407 ,
push drop pop *. + ;
scaled 2/ 8000 . + 8191 12 interp ;
dac! io b! 155 or !b ;
start 1f 128 phaseinc
dup dup or
begin
dup cos scaled
synch right b! @b drop
dac!
over . +
end
868 list
timer count cycles,616 node 0 org,hold for . . unext ;,ms for 27063 for . . . unext
next;start right b! 1 ms,go 500 hold !b go ;
870 list
sine wave loaderhost load loader loadusing default ide pathskill boots0 708 hook 0 -hooksetup application616 +node 616 /ram 8 /p617 +node 617 /ram 1f /p
visit sine pathpanel pause 2 ship
Tuesday, June 18, 2013
Direct Digital Synthesis (DDS) on the GA144
I wanted a simple demo of the GA144 producing sound. I found a sample DDS app for a SeaForth chip (predecessor to the GA144) but the code syntax is sufficiently different that I couldn't simply copy it.
The concept is simple enough. Calculate the values of a sine wave over a fixed time interval and load those values into a digital-to-analog converter (DAC). Connect the DAC to a loudspeaker and listen to the pretty tone.
Rather than look up tables of (co-)sine values, which can take up lots of memory, this app chooses to approximate the values at each interval using relatively fast calculations. The code takes much less room and easily fits into the limitations of the F18 nodes in the GA144.
The concept is simple enough. Calculate the values of a sine wave over a fixed time interval and load those values into a digital-to-analog converter (DAC). Connect the DAC to a loudspeaker and listen to the pretty tone.
Rather than look up tables of (co-)sine values, which can take up lots of memory, this app chooses to approximate the values at each interval using relatively fast calculations. The code takes much less room and easily fits into the limitations of the F18 nodes in the GA144.
But it took me a couple of days to understand the code. It all resolved to two words: cos and scaled. cos in turn uses three other words: triangle, poly and *. while scaled uses interp. Now I knew that each of those words is part of the GA144 ROM library. There was also an intriguing comment in cos: 'Hart, 3300'.
So I googled for 'Hart cosine' and one of the first hits was a page by Chuck Moore about sines and cosines in colorForth. This page also explained the 'Hart, 3300' comment, viz., Computer Approximations by John F Hart, Wiley 1968; function 3300. I googled for 'Computer Approximations Hart' and found that the only copy I could buy was hardcover from Amazon. However I also found a link to an electronic copy which allowed me to read the theory behind the magic numbers that turn up in the code.
cos f-f'hart 3300-0.0043 0.0794 -0.6459 0.5708
2* 2* . triangle dup *. 2 poly
-281 , 5203 , -42329 , 37407 ,
push drop pop *. + ;
The final code was this:
866 list
sine wave generator,617 node 0 org,0 , 40 , 80 , 120 , 170 ,,220 , 280 , 370 , 511 ,,hart 3300; -.00433 .07943 -.64589 1.57079,cos tri 2* 2* . triangle dup *. 2 poly
-281 , 5203 , -42329 , 37407 ,
push drop pop *. + ;
scaled 2/ 8000 . + 8191 12 interp ;dac! io b! 155 or !b ;
delay 700 1 for . . unext ;
start 22 128 phaseinc
dup dup or
begin
dup cos scaled
delay dac!
over . +
endA couple of explanations. The delay word in the original was another node running a single timing loop and raising a signal on a comms port at the end. This in turn allows the main node to synchronise with a (relatively) accurate clock signal. However I ran into problems starting multiple nodes on the chip so I brought the synch delay into the node, preferring to sacrifice some accuracy for simplicity. The constant, 700, controls the amount of delay between DAC updates and, hence, the frequency. 500 gives around 550Hz, 700 gives around 447Hz.
interp expects an interpolation table at address 0. In this case it's not quite a linear interpolation. (Refer to DB001 F18A Technology Reference for details.) scaled halves the cos value, adds 0.5 (to scale into positive numbers only) and calls interp with s and m calculated for L=16 bits and n=3 (a 9-entry table i.e. 2**3+1) to interpolate the values between 0 and 511. dac! sets the DAC value on the node.
The output of the DAC needs to connect to a resistive load. The EVB001 kit includes some 47ohm resistors so I soldered one between the DAC pin and earth and then I was able to see a (relatively) clean sine wave output on my 'scope. It also sounded like a sine wave when I connected a speaker.
Make sure block 200 contains a load of block 866 so 'compile' will include it. The block to start the app on the GA144 (copied from 9.4 of the Users Guide) is:
872 list
demo ide boot empty compile serial load
customize -canon 0 fh orgn !
a-com sport ! a-bps bps ! !nam
run talk 0 617 hook 0 64 617 boot
upd ?ram panel 22 call ;To load and run type '872 load' and 'run' in the IDE.
My next task is to get a second node working as a timer to increase the accuracy of the sine wave (possibly using a crystal?). Then I want to port another VentureForth app, Musicbox, to the GA144.
Subscribe to:
Posts (Atom)