meteohub.de

Hello all,

I've been using meteohub on a NSLU2 for about 15 months until last weekend - mostly without any problems. The last few weeks the system got more and more unstable due to repeated corruption of the file system of the usb stick.
Because of these problems and the need (wish) of running a low power consumption PC for WsWin I decided to move on to the x86 version of meteohub.

Just last weekend I got a new Intel Atom-based Eee Box with WinXP Home as OS. I prepared everything(?) for moving meteohub from NSLU2 to the new system - but while seeing the finish line, the "old" system broke down again and breathed its last!

So, now meteohub is running(hobbling) as activated VMWare appliance in version 4.2rc6, updated directly from 4.1. I restored all settings of the old system manually, because importing the old application settings did not work properly. The current situation is:

• All sensors of the WMR 200 are available and seem to be logged correctly.
• By now the recomputation of all data of the last 15 month runs fast and the aggregated data look ok.
• Graph uploads work as well.

But there are two major issues left, I cannot find a solution/reason for:

1. Time synchronization problems: After booting the VMWare-System the meteohub time is IN time. But after a successful recomputation the meteohub system time starts to behave weird by slowing down significantly. It runs about at half the speed it should, i.e. 60 minutes in realtime is about 25 minutes for meteohub^^. It also looks like the NTP synchronisation does not work properly, here's a short snippet of ntp.log:

   Code: Select all

   28 Mar 16:32:58 ntpd[2363]: synchronized to 141.40.103.102, stratum 2
   28 Mar 16:32:58 ntpd[2363]: time reset +122.896941 s
   28 Mar 16:40:33 ntpd[2363]: synchronized to 141.40.103.102, stratum 2
   28 Mar 16:41:39 ntpd[2363]: no servers reachable
   28 Mar 16:41:57 ntpd[2363]: synchronized to 88.198.36.102, stratum 2
   28 Mar 16:43:03 ntpd[2363]: no servers reachable
   28 Mar 16:44:49 ntpd[2363]: synchronized to 141.40.103.102, stratum 2
   28 Mar 16:46:56 ntpd[2363]: synchronized to 88.198.36.102, stratum 2
   28 Mar 16:47:20 ntpd[2363]: no servers reachable
   28 Mar 16:49:19 ntpd[2363]: ntpd exiting on signal 15
   28 Mar 16:55:30 ntpd[2236]: ntpd exiting on signal 15
   28 Mar 16:55:32 ntpd[2424]: ntpd exiting on signal 15
   28 Mar 16:55:32 ntpd[2422]: ntpd exiting on signal 15
   28 Mar 17:00:55 ntpdate[2251]: step time server 192.53.103.108 offset -0.005920 sec
   28 Mar 17:00:55 ntpd[2253]: frequency initialized 0.000 PPM from /var/spool/ntp.drift
   28 Mar 17:05:14 ntpd[2253]: synchronized to 192.53.103.104, stratum 1
   28 Mar 17:05:14 ntpd[2253]: kernel time sync enabled 0001
   28 Mar 17:22:33 ntpd[2253]: no servers reachable

   I tried several different ntp-Servers -> no change.
   In the vmx-config file I tried tools.syncTime set to TRUE as well as FALSE(the default) -> no change.
   I suppose it has something to do with the VMWare-Configuration Settings, but I'm not sure with this.
2. Checksum errors:
   In meteohub.log there are now lots of checksum errors like this:

   Code: Select all

   station 0 (WMR-200), wrong checksum (00f1 vs computed 0208) for sensor model d6  in byte sequence: d6 0d 06 12 1c d9 08 00 00 00 10 f1 00

   . I never did experience that before, well, at least not in masses.

Has anyone got an idea on this?

Regards,
Max

maxrt wrote: Has anyone got an idea on this?

I had something similar from when I tried to use time sync within a VMware workstation VM, i.e. it's not specific to Meteohub.

Here's a VMware knowledge base article about it.

In short you run something on the host (i.e. eee box) to keep that on good time and turn off any time sync inside the VM, then use the VMware Tools option (mentioned in the above link) to have the VM keep itself sync'ed to time of the host.

Yes, I think you are right, although the knowledge base article you mentioned above deals with Windows as guest OS.

Unfortunately I'm a real beginner with Virtual machines and linux systems, but hey, one can never learn enough ;)
Here's what I found out so far:

1. Obviously the Debian Kernel 2.6.x has got some serious timing issues when running as guest appliance in VMWare. As I understand it has something to do with the ACPI features of the host system. For that you can find many many solution hints on the internet, but there doesn't seem to exist THE solution for the timing problem!
   So, first I fiddled around (as most solutions suggest) with the kernel boot options in meteohub's /boot/grub/menu.lst. Those many different options didn't work for itself. For some of them you would have to install the vmware-tools, but I didn't want to change the original meteohub system too much.
   
   Currently the relavant line in menu.lst looks like this:

   Code: Select all

   kernel    /boot/vmlinuz... root=/dev/hda1 ro noapic clocksource=pit acpi=no nohz=off quiet

   Most probably I wouldn't need all of the additional options, but for now I will go with that.
2. Next thing to do, was to add global options for the VMWare-Player. On the host (WinXP) I had to create a config.ini in VMWare's application data folder (in my case: C:\\Dokumente und Einstellungen\\All Users\\Anwendungsdaten\\VMware\\VMware Player). The VM has to be told to use a constant (maximum) CPU speed, because the guest OS doesn't fully support the power management features and it would not correctly read the cpu speed if the system ran on reduced processor speed.
   The latter was very obvious, when analyzing the timing on a reboot with recomputation of all collected data. During recomputation the processor was at 100% and the timing was ok. But as soon as it finished the time delay was quickly getting bigger.
   For the Intel Atom N270 the needed entries in config.ini would be:

   Code: Select all

   host.cpukHz = 1608090
   host.noTSC = TRUE
   ptsc.noTSC = TRUE
   

3. Last thing to get this fully to work, was to tell WinXP not to use the TSC (Time Stamp Counter) by adding the option "/usepmtimer" to the boot.ini.

These three settings combined together seem to work for me right now. We'll have to wait and see if it works as a longterm solution and the sweet meteohub can smoothly do its wonderful work again for a long time.

If anyone out there has more profound knowledge about this and possibly can offer some hints on how to improve my "solution" I would be very thankful :)

Regards,
Max

I am running an Asus Eee PC 701 4G here, with Ubuntu 9.10 Netbookremix on an external hard drive.

Had similar NTP problems at first with meteohub.

Here is what I did-

In Meteohub VM /boot/grub/menu.lst
kernel /boot/vmlinuz-2.6.24-etchnhalf.1-486 root=/dev/hda1 ro quiet clocksource=acpi_pm divider=10

this was recommended
Link: here

In eeePC /etc/vmware/config
host.cpuKHz = 900000

(This figure (900MHz) is assuming we have "performance" set in Eee-ctrl)

I also tried, but did not find it necessary:
In eeePC /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash notsc pmtimer"

(then update-grub)


In meteohub's /etc/ntp.conf

tinker panic 0
# generated by meteohub
#
logfile /data/log/ntp.log
driftfile /var/spool/ntp.drift

restrict 127.0.0.1
restrict default kod nomodify notrap

server 0.uk.pool.ntp.org iburst minpoll 6 maxpoll 8
server 1.uk.pool.ntp.org iburst minpoll 6 maxpoll 8
server 2.uk.pool.ntp.org iburst minpoll 6 maxpoll 8
server 3.uk.pool.ntp.org iburst minpoll 6 maxpoll 8