I've done some pi compiling.
I protoed the code on my twin core X86 desktop, then transferred it to the pi and compiled it. Now my desktop aint brutal - its an entry level motherboard with a twin core entry level processor, and the compilations was dine across the 100Mbps network as far as file reading and writing went - but the pi zero took about ten times as long to compile on the SD card...
-- You can get much farther with a kind word and a gun than you can with a kind word alone. Al Capone
Same here: I've just compiled the same C code on the Lenovo T440 I'm writing this on and on my Pi, one of the early 512MB model Bs. Both hosts are running the latest code versions as of last week: the T440 runs Fedora 31 and the Pi runs Buster.
The code is a set of related C programs: 15 source files, 11 header files, a total of 9213 lines including comments etc. or 251Kb of text.
Output from the compilation is a small code library and four executables.
All runs were preceded with an untimed 'make clean' run to make all timed compilations comparable. The compilations are run with make. Some of the modules are built into into a library with 'ar', and finally the four executables are linked.
Timings:
System First compile Second compile
Lenovo T440 (8GB RAM, i5, 1.9GHz) 3.86 secs 0.74 secs RPi 512MB B 23.27 secs 23.50 secs
This makes the Pi 6 times slower than the T440 on the first compilation and 32 times slower on the second.
The main difference for the first and second successive compilations is because the T440 has enough RAM to cache all the source files and compiler executables, so very little, if anything, needed to be reloaded for the second run while the Pi had to read in everything during both runs.
It would be interesting to see a similar comparison run using Pi models
2B, 3B and 4 with, ideally, 1GB and 4GB RAM.-- Martin | martin at Gregorie | gregorie dot org
I should have added that the Pi is using a 8GB Sandisk SD that's been in it almost as long as I've had it.
-- Martin | martin at Gregorie | gregorie dot org
It would be interesting to see how well the Pi performs with everything happening on a decent USB attached SSD or even over NFS. I've a suspicion that IO is hurting performance more than CPU.
-- Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/
On a sunny day (Fri, 6 Mar 2020 12:56:52 -0000 (UTC)) it happened Martin Gregorie wrote in :
On USB Hitachy harddisk connected to Pi4: raspi95: /mnt/sda2/pantel/root/compile/pantel/xgpspc # rm *.o raspi95: /mnt/sda2/pantel/root/compile/pantel/xgpspc # date;make 2>/dev/zero ;date Fri 06 Mar 2020 02:09:59 PM CET cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o xgpspc.o xgpspc.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o setup.o setup.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o sensors.o sensors.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o mpu6050.o mpu6050.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o iiclib.o iiclib.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o io.o io.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o x11.o x11.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o graphics.o graphics.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o ais.o ais.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o navigation.o navigation.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o hmc5883.o hmc5883.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o bmp180.o bmp180.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o nmea.o nmea.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o markeringen.o markeringen.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o alarms.o alarms.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o stepper.o stepper.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o udp_server.o udp_server.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o planes.o planes.c gcc -o xgpspc xgpspc.o setup.o sensors.o mpu6050.o iiclib.o io.o x11.o graphics.o ais.o navigation.o hmc5883.o bmp180.o nmea.o markeringen.o alarms.o stepper.o udp_server.o planes.o -L/usr/lib/X11 -lX11 -L/usr/lib -g -O2 -lpthread -lzorms -lm -lXpm -lcrypt -ljpeg -lXt -lXaw make 2> /dev/zero 14.91s user 1.67s system 98% cpu 16.840 total Fri 06 Mar 2020 02:10:16 PM CET
17 secondsOn cheap 32 GB disk that came with the Pi4 raspi95: ~/compile/pantel/xgpspc # rm *.o raspi95: ~/compile/pantel/xgpspc # date;make 2>/dev/zero ;date Fri 06 Mar 2020 02:12:28 PM CET cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o xgpspc.o xgpspc.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o setup.o setup.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o sensors.o sensors.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o mpu6050.o mpu6050.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o iiclib.o iiclib.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o io.o io.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o x11.o x11.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o graphics.o graphics.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o ais.o ais.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o navigation.o navigation.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o hmc5883.o hmc5883.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o bmp180.o bmp180.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o nmea.o nmea.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o markeringen.o markeringen.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o alarms.o alarms.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o stepper.o stepper.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o udp_server.o udp_server.c cc -O2 -Wall -D_FILE_OFFSET_BITS=64 -c -o planes.o planes.c gcc -o xgpspc xgpspc.o setup.o sensors.o mpu6050.o iiclib.o io.o x11.o graphics.o ais.o navigation.o hmc5883.o bmp180.o nmea.o markeringen.o alarms.o stepper.o udp_server.o planes.o -L/usr/lib/X11 -lX11 -L/usr/lib -g -O2 -lpthread -lzorms -lm -lXpm -lcrypt -ljpeg -lXt -lXaw make 2> /dev/zero 14.98s user 1.56s system 97% cpu 17.002 total Fri 06 Mar 2020 02:12:45 PM CET
also about 17 seconds
Time is mostly set by the processor speed, system is heavy loaded at the same time, cannot test on the Pi3, it runs apps now 24/7.
On my Core i5 laptop: panteltje20: ~/compile/pantel/xgpspc # rm *.o panteltje20: ~/compile/pantel/xgpspc # date;make 2>/dev/zero;date Fri Mar 6 14:16:24 CET 2020 cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o xgpspc.o xgpspc.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o setup.o setup.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o mpu6050.o mpu6050.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o sensors.o sensors.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o iiclib.o iiclib.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o io.o io.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o x11.o x11.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o graphics.o graphics.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o ais.o ais.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o navigation.o navigation.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o hmc5883.o hmc5883.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o bmp180.o bmp180.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o nmea.o nmea.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o markeringen.o markeringen.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o alarms.o alarms.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o stepper.o stepper.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o udp_server.o udp_server.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o planes.o planes.c gcc -o xgpspc xgpspc.o setup.o mpu6050.o sensors.o iiclib.o io.o x11.o graphics.o ais.o navigation.o hmc5883.o bmp180.o nmea.o markeringen.o alarms.o stepper.o udp_server.o planes.o -lm -lpthread -lXaw -ljpeg Fri Mar 6 14:16:29 CET 2020
5 seconds....slightly different makefile linked libraries, but linker time is almost zero compared to compile time.
Not bad for a Raspberry Pi4 compared to to an Intel Core i5 !
This code compiles a LOT slower on my Pi2 I remember waiting. OK, let's try on my P2: root@raspi73:~# cd compile/pantel/xgpspc root@raspi73:~/compile/pantel/xgpspc# root@raspi73:~/compile/pantel/xgpspc# rm *.o root@raspi73:~/compile/pantel/xgpspc# date; make 2>/dev/zero; date Fri Mar 6 14:24:49 CET 2020 cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o xgpspc.o xgpspc.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o setup.o setup.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o mpu6050.o mpu6050.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o sensors.o sensors.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o iiclib.o iiclib.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o io.o io.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o x11.o x11.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o graphics.o graphics.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o ais.o ais.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o navigation.o navigation.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o hmc5883.o hmc5883.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o bmp180.o bmp180.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o nmea.o nmea.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o markeringen.o markeringen.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o alarms.o alarms.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o stepper.o stepper.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o udp_server.o udp_server.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o planes.o planes.c gcc -o xgpspc xgpspc.o setup.o mpu6050.o sensors.o iiclib.o io.o x11.o graphics.o ais.o navigation.o hmc5883.o bmp180.o nmea.o markeringen.o alarms.o stepper.o udp_server.o planes.o -lm -lpthread -lXaw -ljpeg Fri Mar 6 14:34:08 CET 2020
559 seconds ? So compared to Pi4 559/17 = 32.8 the Pi4 is more than 32 times faster than the Pi2.Both pies tested running in X
Pi4 is nice and quick to do fast programming, Of course normally you only work on one or a few source files at the time. The code is rather complex, especiallly it spends a lot of time in graphics.c.
No Pi3 here to test.
Pi4 compiler gives a lot of weird warnings, I like clean compiles reads faster, no idea what this is supposed to mean: /usr/include/features.h:184:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
OK try again claiming all resources on the Pi2 root@raspi73:~/compile/pantel/xgpspc# rm *.o root@raspi73:~/compile/pantel/xgpspc# date; nice -n -19 make 2>/dev/zero; date Fri Mar 6 14:38:29 CET 2020 cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o xgpspc.o xgpspc.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o setup.o setup.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o mpu6050.o mpu6050.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o sensors.o sensors.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o iiclib.o iiclib.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o io.o io.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o x11.o x11.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o graphics.o graphics.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o ais.o ais.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o navigation.o navigation.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o hmc5883.o hmc5883.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o bmp180.o bmp180.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o nmea.o nmea.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o markeringen.o markeringen.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o alarms.o alarms.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o stepper.o stepper.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o udp_server.o udp_server.c cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o planes.o planes.c gcc -o xgpspc xgpspc.o setup.o mpu6050.o sensors.o iiclib.o io.o x11.o graphics.o ais.o navigation.o hmc5883.o bmp180.o nmea.o markeringen.o alarms.o stepper.o udp_server.o planes.o -lm -lpthread -lXaw -ljpeg Fri Mar 6 14:47:30 CET 2020
9 minutes, 540 seconds, makes little difference, Pi4_speed / P2_speed = 540 / 17 = more than 31 times faster.Anyone with a Pi3 test?
My source file was only 10K. I don't think disk I/O was the issue. Pure CPU and RAM
-- Microsoft : the best reason to go to Linux that ever existed.
Does the Pi 4 show the same difference in speed between successive identical compiler runs without a reboot or disk switch in between?
On this T440 I see the same speed-up for subsequent compilations compared with the first following a reboot or switch from other workloads. Its not specific to C either: Open Java 1.8 does exactly the same, though I haven't yet attempted to measure the speed difference for ant- controlled Java compoilation.
The R61i it replaced, which, BTW has 3GB of RAM and a Core Duo chip clocked at 1.6 GHz, used to show the same speed difference.
I bought the T440 when the R61i disk failed and I discovered that its disk interfacing electronics could not handle a disk bigger than 250 GB, and at the time all disks under 320 GB were no longer available. I subsequently revived the machine by fitting a 128GB Sandisk SSD and I've just timed that using the ecaxt same workload.
The 1 st compilation after booting it took 2.540 seconds and the second one took 2.217 secs , so the cache has a tiny effect, but thats largely masked by the much greater speed of the SSD.
The T440 has a 500 GB Toshiba HDD installed, which threw its first hard error last weekend (at around 21,000 hours and no problems since) so I bought a WD Black drive to replace it: I'll be very interested to see what effect its large (32MB) cache has on overall system performance when the Tosh finally dies and gets replaced.
-- Martin | martin at Gregorie | gregorie dot org
On Fri, 06 Mar 2020 13:52:06 GMT, Jan Panteltje declaimed the following:
Unless you have different compiler/OS versions running on the various machines, I'd expect all R-Pi models to produce the same warnings for the same input. What happens if you swap the SD card between the models and repeat?
As for the warning itself, I'd suspect the listed include file is making use of something like
#ifdef xxxx
referencing either of those two definitions. Though... a quick google shows a solution to be in a makefile (for something)
-- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
On a sunny day (Fri, 6 Mar 2020 15:25:38 -0000 (UTC)) it happened Martin Gregorie wrote in :
No, almost the same to a fraction of a second, sometimes even a second longer then again a second earlier.
It is not a disk IO bottle-neck, but mainly processor power used to parse the C code. As to the sources I used: graphcs.c 5684 lines of code (with some empty lines) navigation.c 852 lines xgpspc.c 5084 ais.c 4020 x11.c 2207 etc processor cycles mainly go into parsing the C code.
With Pi4 compiling is fun,
4 seconds for graphics.c only...Speed for my Hitachi 3.2 TB USB disk connected to the Pi: raspi95: # hdparm -t /dev/sda2 /dev/sda2: Timing buffered disk reads: 382 MB in 3.01 seconds = 127.01 MB/sec
raspi95: # hdparm -T /dev/sda2 Timing cached reads: 1660 MB in 2.00 seconds = 831.84 MB/sec
No bottleneck there I think :-)
(apt-get install hdparm)
OK I have the 4GB version of the Pi4
I formatted the 3.2 GB disk with ext4. From 'mount': /dev/sda2 on /mnt/sda2 type ext4 (rw,relatime)
I now have 3 USB harddisks, 1TB unknow make on the TV, 1 TB Seagate normally off for backups, and the 3.2 TB Hitachi on the RP4.
So far no problems,
Only harddisk I ever killed was when I dropped one from the bookshelf 20 years or so ago.. For the rest never have any problems, several on for 15 years or more 24/7.
On a sunny day (Fri, 06 Mar 2020 11:07:05 -0500) it happened Dennis Lee Bieber wrote in :
Interesting, just tried some things, Pi4 keeps complaining.. It runs gcc version 8.3.0 (Raspbian 8.3.0-6+rpi1):
raspi95: ~/compile/pantel/xgpspc # make cc -O2 -Wall -c -o graphics.o graphics.c In file included from /usr/include/arm-linux-gnueabihf/sys/types.h:25, from xgpspc.h:42, from graphics.c:26: /usr/include/features.h:184:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp] # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" ...
Exactly the same source and same Makefile on Pi2 is a clean compile;
That runs gcc version 4.6.3 (Debian 4.6.3-14+rpi1):
root@raspi73:~/compile/pantel/xgpspc# rm graphics.o root@raspi73:~/compile/pantel/xgpspc# make cc -DWITH_MAIN -Wall -O2 -I/usr/local/include -Wall -c -o graphics.o graphics.c gcc -o xgpspc xgpspc.o setup.o mpu6050.o sensors.o iiclib.o io.o x11.o graphics.o ais.o navigation.o hmc5883.o bmp180.o nmea.o markeringen.o alarms.o stepper.o udp_server.o planes.o -lm -lpthread -lXaw -ljpeg
Also clean on the X86 laptop.. it runs gcc version 4.5.2 (GCC) (slackware). panteltje20: ~ # uname -a Linux panteltje20 2.6.37.6 #3 SMP Sat Apr 9 22:49:32 CDT 2011 x86_64 Intel(R) Core(TM) i5-2430M CPU @ 2.40GHz GenuineIntel GNU/Linux time flies :-)
Will play with it and gcc options a bit more, clearly is a compiler issue.
On a sunny day (Fri, 06 Mar 2020 11:07:05 -0500) it happened Dennis Lee Bieber wrote in :
Ah stackoverflow had the right solution: #define _DEFAULT_SOURCE did that in the header
Many thanks!
That seems to be manufacturer-dependent. Back when 20-40MB was considered a good sized 3.5" disk, I used Maxstor drives and never had one last as long as than 3 years - and that was before I had a server running 24 x 7. After that I switched to WD Blue drives and don't believe any of them died, though the systems they were it became obsolete and got replaced.
On last two HDDs I had fail were the 2.5" Hitachi in the Lenovo R61i (47,000 hours) and a Hitachi 3.5" in the house server, which runs 24 x 7, at 49,000 hours. Both are good, seeing that the expected (guestimated) life of these disks is 50,000 hours.
BTW, I noticed, just after buying the WD Black 500GB drive, that WD are selling 500GB SSDs for only about 10% more than it - and the Black series are around 20% more than the equivalent Blue, so has anybody connected this class of SSD to a Pi 3 or 4 yet?
-- Martin | martin at Gregorie | gregorie dot org
The USB controller in the original Pi and friends (USB2) is an OTG controller that works better as a device controller than a host controller. If you know how and what it was designed for the performance it has makes sense. HINT not designed for host controller is a small stand alone computer. The Pi4 has a different USB3 controller so should be more competent as a host controller for a "desktop" computer which is how many Pis are used.
FWIW, a Pi3 running FreeBSD seems to be cpu bound until swap use reaches about 300 MB. With over 500 MB it appears to be I/O bound using decent (Sandisk Extreme or Samsung Evo +) microSD and USB flash swap partitions.
bob prohaska
On a sunny day (Fri, 6 Mar 2020 17:35:46 -0000 (UTC)) it happened Martin Gregorie wrote in :
Ooops, correction, seems the 3.2 TB USB harddisk I have connected to the Pi4 is not a Hitachi, but a Toshiba. raspi95: ~ # hdparm -I /dev/sda ATA device, with non-removable media Model Number: TOSHIBA MQ04UBB400 Serial Number: 59UDT18UT Firmware Revision: JS000U Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
It is even written on it :-)
In the eighties you had IBM drives of maybe it was 10GB? tha thad a mechanical lever likething on the side, it ws connected to teh head movement, If the head positioning got stuck or something you could move that lever and the thing would work again.... So, anyways, sorry about that.
Here is some data on long running PC harddisks I have on my table here using the 'smartctl' utility
Oldest one, runs grml, is based on Debian:
grml: ~ # smartctl --all /dev/hda | grep -i power_on_hours 9 Power_On_Hours 0x0032 052 052 000 Old_age Always - 42069 Model Family: Seagate U Series 5 family Device Model: ST340823A Serial Number: 5EF0Q4VR Firmware Version: 3.11 User Capacity: 40,020,664,320 bytes Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000e 064 046 025 Old_age Always - 184809966 3 Spin_Up_Time 0x0002 070 070 000 Old_age Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 758 5 Reallocated_Sector_Ct 0x0032 100 100 036 Old_age Always - 0 7 Seek_Error_Rate 0x000e 085 060 030 Old_age Always - 387347997 9 Power_On_Hours 0x0032 052 052 000 Old_age Always - 42069 10 Spin_Retry_Count 0x0012 100 100 097 Old_age Always - 0 12 Power_Cycle_Count 0x0032 099 099 020 Old_age Always - 1858
194 Temperature_Celsius 0x0022 020 048 000 Old_age Always - 20 195 Hardware_ECC_Recovered 0x001a 061 052 000 Old_age Always - 98610043 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0000 100 100 000 Old_age Offline - 0 202 TA_Increase_Count 0x0032 100 253 000 Old_age Always - 0SMART Error Log Version: 1 No Errors Logged
SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 41561 -
grml: ~ # smartctl --all /dev/hdb | grep -i power_on_hours 9 Power_On_Hours 0x0032 053 053 000 Old_age Always - 41909 === START OF INFORMATION SECTION === Model Family: Seagate U Series 5 family Device Model: ST340823A Serial Number: 5EF0Q65W Firmware Version: 3.11 User Capacity: 40,020,664,320 bytes Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000e 060 051 025 Old_age Always - 70817756 3 Spin_Up_Time 0x0002 070 070 000 Old_age Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 724 5 Reallocated_Sector_Ct 0x0032 100 100 036 Old_age Always - 0 7 Seek_Error_Rate 0x000e 087 060 030 Old_age Always - 638797005 9 Power_On_Hours 0x0032 053 053 000 Old_age Always - 41909 10 Spin_Retry_Count 0x0012 100 100 097 Old_age Always - 0 12 Power_Cycle_Count 0x0032 099 099 020 Old_age Always - 1854
194 Temperature_Celsius 0x0022 021 054 000 Old_age Always - 21 195 Hardware_ECC_Recovered 0x001a 063 052 000 Old_age Always - 123271335 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0000 100 100 000 Old_age Offline - 0 202 TA_Increase_Count 0x0032 100 253 000 Old_age Always - 0SMART Error Log Version: 1 No Errors Logged
grml: ~ # smartctl --all /dev/hdd | grep -i power_on_hours 9 Power_On_Hours 0x0032 045 045 000 Old_age Always - 48796 == START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.7 and 7200.7 Plus family Device Model: ST3120026A Serial Number: 5JT5C5LR Firmware Version: 8.01 User Capacity: 120,034,123,776 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 6 ATA Standard is: ATA/ATAPI-6 T13 1410D revision 2
SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 051 049 006 Pre-fail Always - 88898812 3 Spin_Up_Time 0x0003 097 096 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 25 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 089 060 030 Pre-fail Always - 871579226 9 Power_On_Hours 0x0032 045 045 000 Old_age Always - 48796 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 099 099 020 Old_age Always - 1149
194 Temperature_Celsius 0x0022 030 057 000 Old_age Always - 30 195 Hardware_ECC_Recovered 0x001a 051 049 000 Old_age Always - 88898812 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 187 000 Old_age Always - 2142 200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0 202 TA_Increase_Count 0x0032 100 253 000 Old_age Always - 0SMART Error Log Version: 1 ATA Error Count: 2139 (device log contains only the most recent five errors) CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days.
Error 2139 occurred at disk power-on lifetime: 48790 hours (2032 days + 22 hours) When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 01 d2 1e 31 f0 Error: ICRC, ABRT 1 sectors at LBA = 0x00311ed2 = 3219154
Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 90 43 1e 31 f0 00 00:01:23.404 READ DMA EXT 25 00 90 43 1e 31 f0 00 00:01:25.455 READ DMA EXT 10 00 3f 00 00 00 f0 00 00:01:24.817 RECALIBRATE [OBS-4] 25 00 90 43 1e 31 f0 00 00:01:24.817 READ DMA EXT 25 00 90 43 1e 31 f0 00 00:01:24.201 READ DMA EXT
Error 2138 occurred at disk power-on lifetime: 48790 hours (2032 days + 22 hours) When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 01 d2 1e 31 f0 Error: ICRC, ABRT 1 sectors at LBA = 0x00311ed2 = 3219154
Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 90 43 1e 31 f0 00 00:01:23.404 READ DMA EXT 10 00 3f 00 00 00 f0 00 00:01:23.404 RECALIBRATE [OBS-4] 25 00 90 43 1e 31 f0 00 00:01:24.817 READ DMA EXT 25 00 90 43 1e 31 f0 00 00:01:24.817 READ DMA EXT 25 00 18 53 9c 2f f0 00 00:01:24.201 READ DMA EXT
Error 2137 occurred at disk power-on lifetime: 48790 hours (2032 days + 22 hours) When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 01 d2 1e 31 f0 Error: ICRC, ABRT 1 sectors at LBA = 0x00311ed2 = 3219154
Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 90 43 1e 31 f0 00 00:01:23.404 READ DMA EXT 25 00 90 43 1e 31 f0 00 00:01:23.404 READ DMA EXT 25 00 18 53 9c 2f f0 00 00:01:23.398 READ DMA EXT 25 00 08 9b 52 2f f0 00 00:01:23.388 READ DMA EXT 25 00 08 3b 46 f1 f0 00 00:01:24.201 READ DMA EXT
Error 2136 occurred at disk power-on lifetime: 48790 hours (2032 days + 22 hours) When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 01 d2 1e 31 f0 Error: ICRC, ABRT 1 sectors at LBA = 0x00311ed2 = 3219154
Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 90 43 1e 31 f0 00 00:01:23.404 READ DMA EXT 25 00 18 53 9c 2f f0 00 00:01:23.404 READ DMA EXT 25 00 08 9b 52 2f f0 00 00:01:23.398 READ DMA EXT 25 00 08 3b 46 f1 f0 00 00:01:23.388 READ DMA EXT 25 00 c0 fb 0c 3b f0 00 00:01:23.377 READ DMA EXT
Error 2135 occurred at disk power-on lifetime: 48790 hours (2032 days + 22 hours) When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 01 72 22 2b f0 Error: ICRC, ABRT 1 sectors at LBA = 0x002b2272 = 2826866
Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 58 1b 22 2b f0 00 00:01:15.817 READ DMA EXT 25 00 40 db 21 2b f0 00 00:01:15.808 READ DMA EXT 25 00 08 db 4d 29 f0 00 00:01:15.799 READ DMA EXT 25 00 18 c3 21 2b f0 00 00:01:15.853 READ DMA EXT 25 00 18 ab 21 2b f0 00 00:01:15.852 READ DMA EXT
Those errors are mainly because I was messing around with it, disc is OK. ----------------
And for the a bit more recent? :-) PC, runs Slackware: sda Model Number: Hitachi HDS721050DLE630 Serial Number: MSK4235H34LZGH Firmware Revision: MS1OA610 Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0; Revision: ATA8-AST T13 Project D1697 Revision 0b
sdb ATA device, with non-removable media Model Number: TOSHIBA HDWD130 Serial Number: 19C59AWAS Firmware Revision: MX6OACF0 Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0; Revision: ATA8-AST T13 Project D1697 Revision 0b
root@panteltje12:~# smartctl --all /dev/sda | grep -i power_on_hours 9 Power_On_Hours 0x0012 092 092 000 Old_age Always
- 62357
No errors
62357 hours on Hitachi is not bad.Recently added disk: root@panteltje12:~# smartctl --all /dev/sdb | grep -i power_on_hours 9 Power_On_Hours 0x0012 100 100 000 Old_age Always
- 596
OK, 'nuf said.
me,
That's where you're wrong by your own premises. If you know your own subject well and know how to achieve a lot manually, then spending just two weeks learning the basics of how to automate can shove parts of your productivity by two orders of magnitude.
You will never be a programmer but a far more competent expert in whatever it is you were an expert in before. And it may teach you just enough vocabluary and way of thinking to be able to team up with a real programmer and achieve something of general usefulfulness. (The programmer of course will have to put in at least the same two weeks before beginning to understand your language.)
-- / \ Mail | -- No unannounced, large, binary attachments, please! --
playing back the same time,
Interesting stuff - never knew how video slomo worked before.
Just found this:
If you scroll down, the 3rd picture shows an EDS 60 disk pack (60MB disk) being exchanged on a disk drive. The drive in that picture is a slide- out unit, which I never saw.
The 8th picture shows a free-standing disk drive, which is the type I'm familiar with - the lid hinges up for access when you need to change the disk.
To remove a disk pack, the clear plastic cover fits down over the stack of magnetic platters. You screw the handle down to lock the pack into the cover and release it from the drive spindle and then lift it off. Finally, you screwed a flat plastic cover on the bottom to keep the disk pack in clean conditions when put in storage.
When the pack is on the drive and running a cover closes over it and filtered air circulates round the spinning disk. There's a servo-driven rack of heads, one per surface, that bangs in and out for access to data. The servo used an optical indexing system (not part of the disk pack) to locate recording tracks. The read/write heads all fly, just like modern HDD systems.
Unlike modern systems, if the mainframe was running UDAS, there was typically a different set of disks for each set of programs, so when switching from, say, invoicing to payroll, the first job was to change the disks take off the disks containing the onvoicing programs and data and replace them with the payroll disks. UDAS was a tiny, in-memory OS, so didn't care which disks were on the drives.
Drives were heavily partitioned. In modern terms, each file occupied its own partition, so part of the system designer's job was to define the number, size and names of the disk files needed my the new system, and to place them on disk to minimise head movement because that was much slower than accessing data on the same cylinger (slang for the same numbered track on all surfaces).
If the box was running George 3, things were quite different: George usually owned the at least one whole disk and managed a dynamically assigned, hierarchic filing system on them - very similar to Unix/Linux - except that all files and directories were automatically backed up to tape. Files that weren't recently used could be, and often were, erased and the space reused. If the file's owner now needed it, no problem, because George asked the operator to load the required backup tape and copied the file back to disk. Right: quite enough of that: I now return you to your normal programme.
-- Martin | martin at Gregorie | gregorie dot org
I don't quite understand what you're after, but 'command line interface' is provided by shells - i.e. bash dash ksh.
There was almost no commonality between the 2900 and the S/360 S/370 apart from the decidedly odd decision to use EDCDIC character codes.
The nearest mainstream architecture was probably the Burroughs B6700.
The 2966 was soft as hell: a 2966 could, and did run the George 3 and VME/ B operating systems simultaneously v. useful for migrating systems from the 1900series (word addressed memory, 24bit words, 6 bit characters, 8
24 bit registers and no stack) to the 2900 VME/B environment (byte addressed memory, 1 programmatically variable sized register, stack-based architecture, 8-bit EBCDIC characters, HLL-oriented instruction set (the COBOL statement "MOVE ALL SPACE to TABLE_A." was one machine instruction.Oddly, though VME/B was curiously similar to IBM's OS/400, which first appeared on the AS/400 range and is still alive and kicking on their I- series machines. Both are Real Programmer's Operating Systems at least as much as UNIX/Linux is, with command languages you can program in, command names follow a system so, if you know them, you can go "There ought to be a command called xxxxxxx which will do what I want", so you'd type it in, hit the 'Screen prompt' key, and the screen would fill with a fill-in-the- boxes template, so you filled it in, hit GO and it did. Of course the commands weren't the same: in VME/B the COBOL compiler was called 'cobol' while in OS/400 is was called CRTCBLPGM.
ICL 1900 for me, after learning Algol 60 at uni on an Eliott 503.
OK, that is positively my LAST on this topic except, to get back on topic, to say that you can run George 3 on a Raspi AND all the manuals needed to develop programs for it are available online. I haven't done that yet, but I will Real Soon Now and I won't be at all surprised if George runs faster on a Raspi B emulating a 1900 than it ever did on a
1903S mainframe (clock speed around 0.6 Mhz) even with its filestore on an SD card.-- Martin | martin at Gregorie | gregorie dot org
On 7 Mar 2020 19:37:00 GMT, Charlie Gibbs declaimed the following:
My college had a Xerox Sigma-6 running CP/V. Four-bank/four-port interleaved memory (this allowed for the CPU to access a bank using one port, and three I/O processors to access the other banks using the other ports -- simultaneously, and the interleave meant all four processors basically chased each other through the memory banks). I'd swear we were told it had 1MB of RAM, but the system reference manual claimed it only handled 128k "words" (32-bit; 16-bit was a "halfword", so 512kB). Four refrigerator sized cabinets, one per memory bank -- but if one opened a cabinet, one found one or two circuit cards sitting in the bottom third. The original magnetic core had been replaced with static RAM ICs (as I recall, the main processor used DTL logic chips, not even TTL!).
We often had some 60+ active terminals scattered over the campus (this is in a time period where a "graphics terminal" was an APL-keyboard Tektronix storage display tube. Common terminals were Hazeltine 1200 and
2000 models.I remember the year they got in two new disk drives which were dedicated to system software and process swap space as I recall. These two were a whopping 300MB each. The other six drives we had were 11-platter (20-writable surfaces) units rated 100MB each.
They also replaced a room full of Gandalf communications gear (handling the terminals to mainframe) with a Honeywell Level-6 minicomputer and lots of I/O ports. It worked nicely except... when the processor board got warm. The board was mounted horizontally, and had a tendency to sag in high temperatures, losing contact with the edge connectors.
We also had a year where the Sigma tended to crash around 7AM every day. Finally tracked down to the PBS station (hosted in the same building) powering up the transmitter each morning. So... A large fly-wheel motor-generator set was installed to smooth out the power supply.
-- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
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.