[Voyage-linux] Several comments on Voyage 0.75

[Jim Cromie]

2011/8/16 Edwin van Drunen <edwin at vandrunen.net>:
> Hello,
>
> I have been using Voyage since version 0.6.0 for many industrial systems and
> have been very satisfied with it. Some custom fixes were applied to previous
> versions of voyage that don't work anymore in 0.7.5 and I found several
> issues with version 0.7.5 that maybe can be easily fixed in the base image:
>
> ### Problem: CF card is /dev/sda instead of /dev/hda
> When using the voyage 0.7.5 live CD to PXE boot an Alix 2D13 board, the
> compact flash card is recognised as /dev/sda.
> The automated installer assumes the CF card to be /dev/hda and therefore the
> installer won't work. It has to be installed manually using voyage.update
> and selecting /dev/sda as the target
>
> After the installation is finished and the board has rebooted, the CF card
> is recognised as /dev/hda.
>

My fedora box sees them as sda, soekris as hda.
This has been a complete non-issue;
the install scripts read /proc/partitions, and you enter the right device.

>
> ### Timing
> I had a lot of timing issues with Voyage 0.6.5 and 0.7.0.
> The kernel (2.6.32-voyage) would complain that clocksource "tsc" was
> unstable and use "jiffies" instead. The clock would drift with several
> minutes every hour and NTP was unable to keep the clock in sync.
> Since Voyage 0.65 I added "clocksource=tsc" bootparameter to grub's menu.lst
> and combine it with NTP to keep the clock in sync and this worked well.
>

the TSC, while being more precise, is less accurate.
ie it counts faster, but can lose cycles in idle, which is what
scheduler does all the time when less than 100% busy.

This bug is present on the sc1100 cpu on my soekris, and thats
why it starts with pit, switches to TSC which should be better,
measures it and sees its not, and goes back to pit.

When scx200_hrt is initialized, its a higher-rated clocksource,
so it gets used.  If you do use it, try the ppm option, and or mhz27.
Id like to hear about drift etc using it with various options.

[    0.333722] Switching to clocksource pit
[    4.261490] Switching to clocksource tsc
[    4.943739] Clocksource tsc unstable (delta = -317270730 ns)
[    4.950186] Switching to clocksource pit
[   34.165164] Switching to clocksource scx200_hrt

> Besides that I added the following things to properly access the hardware
> clock during boot on alix boards:
> add "rtc" to '/etc/modules'
> add "HCTOSYS_DEVICE=rtc" to '/etc/default/rcS'
>
> The new kernel (2.6.38-voyage) now uses "pit" as clocksource on the Alix
> 2D13. After 10 hours the clock was 5 seconds behind. This is something that
> NTP can manage. Are there any other significant differences or advantages to
> using pit instead of tsc?
>
>
> ### Displaylink USB monitor drivers
> The "udlfb" driver module for Displaylink devices is included in kernel
> 2.6.38. It would be nice if the module could be part of the default voyage
> kernel:
> Device Drivers -> Graphics support -> Support for frame buffer devices ->
> Displaylink USB framebuffer support -> M
>
> For use if the monitor in Xorg the video driver
> "xserver-video-xorg-displaylink" is also needed, but this is not part of the
> Debian distribution. Ubuntu does have packages and source available.
> Currently I build this module on the Voyage SDK myself, but also this would
> be a good addition to the Voyage distribution.
>
>
> ### Kernel CPU optimization
> The default kernel is optimised for 486 and higher CPU's and using 586 on
> the Geode LX CPU's would make performance worse.

huh?  backwards ?

> Now there is also a Geode LX option in the kernel. Does this increase
> performance or enable features otherwise not used?
>

You can certainly build a custom kernel easily,
and benchmark it under your load.
Id be curious to see the results.