Re: XO battery/performance [Devel Digest, Vol 76, Issue 4]
On 06/10/2012 01:07 AM, Yioryos Asprobounitis wrote: Took some time and a lot of juggling and ended up to a lot of questionmarks in black diamonds so I do not really know if I did it right or wrong, but here is the screen log just the same. You may or may not have done anything wrong but the output is not valid. Perhaps your comm settings are wrong? 115200,n,8,1 is what they should be set to. Its exactly the same as if you were connected to the OFW or Linux output. The EC output is readable text and if you press enter with no command you get back a prompt. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance [Devel Digest, Vol 76, Issue 4]
On Mon, Jun 11, 2012 at 08:41:16AM -0400, Richard A. Smith wrote: On 06/10/2012 01:07 AM, Yioryos Asprobounitis wrote: Took some time and a lot of juggling and ended up to a lot of questionmarks in black diamonds so I do not really know if I did it right or wrong, but here is the screen log just the same. You may or may not have done anything wrong but the output is not valid. Perhaps your comm settings are wrong? 115200,n,8,1 is what they should be set to. Not for the screen program, which is what Yioryos was asking about. Just 115200. Adding ,n,8,1 achieves nothing, screen ignores it. One can use cs8 to specify the bits per character, but Linux and Mac OS X default to eight bits already. Parity and stop bits cannot be specified to screen. The port defaults are already good enough. I agree that the unreadable text shows something has gone wrong. But I don't think it is baud rate, parity, bits per character, or stop bit count. I've undone Yioryos' change to the Wiki page. Yioryos, do you still get this strange output? -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance [Devel Digest, Vol 76, Issue 4]
On Sat, Jun 09, 2012 at 10:07:36PM -0700, Yioryos Asprobounitis wrote: Also I had a hard time detaching from the screen. Maybe the wiki page needs some clarification. What C-a means? Capital C, dash, a 3 consecutive characters? ctrl+a? shift-c-a keys together? other? C-a means ctrl+a, that is; press ctrl, press a, release a, release ctrl. The convention is an artefact from the documentation of the screen program. The same convention is used in emacs. I've changed to ctrl+ notation. I don't know what notation is standard. I don't like + or - or / notation because they imply use of those keys. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance [Devel Digest, Vol 76, Issue 4]
--- On Sun, 6/3/12, Richard A. Smith rich...@laptop.org wrote: From: Richard A. Smith rich...@laptop.org Subject: Re: XO battery/performance [Devel Digest, Vol 76, Issue 4] To: Yioryos Asprobounitis mavrot...@yahoo.com Cc: devel@lists.laptop.org Date: Sunday, June 3, 2012, 8:41 AM On 06/03/2012 04:43 AM, Yioryos Asprobounitis wrote: serial connector loaded. Its the connector under the heat spreader. There goes my new XO-1.75... Think of it a a rite of passage. Just to be sure, is the UART 4, CN23, shown in the attached picture in blue. Correct? Correct. If OK, please advise further actions. First upgrade the firmware to the latest version and let it update the EC code. Then just plug up the serial connector and then do a full power cycle of the unit by removing both external power and the battery and then plugging in the problem battery. Send the output. May or may not be anything of interest in that log. Then see if the problem duplicates on the 1.75. You can get a quick reading from the EC of the battery level by using the command 'b3'. Type b3 enter which turns on some simple debug info. You can't leave that on however because it will prevent the EC from going into stop mode. 'b0' will turn it back off. You have to be really quick with the serial commands when the XO is off. When off and running on battery the EC will go into stop mode and it does that really fast. When its in stop mode you can't talk to it on the serial port. I usually have one hand ready to type b3 and then wake the EC up by a very short power button press. Then before it goes back into stop mode type b3enter. Once a second it will output a short battery stat then type b0 to stop it and allow it to go back into stop mode. So hook up the EC serial port and log the output. Then charge up the battery. b3 to get some readings. Disconnect external power and then b0 . You should see it go into stop mode. In 24 hours wake the EC up do b3 to get a 2nd set of readings and then send the log output. Took some time and a lot of juggling and ended up to a lot of questionmarks in black diamonds so I do not really know if I did it right or wrong, but here is the screen log just the same. A power cycle followed bu the b3-b0, followed by a power cycle. Both the client with the broblem battery and the host were XO-1.75 running os13. Also I had a hard time detaching from the screen. Maybe the wiki page needs some clarification. What C-a means? Capital C, dash, a 3 consecutive characters? ctrl+a? shift-c-a keys together? other? Thx -- Richard A. Smith rich...@laptop.org One Laptop per Child screenlog.0 Description: Binary data ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance [Devel Digest, Vol 76, Issue 4]
On 06/03/2012 04:43 AM, Yioryos Asprobounitis wrote: serial connector loaded. Its the connector under the heat spreader. There goes my new XO-1.75... Think of it a a rite of passage. Just to be sure, is the UART 4, CN23, shown in the attached picture in blue. Correct? Correct. If OK, please advise further actions. First upgrade the firmware to the latest version and let it update the EC code. Then just plug up the serial connector and then do a full power cycle of the unit by removing both external power and the battery and then plugging in the problem battery. Send the output. May or may not be anything of interest in that log. Then see if the problem duplicates on the 1.75. You can get a quick reading from the EC of the battery level by using the command 'b3'. Type b3 enter which turns on some simple debug info. You can't leave that on however because it will prevent the EC from going into stop mode. 'b0' will turn it back off. You have to be really quick with the serial commands when the XO is off. When off and running on battery the EC will go into stop mode and it does that really fast. When its in stop mode you can't talk to it on the serial port.I usually have one hand ready to type b3 and then wake the EC up by a very short power button press. Then before it goes back into stop mode type b3enter. Once a second it will output a short battery stat then type b0 to stop it and allow it to go back into stop mode. So hook up the EC serial port and log the output. Then charge up the battery. b3 to get some readings. Disconnect external power and then b0 . You should see it go into stop mode. In 24 hours wake the EC up do b3 to get a 2nd set of readings and then send the log output. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance [Devel Digest, Vol 76, Issue 4]
I don't see anything that looks obviously wrong. So here's a test to see if the EC is going to sleep or not. Run the battery down to where the red LED is active. Then power off the laptop. If the EC goes into stop mode the red LED should go out after a few seconds. If you press a game button the EC should wake up briefly and the led will turn back on then in a few seconds go back out. This battery is really strange... After an O/N with the battery out of the XO tried to run it down and suddenly none of the info in /sys/devices/0.baterry/power_supply/olpc-battery/ was changing after an hour of CPU burn and the battery was showing as Full Shutdown and removing the battery to reset the EC, made it behaved. The battery started from 35% and dropped normally thereafter. As per the suggested test, indeed after shutting down at 9% with the red led on, pressing a game key lights up the red led for ~2 sec. What was striking was that the XO-1.75 used 25% of the battery for 1 run while the XO-1.5 used 65% of the battery! If you are going to do more of this then you really need a better tool than just the battery SOC measurement. I usually look either at the ~/power-logs/pwr-* or directly at /sys//power_supply/olpc-battery/* to check battery status olpc-pwr-log can sample the information on a periodic basis and then my processing scripts can run through those logs and produce various reports. All of my tools are in my olpc-pwrlogs repo git://dev.laptop.org/users/rsmith/olpc-pwrlogs Let me know if you are interested and want to know how to use the tools. Sure. I can understand some bash scripting but python is out of my league, so please advise. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance [Devel Digest, Vol 76, Issue 4]
This battery is really strange... After an O/N with the battery out of the XO tried to run it down and suddenly none of the info in /sys/devices/0.baterry/power_supply/olpc-battery/ was changing after an hour of CPU burn and the battery was showing as Full Shutdown and removing the battery to reset the EC, made it behaved. The battery started from 35% and dropped normally thereafter. Hmm... Perhaps there is some intermittent communication fail between the EC and the battery. Next time things get all messed up reboot into OFW and run 'see-bstate'. Do not remove the battery for a complete power cycle. Just reboot. (It helps if you have serial port connected so you can capture the output) see-bstate will spew a bunch of numbers. From those numbers we can see if the EC is talking to the battery. As per the suggested test, indeed after shutting down at 9% with the red led on, pressing a game key lights up the red led for ~2 sec. Ok. Well its not the EC failing to go into stop mode then. Do you have a XO-1.5 or 1.75? Something with an EC serial connector loaded? What was striking was that the XO-1.75 used 25% of the battery for 1 run while the XO-1.5 used 65% of the battery! If you are going to do more of this then you really need a better tool than just the battery SOC measurement. I usually look either at the ~/power-logs/pwr-* or directly at /sys//power_supply/olpc-battery/* to check battery status olpc-pwr-log can sample the information on a periodic basis and then my processing scripts can run The data in the powerd power log file is a super-set of the data captured by olpc-pwr-log. powerd also captures data on events like when the machine goes to sleep, External power connected/disconnected. If no events happen then its samples the battery info every 300 seconds. olpc-pwr-log samples much more frequently and only samples on a time basis. Its every 20 seconds right now but can be changed by editing the script. 20 seconds is about the minimum you want though or the average power computation has lots of error. running olpc-pwr-log is easy. Grab the one from my repository and copy it over the one that is included in the build. Then just open a terminal or VT and run it. It will generate a log file in the directory you run it. if powerd is running and the machine goes to sleep it won't hurt olpc-pwr-log but you times will be irregular so most of the time I use it I stop powerd first. My python processing tool can also process powerd log files. One difference between them is that the processing tool does not have any statefull analysis (yet) so it doesn't do any thing different when you go from charging to discharging. When looking at summary data such as average power over a run if you have both charging and discharging then the average includes all of them. The graph output will show you the data over time and you can see the ups and down. If I use powerd to log normally force it to generate a new file or I reboot first so a new log file is started. Sure. I can understand some bash scripting but python is out of my league, so please advise. Its not necessary to hack python to use the processing tools. You do need some some python dependencies installed though. You need python-dateutils, and pymatplotlib installed and configured. pymatplot lib needs the backend rendering engine set for your system. (The default is Tk, but it has gtk, and QT). The tools have lots of different options and can tell you many different things but most of those options you probably would not use. To you you just feed the tools the power logs on the command line. process-pwr_log.py logfile will give you a summary of that run. If you feed it multiple files on the command line (such as pwr-* ) then it will produce one line of summary output for each logfile processed. graphy-pwr_log.py can show you lots of different graphs. By default it just shows you voltage and current over time. --avgpwr includes a power graph. graph-pwr_log.py --avgpwr logfile If you feed it multiple log files then you will a graph with multiple traces one trace per log file. Each graph lives in its own window right now so you have to close each one before it exits. If you can't get the python stuff to run then you can always send me your log files and I can process them. -- Richard A. Smith One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance [Devel Digest, Vol 76, Issue 4]
I'm very suspect of this measurement. The 1.5 has a hardware floating point unit and the 1.75 is still using soft-float. Its extremely unlikely that the floating point performance on 1.75 is better than the 1.5. Hard FP status depends on if Yioryos is running 11.3.1 or 12.1.0. Since he said os10 by today's date I'm presuming 12.1.0. The Fedora 17 builds should be hard fp (armv7hl). The Fedora 14-based 11.3.1 builds are not (armv5tel / armv7l kernel). Correct. For the LMbench test the XO-1.75 was funning F17/21012o2 with the correct kernel per dsd's suggestion ( Ok.. I'm still a bit unconvinced though. I would expect the FP unit on the x86 to still beat the ARM. -- Richard A. Smith ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance [Devel Digest, Vol 76, Issue 4]
--- On Sat, 6/2/12, Richard Smith rich...@laptop.org wrote: From: Richard Smith rich...@laptop.org Subject: Re: XO battery/performance [Devel Digest, Vol 76, Issue 4] To: Yioryos Asprobounitis mavrot...@yahoo.com Cc: devel@lists.laptop.org Date: Saturday, June 2, 2012, 8:27 AM This battery is really strange... After an O/N with the battery out of the XO tried to run it down and suddenly none of the info in /sys/devices/0.baterry/power_supply/olpc-battery/ was changing after an hour of CPU burn and the battery was showing as Full Shutdown and removing the battery to reset the EC, made it behaved. The battery started from 35% and dropped normally thereafter. Hmm... Perhaps there is some intermittent communication fail between the EC and the battery. Next time things get all messed up reboot into OFW and run 'see-bstate'. Do not remove the battery for a complete power cycle. Just reboot. (It helps if you have serial port connected so you can capture the output) see-bstate will spew a bunch of numbers. From those numbers we can see if the EC is talking to the battery. As per the suggested test, indeed after shutting down at 9% with the red led on, pressing a game key lights up the red led for ~2 sec. Ok. Well its not the EC failing to go into stop mode then. Do you have a XO-1.5 or 1.75? Something with an EC serial connector loaded? I have the adaptor on the J1 of an XO-1. Will it do? If not, where is CN24? (a picture or a reference to the XO-1 board will help) Thenks for the info regarding olpc-powerlogs. I'll run it for a while on the machine with the problem battery. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance [Devel Digest, Vol 76, Issue 4]
then. Do you have a XO-1.5 or 1.75? Something with an EC serial connector loaded? I have the adaptor on the J1 of an XO-1. Will it do? No. If not, where is CN24? (a picture or a reference to the XO-1 board will help) XO-1 did not ship with an EC connector loaded. That's why I asked about 1.5 or 1.75. You seem to have a 1.75 since you produced lmbench results for it. It should have the EC serial connector loaded. Its the connector under the heat spreader. -- Richard A. Smith One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance [Devel Digest, Vol 76, Issue 4]
Most of the test had empty values but the informative ones (below) show that the XO-1.5 is better in basic integer operations and memory bandwidth while the XO-1.75 is better in float and double operations as well as in memory latency. I'm not sure how much this means for real life usage :-/ I'm very suspect of this measurement. The 1.5 has a hardware floating point unit and the 1.75 is still using soft-float. Its extremely unlikely that the floating point performance on 1.75 is better than the 1.5. Hard FP status depends on if Yioryos is running 11.3.1 or 12.1.0. Since he said os10 by today's date I'm presuming 12.1.0. The Fedora 17 builds should be hard fp (armv7hl). The Fedora 14-based 11.3.1 builds are not (armv5tel / armv7l kernel). Correct. For the LMbench test the XO-1.75 was funning F17/21012o2 with the correct kernel per dsd's suggestion ( http://lists.laptop.org/pipermail/devel/2012-May/035212.html ) The XO-1.5 was running F14/11.3.0 os880 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
