Re: hwclock accuracy
On Thu, Jan 20, 2011 at 06:36:14PM +1100, Sridhar Dhanapalan wrote: What is the accuracy of the hwclock on XOs? By accuracy I presume you mean stability over time, or the amount of error between the clock and actual time. If you mean something else, ignore the following explanation. The XO-1.5 real-time clock is part of the VX855 chip. Attached to it is a 32768 Hz tuning fork crystal. When the system is off, the clock is powered by the tiny rechargable coil cell type battery on the main board. The clock battery is kept charged by one of the internal power supplies. The accuracy will be mainly determined by the crystal and the temperature. I don't have the specifications for the crystal here. I guess the accuracy should be around six parts per million, which is within half a second per day. To measure accuracy you must measure the error between the clock time and a more accurate source, over a long period of time, such as a day or a week. What are you observations regarding accuracy? Can we assume that it will keep good time over an XO's five-year lifespan? Yes, for a certain measure of good. We expect that you will synchronise the clock regularly, and this is supposed to be done in the presence of the OLPC school server. If you are not using a school server, then I imagine you should add a periodic ntpdate invokation, followed by a hwclock --systohc. Doing this on network connection might be best. Most computer real-time clocks are built with similar assumptions. We have some XO-1.5s that have their hwclocks off by 10-20 minutes. Would this likely be due to a fault at the factory (e.g. not setting the time before shipping them), or did they skew over time? This is due to the factory not setting them to a synchronised time source. I've observed that. Not unexpected. Skew over time is possible, but you would need to measure it, not just assume it. At six parts per million, I'd expect a ten minute drift to take a few years. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: hwclock accuracy
What is the accuracy of the hwclock on XOs? Can we assume that it will keep good time over an XO's five-year lifespan? The ballpark for the hardware is 1 second per day. We have some XO-1.5s that have their hwclocks off by 10-20 minutes. Would this likely be due to a fault at the factory (e.g. not setting the time before shipping them), or did they skew over time? How long ago did you last set the clock? Timekeeping is more complicated than that. /etc/init.d/halt calls /sbin/hwclock --systohc So each time you shut down cleanly, your hwclock gets updated with the current system time. That's probably a good idea if you are running ntpd like most Linux boxes. However, if you aren't running ntpd (or somehow keeping the system clock reasonably sane), you are swapping the drift on the hwclock for the drift of the system clock. Sometime in the past few years, the timekeeping corner of the kernel was cleaned up. Unfortunately, they introduced a bug in the TSC clock calibration code. The main problem for most Linux users is that it doesn't get the same answer each time it boots. It's close, but not very good if you are interested in timekeeping. If it were consistent, ntpd could easily correct for the error. That's what /var/lib/ntp/drift is for. (Small variations are expected due to temperature.) The secondary problem is that it's likely to be off by 10s of seconds per day. I'll dig out some numbers if anybody wants more details. I don't have good data on how well clocks work when power-saving is enabled. - If you actually want to know how accurate your hwclock is: comment out the line in /etc/init.d/halt, reboot, check the time, wait a week or 10 days, check again. ntpdate -d handy-server may be the simplest way to check the time. Grab ntpdate from a handy system. Or run xclock -analog -update 1 on a system running ntpd and use that to calibrate your wrist watch and ... -- These are my opinions, not necessarily my employer's. I hate spam. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC XO 1.75 replace one of the 3 usb port with a mini hdmi
On Jan 20, 2011, at 5:12 AM, Peter Robinson wrote: On Thu, Jan 20, 2011 at 7:17 AM, Frantisek Dufka duf...@gmail.com wrote: On 19.1.2011 12:48, Andrew Puch wrote: Also I hope there is a give1get1 one for this machine along with a nice touch screen :) Even selling just motherboard upgrades to XO-1 G1G1 would be great. BTW, does 1.75 board still fit into XO-1 like the 1.5 one does? Yes, except there's a slight mod required to secure the wifi but that's the same mod that's required to mount a 1.5 MB in a 1.0 case too. 1.75 in a 1.5 case should be fine. There was a post to the list in the last couple of days about a 1.5 MB in a 1.0 case and what minor mod was required. We have a metal bracket designed and in production which makes that even more trivial. Unfortunately, doing this also requires adding some conductive foam/tape in a number of places in order to maintain the same ESD protection as the XO-1. Cheers, wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC XO 1.75 replace one of the 3 usb port with a mini hdmi
On Jan 19, 2011, at 6:48 AM, Andrew Puch wrote: Is the cost and form factor viable to replace one of the external usb ports with a mini hdmi Type C or D port ? When students or teacher give talks it would be nice for them to show to the class on the tv what they are doing. The type hdmi 1.4 , D connector is 2.8 mm × 6.4 mm, where as the hdmi 1.3 type C connector is 2.42 mm × 10.42 mm; for comparison, a micro-USB connector is 2.94 mm × 7.8 mm and usb a is 11.5 mm × 4.5 mm. http://en.wikipedia.org/wiki/HDMI#Connectors Hmm. Most of the schools I've seen with XOs have no TVs, much less one with HDMI input. The HDMI pins aren't reused for anything, so this IS theoretically possible. We didn't budget for HDMI power, however.We'll think about it. wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: hwclock accuracy
On 20 January 2011 21:15, Hal Murray hmur...@megapathdsl.net wrote: What is the accuracy of the hwclock on XOs? Can we assume that it will keep good time over an XO's five-year lifespan? The ballpark for the hardware is 1 second per day. We have some XO-1.5s that have their hwclocks off by 10-20 minutes. Would this likely be due to a fault at the factory (e.g. not setting the time before shipping them), or did they skew over time? How long ago did you last set the clock? Never did. Timekeeping is more complicated than that. /etc/init.d/halt calls /sbin/hwclock --systohc So each time you shut down cleanly, your hwclock gets updated with the current system time. That's probably a good idea if you are running ntpd like most Linux boxes. However, if you aren't running ntpd (or somehow keeping the system clock reasonably sane), you are swapping the drift on the hwclock for the drift of the system clock. I think that's consistent with our problem. The system clock seems to be very inaccurate, and if it's writing to the hardware clock, it will be making it skew considerably. We've actually disabled the /sbin/hwclock --systohc in our latest build (probably to be released tomorrow). Related issues in our system are: https://dev.laptop.org.au/issues/299 https://dev.laptop.org.au/issues/313 Sometime in the past few years, the timekeeping corner of the kernel was cleaned up. Unfortunately, they introduced a bug in the TSC clock calibration code. The main problem for most Linux users is that it doesn't get the same answer each time it boots. It's close, but not very good if you are interested in timekeeping. If it were consistent, ntpd could easily correct for the error. That's what /var/lib/ntp/drift is for. (Small variations are expected due to temperature.) The secondary problem is that it's likely to be off by 10s of seconds per day. I'll dig out some numbers if anybody wants more details. I don't have good data on how well clocks work when power-saving is enabled. - If you actually want to know how accurate your hwclock is: comment out the line in /etc/init.d/halt, reboot, check the time, wait a week or 10 days, check again. ntpdate -d handy-server may be the simplest way to check the time. Grab ntpdate from a handy system. Or run xclock -analog -update 1 on a system running ntpd and use that to calibrate your wrist watch and ... -- These are my opinions, not necessarily my employer's. I hate spam. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: hwclock accuracy
On Thu, 2011-01-20 at 02:15 -0800, Hal Murray wrote: What is the accuracy of the hwclock on XOs? Can we assume that it will keep good time over an XO's five-year lifespan? The ballpark for the hardware is 1 second per day. We have some XO-1.5s that have their hwclocks off by 10-20 minutes. Would this likely be due to a fault at the factory (e.g. not setting the time before shipping them), or did they skew over time? How long ago did you last set the clock? Timekeeping is more complicated than that. /etc/init.d/halt calls /sbin/hwclock --systohc So each time you shut down cleanly, your hwclock gets updated with the current system time. That's probably a good idea if you are running ntpd like most Linux boxes. The main problem is /etc/adjtime doesn't keep it's data used to track whether the rtc is in localtime or utc time, the readonly filesystem layout resets this file on reboot. https://dev.laptop.org.au/issues/299 http://dev.laptop.org/ticket/10605 However, if you aren't running ntpd (or somehow keeping the system clock reasonably sane), you are swapping the drift on the hwclock for the drift of the system clock. With my observations I'd used the rtc as the source, as the system is drifting over a 1 min per hour. Sometime in the past few years, the timekeeping corner of the kernel was cleaned up. Unfortunately, they introduced a bug in the TSC clock calibration code. The main problem for most Linux users is that it doesn't get the same answer each time it boots. It's close, but not very good if you are interested in timekeeping. If it were consistent, ntpd could easily correct for the error. That's what /var/lib/ntp/drift is for. (Small variations are expected due to temperature.) The would be great to use but a ntp client is not installed by default. The secondary problem is that it's likely to be off by 10s of seconds per day. I'll dig out some numbers if anybody wants more details. I don't have good data on how well clocks work when power-saving is enabled. You might be on to something there, on one XO-1.5 with uptime of 12 hours (inactive, I was sleeping), the system clock is now out over 3 hours in that time frame while the rtc is accurate. Well it's not out 3 hours... ;) - If you actually want to know how accurate your hwclock is: comment out the line in /etc/init.d/halt, reboot, check the time, wait a week or 10 days, check again. ntpdate -d handy-server may be the simplest way to check the time. Grab ntpdate from a handy system. Or run xclock -analog -update 1 on a system running ntpd and use that to calibrate your wrist watch and ... Going down that route chasing this, Jerry ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: foot pedal power
Talking about human power.. potenco version2. http://www.potenco.com/products/pcg2/ Rafael Ortiz On Wed, Jan 19, 2011 at 9:44 PM, James Cameron qu...@laptop.org wrote: On Thu, Jan 20, 2011 at 10:38:59AM +0800, Carlos Nazareno wrote: I can add it to the wiki, but where should I add it? It's a Wiki, add it where you think best. Others may move it or link to it. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Announcing the development of OLPC OS 11.2.0
Hi, The project previously known as F14 for XO will now be developed into an official OLPC OS release with version number 11.2.0. More information is available here: http://wiki.laptop.org/go/11.2.0 http://wiki.laptop.org/go/11.2.0/Release_plan We are currently in milestone 2, which is where we will try to fix the biggest showstoppers such as various activities not launching, before moving into a 2.5-month feature development period. Your feedback is appreciated: we are looking to draw in testing, bug reports and development efforts from the community, starting now :) Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Announcing the development of OLPC OS 11.2.0
On 20 January 2011 17:50, Daniel Drake d...@laptop.org wrote: Your feedback is appreciated: we are looking to draw in testing, bug reports and development efforts from the community, starting now :) One thing to add - we'd previously asked that people don't file bug reports for Sugar and activities, since we didn't have any resources directed towards fixing them. That's changed now, and we're ready to make this work. So, please file any bugs you had been holding back. However, it may be sensible to wait til the next build is published, today or tomorrow, as the current one is a bit stale. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: hwclock accuracy
On Thu, Jan 20, 2011 at 8:02 AM, Sridhar Dhanapalan srid...@laptop.org.au wrote: We've actually disabled the /sbin/hwclock --systohc in our latest build (probably to be released tomorrow). If you are spinning your own build, ensure ntpdate is installed. That should help significantly. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
The old xs-livecd is the new olpc-xs-builder
The XS build tools have not used the livecd toolchain for a long time -- so the name is not appropriate. Time for a rename (and repo reorg). While not as modular and elegant as olpc-os-builder, we do have a collection of tools and configs that, operated correctly, build XS isos for installation. This can be useful to prepare a custom auto-intalling iso with preconfigured settings. http://dev.laptop.org/git/projects/olpc-xs-builder I've updated wiki links to the old repo, and added a stub http://wiki.laptop.org/go/XS_Builder m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Health] $30 microscope
Folks: We've been able to get the Veho USB 400x 1.3Mp/2.0Mp interpolated to work on the XO 1 and XO 1.5 under 10.1.3 with 'Cheese'. However, with this high resolution webcam, you just need to make sure it attaches itself to the USB 2.0 bus. If for some reason it comes up and attaches to the 1.1 bus, one gets get what looks like a 1970's color TV test pattern when starting the camera software.. I can't speak to the specifics of the DIgiMicro; we bought a bunch of different microscope samples from various HK based ebay vendors before standardizing on the Veho. It is fully uvc compliant and also works on Ubuntu, Windows and the Mac. On Ubuntu, we use guvcview to control it. Due to the fact we needed to support multi-continent co-curricula, we needed one that ran everywhere on everything. It can cost between $40 and $75 from ebay depending on the day of the week, it seems. Be careful, the one one wants is the '004' product not the '001' or '004'. On the XO, Mikus Grinbergs has since done some magic for us to get guvcview to load on the XO, since guvcview only has an Fc12, 686 RPM. It gets more complicated since some of the dependencies for guvcview need the FC12/686 rpm versions which one has to go out and find manually, while other dependencies need the FC11/586 standard repo versions. For us, we are still in the process of bullet-proofing this so young users can mod their 10.1.3 box to install guvcview. guvcview has way more user-definable parameters than does Cheese. So, for simplicity, one can just install Cheese for now. It works from Sugar if called from the terminal prompt. It wont run properly as root, just stay as default OLPC user., dont know why, dont really care. Personally I run as little as possible as root.A bunch of weird messages come up once invoked from Sugar, but it does eventually come up. It will flash the built-in cafe camera light then proceed over to the USB camera. You can edit the preferences in Cheese to default to the USB camera. If the USB camera isnt seen in teh camera device drop-down, then for some reason it isn't being handled properly at the driver level. In terminal, check the output of the lsusb command, the camera should be seen there with a nice description and USB vendor./eqpt number. Once you are doen in cheese on the the sugar side, unfortunately you have to stop it 'inelegantly'' as it has no sugar activity button. You can use the ctrl-q, or function key back to the activity wheel and kill it from there. However, this seems to leave a little stub up and running, so you may have to reboot to get it going again. On the other hand the successful yum install of cheese puts itself nicely into the graphics submenu on the Gnome side, and behaves nicely there. You can then save your microscope photos ot the fiel system (preferably on an external SD card or a USB stick, then look at the photos from the Sugar side. Just remember INSTALL it as root, but run it as the normal default user. Summary. USB uvc compliant webcams (microscopes) should just plug in and be seen by both the XO 1.0 and XO 1.5. Then yum install cheese, and use the Gnome side to do any 'photos'. All caveats with respect to the snails-pace of the yum install are still in effect ont the 1.0, we do a yum install downloadonly to a stick on a 1.5 (which does yum nicely), then yum localinstall from the stick to all the XO 1.0's to eliminate those install hanging and memory full issues. As an added benefit, Cheese has no other dependencies when installed to 10.1.3. For those who saw our little tech-geek table at the SF summit, this is exactly what we were demoing on the 1.5. Daniel Drake and Paul Fox have since done yeomen effort to bring the uvc, sisusb, and ldusb drivers all back into sync on the 1.0's and 1.5s at 10.1.3 . Have fun, it really is cool stuff. KG O n Thu, Jan 20, 2011 at 5:45 PM, Mike Lee curious...@gmail.com wrote: [Copying everyone.] I haven't tried this with the new 10.1.3. But before that, it didn't work on the XO-1 without having to get into kernal hacking. Paul Fox confirmed that they are looking into adding support. I don't know if they have. I bought my Digimicro from DealExtreme for $31.10. The catch is they ship from Hong Kong (as I recall). It took 3-4 weeks to get the 'scope. http://www.dealextreme.com/details.dx/sku.11743 Mike On Thu, Jan 20, 2011 at 3:03 PM, Cherry Withers cwith...@ekindling.org wrote: Mike, I just ordered mine from Amazon. But we were discussing this on our Squeakland meeting today and wondering if you've tried this on the XO 1.0 as well and if you've tried other brands? The Digimicro is hovering around $37-$45 at Amazon (without shipping and tax). Where have you found them for $30? Thank you for your help! --Cherry On Thu, Nov 18, 2010 at 8:14 PM, Mike Lee curious...@gmail.com wrote: Hi all, I ordered this Digimicro 1.3mp USB microscope and it arrived from China
Re: [Sugar-devel] acti-plications: write once, run anywhere?
Am I correct that sugar and gnome can co-exist in two different ways right now? 1. On a dual boot machine, probably an xo, where activities are installed into /home/user/Activities/ where useris probably *always *olpc 2. Sugar as an application in gnome (within a Xephyr window) where activities can be installed a few places, including /home/user/Activities/ Next question.. am I correct that the *preferred *way for users to install activities and applications is: A. Sugar activities are installed via .xo bundles. B. Gnome activities are installed via .rpm files. Now, how should activity developers (who are not writing system libraries like xulrunner or squeak) put their content so that their activity/application can be viewed from both sugar and gnome? I am asking so children can avoid having redundant copies of files on every machine running both gnome and sugar. This is a real problem for content rich activities with lots of media assets. By default, an rpm file will install into /usr/lib/python/. This is obviously not where sugar looks for its activities. If we could get an 'educational content' rpm to install its contents anywhere... where should we put its assets so that they are automatically where they should be for sugar too? Any experts out there on rpm spec files? Or is this a bad idea? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Administrative login for political reasons
On Wed, Jan 19, 2011 at 6:01 PM, Anna ascho...@gmail.com wrote: I think enough time has passed that I can write this up in case anyone else runs into this situation. Back when I was tussling with a school IT guy, he demanded administrative access to the XSs. Err, you do realize there is no GUI whatsoever and all you're going to see is a prompt, right? He was a Windows guy and didn't want to admit he had no clue what to do with a CLI only Linux system. And got offended when I asked if he had an ssh client. Well, Mr. Big Shot, here's your precious admin access. I created an admin user and set a password. adduser admin passwd admin I use passwords for ssh, but do run it on a nonstandard port, deterring the script kiddies. Having previously installed and set up ssmtp so the XSs could send me emails via gmail, I edited /home/admin/.bashrc echo 'Login Alert on' `hostname` `who -m` | mail -s Login Alert m...@gmail.com Being of a nosy disposition, particularly when it comes to what's going on with my systems, I set it up to quietly log everything he did with this line in /home/admin/.bash_profile script -q /var/log/sessions/login-`date +%m-%d-%Y-%Hh-%Mm-%Ss`-`whoami`.log exit Created and set permissions to a dir in /var/log that looks innocuous: mkdir /var/log/sessions chmod 777 /var/log/sessions And just in case he reads something on the internet, here's some sudo rope to hang himself with. I can install and customize an XS in under an hour, so whatever if he breaks it. I was actually really looking forward to pulling logs to prove he was out of his league. visudo and then add an entry for admin under root. ## Allow root to run any commands anywhere root ALL=(ALL) ALL admin ALL=(ALL) ALL The hilarious bit was he claimed he logged into all my XSs and said everything looked OK. What? I didn't get a single email notification and /var/log/sessions was empty. I checked /var/log/secure just to be absolutely sure. What a pompous liar. And a liar who didn't know better than to lie to someone who could prove it via system logs. So that's my workaround for ignorant people who demand admin access. Anna Schoolfield Birmingham ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel You are hilariously evil 8-)~ cheers, Sameer ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
[Server-devel] Picostation APs
Any useful feedback/criticisms on the Ubiquiti Picostation units being used in the Samoa deployment? http://www.ubnt.com/picostation We are debating between these and WRT54GL units for Jamaica. cheers, Sameer ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
