Re: Any issues with C in Sugar and XO?
On 08.05.2010, at 11:12, Chris Ball wrote: > > Hi, > >> Hey, I am wondering if there are some major issues or technical >> problems that doesn't make Sugar compatible with C. For example, >> if a program is written in C, are there going to be at least some >> complications with running it? > > No. Several activities are currently written in C, although most > (e.g. Browse and Abiword) have a small Python wrapper sitting on top > of the C code. > >> Can we run the program after installing gcc, but I don't think >> gcc would be easy to install in it, will it? > > You do not need to install gcc to run a C program. gcc's just a > compiler, not a runtime library. > >> So, one more question, please - What are the consequences and >> effects on performance of a C program as compared to a Python >> program? > > The largest consequence is that you lose access to our python > libraries for the datastore and collaboration, which affects how > integrated your activity will be with the rest of Sugar. You can > work-around this by speaking the dbus protocols that we use from C > directly, but this is by no means trivial. Not trivial, true, but not exactly rocket science either :) Pure C might be a bit cumbersome, but by using something like glib to speak to DBus I'd think it is quite possible to keep the effort reasonable. Have a look at the stuff you need to implement: http://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API This could be made into a library, basically a Sugar toolkit implementation in C. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Any issues with C in Sugar and XO?
Hi, > Hey, I am wondering if there are some major issues or technical > problems that doesn't make Sugar compatible with C. For example, > if a program is written in C, are there going to be at least some > complications with running it? No. Several activities are currently written in C, although most (e.g. Browse and Abiword) have a small Python wrapper sitting on top of the C code. > Can we run the program after installing gcc, but I don't think > gcc would be easy to install in it, will it? You do not need to install gcc to run a C program. gcc's just a compiler, not a runtime library. > So, one more question, please - What are the consequences and > effects on performance of a C program as compared to a Python > program? The largest consequence is that you lose access to our python libraries for the datastore and collaboration, which affects how integrated your activity will be with the rest of Sugar. You can work-around this by speaking the dbus protocols that we use from C directly, but this is by no means trivial. - Chris. -- Chris Ball One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Any issues with C in Sugar and XO?
Hey, I am wondering if there are some major issues or technical problems that doesn't make Sugar compatible with C. For example, if a program is written in C, are there going to be at least some complications with running it? Can we run the program after installing gcc, but I don't think gcc would be easy to install in it, will it? So, one more question, please - What are the consequences and effects on performance of a C program as compared to a Python program? Thanks a lot, Abhishek Indoria _ Catch the latest in the world of fashion http://lifestyle.in.msn.com/___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 bad ogg experience
On Fri, May 7, 2010 at 11:07 PM, Daniel Drake wrote: > The video does work absolutely great in the Jukebox activity. But > Jukebox is a story of its own. Firstly it doesn't associate mimetypes > so you can't open a video in Jukebox from the journal > http://bugs.sugarlabs.org/ticket/1384 > > Secondly when you open it from the home view, it doesn't pop up the > object chooser, it just gives you a blank screen and gives you the > challenge of finding the "Open" button yourself > http://bugs.sugarlabs.org/ticket/1385 > > Thirdly it doesn't inhibit suspend, so the machine goes to sleep > during playback (should I file a bug?) > > > We're running something really close to 10.1.1 build 202. Released Jukebox v19 [1] , you can try this one , no suspend related code in that. Not tested too much due to unavailability of hardware. [1] http://download.sugarlabs.org/sources/sucrose/fructose/Jukebox/Jukebox-19.tar.bz2 Kushal -- http://fedoraproject.org http://kushaldas.in ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #10045 HIGH 1.5-sof: XO-1.5 Record audio/video are out of sync with each other
Hi,
I was just looking into this and the issue with SD cards' random write
performance intrigued me in this particular case.
Isn't recording being performed sequentially, hence no lag problem? At
least, it should be somewhat mitigated, filesystem might be causing
problems?
Anyhow, I have been looking into how to go around the random write problem
and NILFS2 popped up. In theory it seems a very capable way of having a
whole lot better performance, as it should only perform sequential
writes(unfortunately only partially). Anyone tried it before choosing ext3?
I have still not gotten to backuping the fs and moving it to NILFS2. It even
has SSD options and can suspend the garbage collector within some criteria,
helping alleviate the wear issue.
Best regards,
Tiago
On Thu, May 6, 2010 at 6:40 AM, Zarro Boogs per Child wrote:
> #10045: XO-1.5 Record audio/video are out of sync with each other
>
> ---+
> Reporter: wad | Owner: dsd
> Type: defect | Status: new
> Priority: high | Milestone: 1.5-software-update
> Component: record-activity | Version: Development build as
> of this date
> Resolution: |Keywords: camera record XO-1.5
>Next_action: diagnose |Verified: 0
> Deployment_affected: | Blockedby:
> Blocking: |
>
> ---+
>
> Comment(by Quozl):
>
> A significant improvement in video recording is achieved by moving the
> instance directory for the Record activity off the SD card.
>
> The result was no significant pauses in video motion during recording, and
> a much more predictable A/V latency.
>
> The downside is restricted recording time.
>
> This suggests that the current problems with recording are due to the SD
> writes. See #9688 (terrible SD write performance: wontfix), #9995
> (optimise kernel write block size), and #10112 (GUI freezes on fsync).
>
> While this is not the best way of doing it, this is the method I used:
>
> * start Record,
> * copy the directory to a large enough tmpfs,
> {{{
> cd .sugar/default
> rsync -a org.laptop.RecordActivity /dev/shm
> }}}
> * remove the old directory and create a symlink,
> {{{
> rm -rf org.laptop.RecordActivity && \
> ln -s /dev/shm/org.laptop.RecordActivity
> }}}
> * continue using the Record activity.
>
> (This symlink persists until removed ... and since /dev/shm is empty next
> boot the Record activity will fail to start.)
>
> --
> Ticket URL:
> One Laptop Per Child
Re: Fwd: XO 1.5 frequency scaling
> you're right. there's nothing in powerd related to clocking. powerd > limits itself to managing the display, wlan on/off, and system suspend. > Seemed so, thanks. > > > Did I miss some firmware or kernel update, as I can't load the c7 powersaver > > kernel module in a kernel I built myself. > > are you sure you're running the kernel you built? (i.e., it, and > whatever symlinks it needs to vmlinuz, need to be in /boot and > /bootpart/boot.) Yup, I'm not running it over Fedora but on Gentoo in an external HDD. Some patch missing in the kernel perhaps? Best regards, Tiago > > paul > > > > > > > > > > > == > > > I spent the day/night today working on getting our C states and P states > > > enabled. > > > > > > The good news is that I got C4,C5 and frequency/voltage scaling (P > > > states) working. > > > > > > The bad news is that C5 causes memory corruption and P states don't help > > > much. > > > > > > Enabling C4 seems to save us about 170mW in idle. > > > > > > > Any measurement on how low it goes in C4? > > > > > > > > > > C5 should save us a bit more but with it enabled the system won't boot. > > > It gets all sorts of funky ext4 errors. C5 turns off the L2 cache and > > > the docs say you should flush before entering. I suspect thats not > > > happening. > > > > > > P states currently don't seem to save us enough to be measured. One > > > reason is that our core voltage is set by default to be very close to > > > the minimum. Its at .796V and the minimum is .7V with scaling enabled > > > (+ code hack) the minimum setting drops Vcore to .73V. Its supposed to > > > go to .7 but the volt meter says otherwise. 60mV diff doesn't offer a > > > whole lot of savings. > > > > > > > I see, I thought they could drop it even further. > > > > > > > > > > The CPU frequency slides between 400Mhz and 1GHz and you would think > > > that it would make a large difference but the meter says otherwise. How > > > can that be you ask? The answer is because Linux issues a hlt when > > > idle. If you run the test under OFW then you can create up to 1.5W of > > > power difference by sliding the freq from min to max [1] and holding the > > > Vcore constant. But in idle not so much. The processor already does a > > > very good job of gating the clocks. > > > > > > > > Nice, kudos for VIA. > > > > > > > So this brings us back to what we already knew. The big money on power > > > savings is in our special sauce idle suspend. > > > > > > [1] Turns out you can overclock the processor. Via lists the max > > > multiplier at 16x FSB (100Mhz) which is 1.6Ghz even though its listed as > > > a max of 1Ghz. However if you continue to put values into the multiplier > > > register the power draw continues to increase. I stopped when the > > > system draw had hit 9W cause the XO on the power meter does not have a > > > heat spreader and I didn't want to take the chance of burning it up. > > > = > > > > > > > The heatspreader I can hack with a heatpipe and some coolers, I'm going to > > do it anyway since it is already going to 85ºC in load. The speed is of some > > use to me most of the time, I'm just worried that the VRM can't handle the > > extra current. > > > > Best regards, > > Tiago > > > > > > > > > > -- > > > > > > Richard A. Smith > > > One Laptop per Child > > > ___ > > > Devel mailing list > > > Devel@lists.laptop.org > > > http://lists.laptop.org/listinfo/devel > > > > > part 2 text/plain 129 > > ___ > > Devel mailing list > > Devel@lists.laptop.org > > http://lists.laptop.org/listinfo/devel > > =- > paul fox, p...@laptop.org > > ___ > 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
Re: XO-1.5 bad ogg experience
On Sat, May 8, 2010 at 7:15 AM, Paul Fox wrote: > > well, i hope it won't be necessary, and that powerd's cpu utilization > heuristic will work well enough. but if not, see: > http://dev.laptop.org/git/users/pgf/powerd/tree/powerd#n170 > I don't have any hardware to test :( , so have to wait for others to test if it is suspending or not. Kushal -- http://fedoraproject.org http://kushaldas.in ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: XO 1.5 frequency scaling
tiago wrote: > -- Forwarded message -- > From: Tiago Marques > Date: Sat, May 8, 2010 at 12:17 PM > Subject: Re: XO 1.5 frequency scaling > To: "Richard A. Smith" > > > Hi Richard, > > On Wed, May 5, 2010 at 12:28 AM, Richard A. Smith wrote: > > > On 05/04/2010 07:01 PM, Tiago Marques wrote: > > > > > Let me see if I understand what you said. I understand how it works on > > > desktop and regular laptops. You load the module for the specific power > > > saving feature and either a kernel module to do the job or the userspace > > > module which then allows a daemon to do the frequency scaling. > > > Now the XO 1.5, AFAIK, isn't doing it or powerd is doing it(or openfw). > > > I tried loading the C7 power saver module but it can't find the device. > > > Is it already being taken and should I not worry with frequency scaling > > > although /proc/cpuinfo always shows 1000MHz? > > > > The module is not enabled in the kernel build and in our case appears to > > only offer saving in very limited cases. Yes, you could cap your max > > frequency and max power draw but in general you end up using more > > power*time that way because you keep all the other components that don't > > have sort of power scaling up longer then they would have been because > > it takes longer to do the task. If you decrease the power draw 2x but > > then extend the time 2x you have gained nothing. > > > > > Not my experience, but I'm desktop biased I guess. I was thinking that you > could further lower the core voltage on the XO and get something like 50% > the clock with 25% or less power. But, as you describe below, if VIA managed > such an agressive power gating, it's the way to go. > > > > Feel free to experiment though. The latest versions of powerd have > > power logging built in and if you want a more specific measurement my > > power logging scripts should be useful. > > > > IIRC I had to hack on the driver a bit to make it work. The following > > is a summary email I posted from when I worked on it. > > > > Notes: > > - Ignore the comment about C5. Our CPU does not support C5. > > > > - Ignore the comment about being scared to burn up the CPU. We now have > > thermal throttling enabled and have tested it extensively. Unless you > > turn that off you should not be able to burn up the CPU. > > > > This is on olpc-powerd or the VIA C7 powersaver driver? I couldn't find > anything related to over/underclocking in powerd. you're right. there's nothing in powerd related to clocking. powerd limits itself to managing the display, wlan on/off, and system suspend. > Did I miss some firmware or kernel update, as I can't load the c7 powersaver > kernel module in a kernel I built myself. are you sure you're running the kernel you built? (i.e., it, and whatever symlinks it needs to vmlinuz, need to be in /boot and /bootpart/boot.) paul > > > > > > == > > I spent the day/night today working on getting our C states and P states > > enabled. > > > > The good news is that I got C4,C5 and frequency/voltage scaling (P > > states) working. > > > > The bad news is that C5 causes memory corruption and P states don't help > > much. > > > > Enabling C4 seems to save us about 170mW in idle. > > > > Any measurement on how low it goes in C4? > > > > > > C5 should save us a bit more but with it enabled the system won't boot. > > It gets all sorts of funky ext4 errors. C5 turns off the L2 cache and > > the docs say you should flush before entering. I suspect thats not > > happening. > > > > P states currently don't seem to save us enough to be measured. One > > reason is that our core voltage is set by default to be very close to > > the minimum. Its at .796V and the minimum is .7V with scaling enabled > > (+ code hack) the minimum setting drops Vcore to .73V. Its supposed to > > go to .7 but the volt meter says otherwise. 60mV diff doesn't offer a > > whole lot of savings. > > > > I see, I thought they could drop it even further. > > > > > > The CPU frequency slides between 400Mhz and 1GHz and you would think > > that it would make a large difference but the meter says otherwise. How > > can that be you ask? The answer is because Linux issues a hlt when > > idle. If you run the test under OFW then you can create up to 1.5W of > > power difference by sliding the freq from min to max [1] and holding the > > Vcore constant. But in idle not so much. The processor already does a > > very good job of gating the clocks. > > > > > Nice, kudos for VIA. > > > > So this brings us back to what we already knew. The big money on power > > savings is in our special sauce idle suspend. > > > > [1] Turns out you can overclock the processor. Via lists the max > > multiplier at 16x FSB (100Mhz) which is 1.6Ghz even though its listed as > > a max of 1Ghz. However if you continue to put val
Fwd: XO 1.5 frequency scaling
-- Forwarded message -- From: Tiago Marques Date: Sat, May 8, 2010 at 12:17 PM Subject: Re: XO 1.5 frequency scaling To: "Richard A. Smith" Hi Richard, On Wed, May 5, 2010 at 12:28 AM, Richard A. Smith wrote: > On 05/04/2010 07:01 PM, Tiago Marques wrote: > > > Let me see if I understand what you said. I understand how it works on > > desktop and regular laptops. You load the module for the specific power > > saving feature and either a kernel module to do the job or the userspace > > module which then allows a daemon to do the frequency scaling. > > Now the XO 1.5, AFAIK, isn't doing it or powerd is doing it(or openfw). > > I tried loading the C7 power saver module but it can't find the device. > > Is it already being taken and should I not worry with frequency scaling > > although /proc/cpuinfo always shows 1000MHz? > > The module is not enabled in the kernel build and in our case appears to > only offer saving in very limited cases. Yes, you could cap your max > frequency and max power draw but in general you end up using more > power*time that way because you keep all the other components that don't > have sort of power scaling up longer then they would have been because > it takes longer to do the task. If you decrease the power draw 2x but > then extend the time 2x you have gained nothing. > > Not my experience, but I'm desktop biased I guess. I was thinking that you could further lower the core voltage on the XO and get something like 50% the clock with 25% or less power. But, as you describe below, if VIA managed such an agressive power gating, it's the way to go. > Feel free to experiment though. The latest versions of powerd have > power logging built in and if you want a more specific measurement my > power logging scripts should be useful. > > IIRC I had to hack on the driver a bit to make it work. The following > is a summary email I posted from when I worked on it. > > Notes: > - Ignore the comment about C5. Our CPU does not support C5. > > - Ignore the comment about being scared to burn up the CPU. We now have > thermal throttling enabled and have tested it extensively. Unless you > turn that off you should not be able to burn up the CPU. > This is on olpc-powerd or the VIA C7 powersaver driver? I couldn't find anything related to over/underclocking in powerd. Did I miss some firmware or kernel update, as I can't load the c7 powersaver kernel module in a kernel I built myself. > > == > I spent the day/night today working on getting our C states and P states > enabled. > > The good news is that I got C4,C5 and frequency/voltage scaling (P > states) working. > > The bad news is that C5 causes memory corruption and P states don't help > much. > > Enabling C4 seems to save us about 170mW in idle. > Any measurement on how low it goes in C4? > > C5 should save us a bit more but with it enabled the system won't boot. > It gets all sorts of funky ext4 errors. C5 turns off the L2 cache and > the docs say you should flush before entering. I suspect thats not > happening. > > P states currently don't seem to save us enough to be measured. One > reason is that our core voltage is set by default to be very close to > the minimum. Its at .796V and the minimum is .7V with scaling enabled > (+ code hack) the minimum setting drops Vcore to .73V. Its supposed to > go to .7 but the volt meter says otherwise. 60mV diff doesn't offer a > whole lot of savings. > I see, I thought they could drop it even further. > > The CPU frequency slides between 400Mhz and 1GHz and you would think > that it would make a large difference but the meter says otherwise. How > can that be you ask? The answer is because Linux issues a hlt when > idle. If you run the test under OFW then you can create up to 1.5W of > power difference by sliding the freq from min to max [1] and holding the > Vcore constant. But in idle not so much. The processor already does a > very good job of gating the clocks. > > Nice, kudos for VIA. > So this brings us back to what we already knew. The big money on power > savings is in our special sauce idle suspend. > > [1] Turns out you can overclock the processor. Via lists the max > multiplier at 16x FSB (100Mhz) which is 1.6Ghz even though its listed as > a max of 1Ghz. However if you continue to put values into the multiplier > register the power draw continues to increase. I stopped when the > system draw had hit 9W cause the XO on the power meter does not have a > heat spreader and I didn't want to take the chance of burning it up. > = > The heatspreader I can hack with a heatpipe and some coolers, I'm going to do it anyway since it is already going to 85ºC in load. The speed is of some use to me most of the time, I'm just worried that the VRM can't handle the extra current. Best regards, Tiago > > -- > > Richard A. Smith > One Laptop per Child > ___ > Devel mailing l
Re: XO 1.5 frequency scaling
On Wed, May 5, 2010 at 12:38 AM, Paul Fox wrote: > martin wrote: > > > > Running powertop on your machine is hugely informational once you've > > read the powertop website docs. > > re: powertop -- with silbe's help our battery driver now provides > enough of the expected properties under /sys to let powertop make > crude power measurements [1]. you have to build from their svn, > though, because of a bug that's not normally exposed on machines > using the ACPI driver. (to clarify -- i have the fix -- it's not > in their svn repo yet -- i need to send it in.) > > but as richard implied, a tool like powertop won't help you tune > your laptop much, since it only measures what happens when it's > running. we save so much power with aggressive S3 that the changes > from P-states, and to some extent C-states, are in the noise. > I see, cool. I must say I'm very surprised by how long the XO 1.5 can hold the battery when it's suspended. I have yet to mod my B2 with the wireless ECO and since it always turns off wireless when suspended IIRC it used like 12% of the battery while suspended for 8 hours. Must check this again, it seemed too good to be true and a great work on the power management details! Best regards, Tiago > > paul > [1] richard's logs and tools are far more informative, but it's > fun watching the powertop numbers change. > =- > paul fox, p...@laptop.org > ___ > 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
