One issue I had to deal with recently when trying to get the Distributed.net client to work well on the empeg was the disk access. The client requires read/write access to it's buffer files all the time. My solution was to add the following to my init script:
echo "*** Creating Ramdisk ***" /sbin/mke2fs -m 0 -b 1024 -v /dev/ram1 echo "*** Mounting Ramdisk ***" /sbin/mount -t ext2 /dev/ram1 /usr/dnetc/buffers echo "*** Copying D.Net buffers to RAM ***" cp /usr/dnetc/empeg* /usr/dnetc/buffers cp /usr/dnetc/checkpoint /usr/dnetc/buffers
From there, the D.net client is set to read it's buffers off the ram drive, and it works fine. But the main problem is power loss. My solution to that is going to be a timed program the copies the files back to the disk, taking precautions to ensure a power loss during the short copy time doesn't corrupt the buffers. My questions on this whole thing are:
1. Whats an easy way to time things on the empeg via a script file? Best way I can think of is a simple loop script with a pause, but I can't figure out a pause function.
2. Is there a way that I can shrink the ramdrive? It's much bigger then I need it to be for the buffers, but the only way I have found is to recompile the kernel. Not fun if you plan on releasing something that depends on a modification to the kernel.
Thanks, Tom
Tom wrote:
- Whats an easy way to time things on the empeg via a script file? Best
way I can think of is a simple loop script with a pause, but I can't figure out a pause function.
`sleep' is probably what you're looking for, although the developer image doesn't include it. You'd either have to build your own binary or snarf a copy from the Debian ARM distribution (or bug someone else to send it to you :-)
- Is there a way that I can shrink the ramdrive? It's much bigger then I
need it to be for the buffers, but the only way I have found is to recompile the kernel. Not fun if you plan on releasing something that depends on a modification to the kernel.
Not sure about this one... I haven't played with RAM disks very much.
You're tackling an interesting problem. There are plenty of reasons to want writeable filesystems, but the possibility of power loss at any moment is a concern. I think I like the RAM disk solution, although RAM on the empeg is in pretty limited supply.
Cheers, -rob (aka Verement)
On Tue, 14 Mar 2000, Rob Leslie wrote:
Tom wrote:
- Whats an easy way to time things on the empeg via a script file? Best
way I can think of is a simple loop script with a pause, but I can't figure out a pause function.
`sleep' is probably what you're looking for, although the developer image doesn't include it. You'd either have to build your own binary or snarf a copy from the Debian ARM distribution (or bug someone else to send it to you :-)
Ahh, thanks. I wasn't sure what it was, I kept trying "delay, wait, pause, and sleep" with no luck. Sleep worked on my linux server, but I was assuming it was a part of the shell.
Next question is how do I wait for a process to stop before contuining a script? On startup, I want cenrtain things to happen while the startup sound is playing, like the setup of the ramdrive. I grabbed pidof, but for some reason my pidof /bin/pcmplay | wait just keeps on going, and the player hates to start when the pcmplay program is still going. (Almost had to reupgrade the unit to get out of a bad loop).
- Is there a way that I can shrink the ramdrive? It's much bigger then I
need it to be for the buffers, but the only way I have found is to recompile the kernel. Not fun if you plan on releasing something that depends on a modification to the kernel.
Not sure about this one... I haven't played with RAM disks very much.
You're tackling an interesting problem. There are plenty of reasons to want writeable filesystems, but the possibility of power loss at any moment is a concern. I think I like the RAM disk solution, although RAM on the empeg is in pretty limited supply.
Amazingly enough, the player is handleing it well. The ram drive, D.Net client, player and bash ran stable for 24 hours. But memory was very tight. Thats why I want the ramdrive shrunk, since I think it's wasting almost 3 megs of memory. Now that I know the command to pause, I'll write a basic thing tonight to test the stability with that running.
I still want to find out how the player deals with disk writes. Maybe with a push, we can get a developer partition allocated to us that survives the upgrade process. That way we can have similar "scratch" space that the player uses for active playlists. The empeg is definitly an open platform that needs to be exploited more, as I really want my empeg to be an in car computer that I can tweak. The AutoPC is cool in it's functionality, but I don't see a WinCE SDK being freely available anytime soon. The empeg only requires a terminal program, and has the empeg developers available for questions.
Tom
Next question is how do I wait for a process to stop before contuining a script? On startup, I want cenrtain things to happen while the startup sound is playing, like the setup of the ramdrive. I grabbed pidof, but for some reason my pidof /bin/pcmplay | wait just keeps on going, and the player hates to start when the pcmplay program is still going. (Almost had to reupgrade the unit to get out of a bad loop).
You shouldn't need to know the PID; `wait' alone will wait for all outstanding background processes (&) started with the shell to finish.
(If you need to wait for a specific process, grab the PID from $! after spawing it into the background, and give this later as an argument to `wait'.)
I still want to find out how the player deals with disk writes. Maybe with a push, we can get a developer partition allocated to us that survives the upgrade process. That way we can have similar "scratch" space that the player uses for active playlists. The empeg is definitly an open platform that needs to be exploited more, as I really want my empeg to be an in car computer that I can tweak. The AutoPC is cool in it's functionality, but I don't see a WinCE SDK being freely available anytime soon. The empeg only requires a terminal program, and has the empeg developers available for questions.
We do have such a partition already: /dev/hda2 is an (unformatted) 16MB scratch partition protected from being clobbered by upgrades.
I share your enthusiasm for turning the empeg into a development platform, and already have several thoughts about this. I'm hoping this list will give us the momentum and the means to support each other we need to do this successfully. I have more to say on this topic, but I'll save it until I think we've gathered enough audience...
Cheers, -rob
-
Rob Leslie -
Tom -
Tom Cramer