My initial write-up is here:
Comments and corrections welcomed. There's still some work to be done.
Many, many thanks to folk in the comp.protocols.time.ntp Usenet group, without whose help this would not have been possible for this Linux novice.
-- Cheers, David Web: http://www.satsignal.eu
Interesting. Is there any particular reason why you didn't compile the ntp sources directly on the Pi? This is just a small program, it wouldn't take long to compile on the Pi.
-- Torfinn Ingolfsen, Norway
That's how I started, Torfinn, compiling on the RPi. However, it can take over 40 minutes to configure and make NTP on the RPi, and that was one of the drivers behind trying to cross-compile. I don't know why it takes so long, of whether that's just a characteristic of very portable C code and all the different options which have to be tested.
Please try it for yourself:
-- Cheers, David Web: http://www.satsignal.eu
Probably a slow SD card, by which I mean one with a low random write speed. Many Class 10 cards suffer from random write speeds of
That might be an interesting experiment to try one day, Theo. Perhaps someone will try it and let us know the results?
However, I would note that the CPU is typically at 100% when compiling NTP, which makes me suspect that disk speed isn't the major limiting factor. I'm hoping that the RPi is /not/ using programmed I/O, and is using DMA access, but I don't know.
-- Cheers, David Web: http://www.satsignal.eu
A note of caution: how are you measuring that? If it?s ?uptime? or equivalent then you can get a reported load of over 1 just from disk IO with negligible user CPU usage.
?top? can produce less misleading figures.
-- http://www.greenend.org.uk/rjk/
Richard,
Thanks for that. I'm monitoring the SNMP variable:
.1.3.6.1.2.1.25.3.3.1.2.768
with MRTG:
At the moment, that RPi is running a program which is consuming about
82% CPU according to 'top', and is doing no disk I/O at all. Compiling NTP was around either side of 13:00 UTC, and I stopped the 82% program while the compile as in progress. You can see the download from the NTP source, and the upload to my FTP server in the network I/O plots. The CPU also shows an elevated temperature when the CPU use is reported to be high.If it's wrong, I would certainly want to know.
-- Cheers, David Web: http://www.satsignal.eu
I think that variable is indeed misleading; at any rate it is in the version of netsnmp I have (5.4.3~dfsg-2.7, i.e. from Debian stable). The situation may be different if you have a more recent version.
The way it is calculated on Linux is to poll the number of ticks spent in the idle task, as reported in /proc/stat, periodically. By subtracting successive values and inverting the sense it comes up with an estimate for the time spent with the CPU busy.
But this calculation completely ignores the iowait field, so it may report a largely idle CPU as very busy if in reality it?s spending all its time waiting for IO to complete.
-- http://www.greenend.org.uk/rjk/
If I knew how to determine the version of the SNMP software I have, I could tell you what it is. The CPU use reported does correlate with CPU temperature, though.
-- Cheers, David Web: http://www.satsignal.eu
40+ minutes is a long time? Well, we sure have different views on what a long time is. I'm sure you could find something to do in that time.
-- Torfinn Ingolfsen, Norway
Compared to compiling the same source under Windows it's a grossly long time! Takes less than a couple of minutes. Compiling on an Atom FreeBSD system takes some five minutes or less.
Other programs compile much more quickly on the RPi - it seems that NTP has a configuration step which takes almost as long as the make step.
Yes, you can leave it running and come back, of course, but I prefer the almost instant response of using Delphi on a Windows system. It helps my program development.
-- Cheers, David Web: http://www.satsignal.eu
In my experience, it helps quality program development when the turnaround time of a compilation is sufficient to motivate thinking rather than trying.
We had this one a few months back, I think. You?re making a virtue of something that isn?t even a necessity any more. Sensible compile times in no way prevent you stopping and thinking about the things that you need to stop and think about.
-- http://www.greenend.org.uk/rjk/
On 12/03/2014 08:45, Rob wrote: []
In my experience, having a very long change/test cycle makes people change a lot at once, which can lead to problems. The fast development cycle means you can change a line at a time, and add debugging checks to make sure everything is working exactly as you expect.
Yes, there should be plenty of thinking before change, but then make the changes in very small, tested steps.
-- Cheers, David Web: http://www.satsignal.eu
This got me thinking. 40 minutes is a lot, so I ran it on my pi. With the usb-attached disk as the store, and an otherwise quiet system. I ran make -j 2 to get io interleaving going. I got 19 minutes 16 seconds, which is about half of the 40 minutes stated. Probably some heavy io issues with that machine.
The ntp source was ntp-4.2.6p5.tar.gz downloaded from ntp.org, with defaults to config, no hardware drivers.
Looking at this as a benckmark, the various times for this turnes up as (minutes:seconds) :
host rpi odroid wair atom trim hw rpi odroid u3 acer atom trimslice cpu speed 900Mhz 1.7Ghzx4 1.7Ghz 1.6Ghz 1.0Ghz # cpus 1 4 4 2 2 architecture arm6 arm7 x86 x86 arm7 os raspbian ubuntu ubuntu FreeBSD archlinux
tar xfz ntp..gz 0:04 0:32 0:39 0:20 0:17 sh configure 7:35 3:15 2:33 2:45 3:48 make 11:37 1:34 0:51 1:49 2:35 total 1156 s 321 s 243 s 294 s 335 s speed ratio 1.0 3.60 4.75 3.93 3.45 rpi=1 cpu power 900 6800 6800 3200 2000 mhz x cpus 1.0 7.55 7.55 3.55 2.22
Setup agains a 256G usb disk hooked up to a r-pi, re-exporting this with NFS to th odroid and the intel box. So the r-pi always does all the disk io in this benchmark. Using -j2 on the make on the rpi and
-j6 on the (4 processor) other systems, -j4 on the 2proc systems. The rpi is down to 20% idle cpu doing nfs io for the other systems during the make, at around 45% during the other two steps.
19 1/4 minutes, which is hardly bad for such a small system.The intel 4xi5 system, which is the fastest I have, is only a little less than 5 times as fast, where it has 7.5 times the rated cpu power.
Hardly worth complaining about the pi here.
-- mrr
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.