Re: XO battery/performance [Devel Digest, Vol 76, Issue 21]
On 07/21/2012 12:53 PM, Yioryos Asprobounitis wrote: I'm sorry but I did not run any bg-acr! commands except the one you suggested. The only command that I run outside your suggestions is bg-acr@ .bg-acr with no batman.fth/batman-start first, which certainly can not account for the erratic behavior. Commands _like_ 'bg-acr!' that includes all of the bg-* commands and many others. They _require_ batman-start to function. If it hasn't been called then they do it for you. Thus if you have run those command and not run batman-stop then the charging system will behave erratically. bg-acr! changes values that take the EC close to a full cycle to recovery from so even after a full reset the reporting can be incorrect. I keep saying that the battery EC might have a problem There is no battery EC. The battery only has a sensor chip. The EC on the XO talks to that chip and reads voltage, current, temperature, ACR and a few other values. and you just dismiss all the indications (like a full battery reporting as empty) I'm sorry if my last mail came across the wrong way I was in a bit of a hurry before my flight. Its just that I keep telling you that nothing you have presented so far indicates there is a communication problem between the EC and battery. I'll be the very first to tell you when I see something I think is funky. Just like with the rollover bug. I'm not dismissing what you say. I'm just trying to tell you that you aren't doing anything useful debugging wise when you try to figure out whats going on based on the charging LED or what sugar tells you. The use of _any_ of the debugging commands I gave you will screw up the normal battery reporting. If you want to known whats happening when you boot Linux then please do a full power cycle and run olpc-pwr-log. Those log files are much, much, more useful than what the LED/Sugar is doing. The LED/sugar can lie to you but the log files do not. Normally, I boot the laptop without the battery installed, run olpc-pwr-log and then insert the battery. olpc-pwr-log will wait for a battery to show up. including even the fact that EC reports the battery is asleep while the discharge data show that is not. Its not possible for the battery to go to sleep. I don't understand what you are referring to. Oh well, I do not think that one battery in a couple of millions worths all this trouble. Actually I believe it is worth the trouble because there is never just a single problem that doesn't happen to another machine. If you have this failure then there are probably many more. Its just never been reported. I'm happy to keep working on this if you don't mind the time. -- 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 21]
--- On Sun, 7/22/12, Richard A. Smith rich...@laptop.org wrote: Actually I believe it is worth the trouble because there is never just a single problem that doesn't happen to another machine. If you have this failure then there are probably many more. Its just never been reported. I'm happy to keep working on this if you don't mind the time. I'm afraid that I can not be of much help. Let me repeat the problems as I see them, (pretty much as originally stated) - The battery loses too much charge (~12% in 24h) when in an XO but not when out. - The battery has a bit decrease capacity (2.75Ah was the max I ever recorded last month) - The battery miss-communicates its state to the kernel/OS (BTW usually I confirm erratic Sugar readings by looking directly at /sys/class/power_supply/olpc-battery/) After a month of e-mails we hopefully agree in 2 out of the 3 symptoms and have no causes/solutions yet. As I said before, the problem needs an engineer if it is to be investigated any further, and I'm not. You are welcome to the battery. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance [Devel Digest, Vol 76, Issue 21]
On 07/22/2012 04:29 PM, Yioryos Asprobounitis wrote: As I said before, the problem needs an engineer if it is to be investigated any further, and I'm not. You are welcome to the battery. Ok. Well then please send me the battery. Richard Smith One Laptop per Child 222 3rd St. STE 0234 Cambridge, MA 02142 +1 617-714-4589 Thanks for all your help so far. -- 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 21]
--- On Thu, 7/19/12, Richard Smith rich...@laptop.org wrote: - Boot the XO. Sugar or OFW either will work. - Run on battery and allow the battery to discharge until is says its 90% - Connect power and let the battery charge to full. - Reboot XO and stop at OFW. - ok batman-start - ok 0 bg-acr! - Verify the ACR is really zero. - ok bg-acr@ .bg-acr (Should print zero) ACR: -0.42 - Remove battery (Wait 24 hours, you can do whatever you want with the XO) - Boot XO and stop at OFW - ok batman-start - Insert battery - ok bg-acr@ .bg-acr ACR: -0.84 - ok batman-stop - Poweroff - Remove AC - 25 h battery IN the XO - remove battery - Plug AC - Boot XO and stop at OFW - ok batman-start - Insert battery - ok bg-acr@ .bg-acr ACR -469.52 - ok batman-stop - Remove AC - ok boot Power LED red. Sugar says 2% battery but works! Reboot - ok bg-acr@ .bg-acr (no batman.fth/batman-start) ACR -526.32 , LED red, Sugar 2% battery poweroff -remove battery -insert battery - ok bg-acr@ .bg-acr (no batman.fth/batman-start) ACR -566.32 , LED red, Sugar auto shuts off Tried also after batman-start/stop remove battery etc, no difference LED red, Sugar auto shuts off. Booted another OS, power LED red but works fine with battery (used it for 10-15 min) Moved the battery on another XO just in case, power LED red, Sugar auto shuts off. Booted up with battery, plugged AC, power LED stays red. Remove battery, power LED stays red! Powerd off with AC power LED stays red! Remove AC, power LED went off. Booted without battery, inserted battery, battery shows empty and charging. Charged to about 15% slowly, then jumped to 81% and then 97% in under 1 min and the power LED turned green! Now, you are going to say again that I do not know what I'm doing, but sure none of these looks very normal behavior to me and may have to do with how the battery communicates its state than its state per se. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance [Devel Digest, Vol 76, Issue 21]
On 07/21/2012 03:05 AM, Yioryos Asprobounitis wrote: - ok bg-acr@ .bg-acr (Should print zero) ACR: -0.42 Hmm... I was expecting zero. I'm traveling to Taiwan right now and don't have 1.0 or 1.5 with me to check. - Insert battery - ok bg-acr@ .bg-acr ACR: -0.84 .42mAh / 24 hours = 17.5uA so very low. Does not appear to be a hardware fault in the battery. - ok batman-stop - Poweroff - Remove AC - 25 h battery IN the XO - remove battery - Plug AC - Boot XO and stop at OFW - ok batman-start - Insert battery - ok bg-acr@ .bg-acr ACR -469.52 Assuming -.84mAh was where you started thats 468.68 mAh / 25h = 18.7mA which is just about what olpc-pwr-log indicated was happening. This really smells like the EC not going to sleep although I thought we proved it was going to sleep with an earlier test. (Low battery LED going out when you power off) Please dump the registers and EEPROM (bat-dump-banks) again and I'll program them into a battery and test it on a XO-1. No rush though I won't be able to do anything with this for at least 2 weeks when I back in Boston and working. Perhaps I'll think of some other thing to look at between now and then. -insert battery - ok bg-acr@ .bg-acr (no batman.fth/batman-start) commands like bg-acr@ require batman-start to work correctly. If batman-start has not been called then they will call it for you. We call it explicitly so that the charging system is disabled prior to inserting the battery. Booted up with battery, plugged AC, power LED stays red. This is an invalid condition. With AC connected you should either have: Blinking red: Error yellow (some say orange): Charging Green: Full If its not one of the above then either the EC charging system is disabled in which case the LED values are somewhat random or your power adapter is not providing power. Booted without battery, inserted battery, battery shows empty and charging. Charged to about 15% slowly, then jumped to 81% and then 97% in under 1 min and the power LED turned green! Now, you are going to say again that I do not know what I'm doing, but sure none of these looks very normal behavior to me and may have to do with how the battery communicates its state than its state per se. Yes and I'll continue to say it as long as you continue to do things that are invalid and will produce nonsensical results. I've told you a few times that when you run commands like bg-acr! that you are modifying important values outside of the EC and that until you do a full discharge/recharge cycle normal reporting won't yield valid results. The jumps are when the EC detects specific conditions and tries to reset the SOC accordingly. Normal and expected. If you want to understand whats going on the please run olpc-pwr-log so you can observe the voltage and current and see when the EC changes things based on those values. -- 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 21]
--- On Sat, 7/21/12, Richard A. Smith rich...@laptop.org wrote: Yes and I'll continue to say it as long as you continue to do things that are invalid and will produce nonsensical results. I've told you a few times that when you run commands like bg-acr! that you are modifying important values outside of the EC and that until you do a full discharge/recharge cycle normal reporting won't yield valid results. I'm sorry but I did not run any bg-acr! commands except the one you suggested. The only command that I run outside your suggestions is bg-acr@ .bg-acr with no batman.fth/batman-start first, which certainly can not account for the erratic behavior. You are certainly free to disregard whatever I say/describe, but can not justify it by inappropriate commands, because they were not any. All the commands issued are described precisely. I keep saying that the battery EC might have a problem and you just dismiss all the indications (like a full battery reporting as empty) including even the fact that EC reports the battery is asleep while the discharge data show that is not. Oh well, I do not think that one battery in a couple of millions worths all this trouble. Have a good trip. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance [Devel Digest, Vol 76, Issue 21]
On Wed, Jul 18, 2012 at 11:43 PM, Yioryos Asprobounitis mavrot...@yahoo.com wrote: At which point exactly the - insert battery step goes between - Remove battery and - ok bg-acr@ .bg-acr ? Ooops. That's kind of important. Sorry. Updated list below. You need to insert the battery after you do batman-start because batman-start disables the EC's charging system. Its stays disabled until you do batman-stop or until you reset the EC. --- On Wed, 7/18/12, Richard Smith rich...@laptop.org wrote: - Start with the XO in a clean working condition. ie remove all power and battery. - Boot the XO. Sugar or OFW either will work. - Run on battery and allow the battery to discharge until is says its 90% - Connect power and let the battery charge to full. - Reboot XO and stop at OFW. - ok batman-start - ok 0 bg-acr! - Verify the ACR is really zero. - ok bg-acr@ .bg-acr (Should print zero) - Remove battery (Wait 24 hours, you can do whatever you want with the XO) - Boot XO and stop at OFW - ok batman-start - Insert battery - ok bg-acr@ .bg-acr -- 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 21]
On an XO-1 The reading is -4610.42 (!?) Its a 2's compliment number. Negative values are normal. But you need more than 1 reading. A single reading of the ACR doesn't tell you anything unless you reset it to a known value before you start. Reboot to Sugar and got very little battery At no point the charge light came up (green, red, or orange/yellow) run 0 bg-acr! and then bat-recover. Indeed the battery looked drained (6.9 Volts) and charged but took took just few mAh before it jumped to 7.4 volts. Still no battery LED We are running debugging commands outside the EC. All reporting normal battery status reporting is invalid until you run a discharge and recharge cycle Also bat-recover is useless for this problem. I may be way off, but judging from the erratic readings and LED behavior I would think that might be an issue with the battery EC. Anyway to talk to it and make it behave? Yes you are way off because you don't understand what you are doing. I'll be more specific in my instructions. Though if interested I think would be much more efficient if you check the battery in person ;) I'm mildly curious but what if you send it to me and then the problem does not duplicate? I'd rather sort it out in the known problem case. If not, let me have clear what you want exactly since is not clear to me from your latter mail if after the first run, AC is needed and the XO should start with AC only or battery only of both together, or doesn't matter. Here's a specific procedure. We are going to zero the ACR register so that you don't have to keep track of the prior reading. - Start with the XO in a clean working condition. ie remove all power and battery. - Boot the XO. Sugar or OFW either will work. - Run on battery and allow the battery to discharge until is says its 90% - Connect power and let the battery charge to full. - Reboot XO and stop at OFW. - ok batman-start - ok 0 bg-acr! - Verify the ACR is really zero. - ok bg-acr@ .bg-acr (Should print zero) - Remove battery (Wait 24 hours, you can do whatever you want with the XO) - Boot XO and stop at OFW - ok batman-start - ok bg-acr@ .bg-acr That number will be the amount of capacity lost. -- 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 21]
--- On Wed, 7/18/12, Richard Smith rich...@laptop.org wrote: - Start with the XO in a clean working condition. ie remove all power and battery. - Boot the XO. Sugar or OFW either will work. - Run on battery and allow the battery to discharge until is says its 90% - Connect power and let the battery charge to full. - Reboot XO and stop at OFW. - ok batman-start - ok 0 bg-acr! - Verify the ACR is really zero. - ok bg-acr@ .bg-acr (Should print zero) - Remove battery (Wait 24 hours, you can do whatever you want with the XO) - Boot XO and stop at OFW - ok batman-start - ok bg-acr@ .bg-acr At which point exactly the - insert battery step goes between - Remove battery and - ok bg-acr@ .bg-acr ? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance [Devel Digest, Vol 76, Issue 21]
1) Connect XO 1 or 1.5 to external power. 2) Boot the machine and stop at the open firmware prompt 3) Allow battery to charge up up until full. 4) print out the ACR with: ok bg-acr@ .bg-acr 5) remove battery 6) record the printed ACR number somewhere 7) Note time of battery removal 8) Wait 24 hours. 9) repeat steps 1-4 I see I was a bit hasty here and this is not quite correct. Step 3 should be skipped and replaced with: ok batman-start That way the EC battery subsystem is disabled and it won't try to charge. Then you can do step 4. 10) subtract the 2 ARC numbers to the the net ACR. 10) subtract the 2 ACR numbers to get the net ACR. -- 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 21]
On 07/04/2012 12:20 PM, Yioryos Asprobounitis wrote: 0 bg-acr! solved the problem of the erratic reading. Logs look more reasonable now (though there is still a sudden jump from 87 to 96% during charging in one log. Thats normal. There isn't any calibration of the capacity as the capacity of the battery decreases. So while charging its going to reach full sooner. When its full the SOC is set to 97%. Battery capacity looks also improved (2.8Ah in one run) I don't see any of your logs that have 2.8Ah they all look like 2.5Ah and 2.6Ah to me. Which log are you referring to? However, the original issue of battery losing ~12% charge per day while in the XO with the laptop off, is there. There is certainly something up with your battery. The charging log shows where the problem is. Look at line 386 in pwr-120703-010410-355aaa250043.csv . Thats where the battery stop reaches its full condition (Voltage@ 7.4V and current 120mA). Normally the status would switch to Full and the current would bounce around very close to zero. Your battery however has a constant discharge current of 16mA. So despite having the power connected your battery is slowly discharging. This seem strange but its possible because when the EC detected the battery was full it turned off the mosfet that is in the charging path. So the battery is isolated from the system. Only when you unplug power does the mosfet re-engage so the battery can then supply power. If you want to prove its the battery then try the same test on other XO-1s and on your 1.75. Another test you could do is to see if the ACR changes with the battery removed from the laptop. You can do this with batman. The steps would be: 1) Connect XO 1 or 1.5 to external power. 2) Boot the machine and stop at the open firmware prompt 3) Allow battery to charge up up until full. 4) print out the ACR with: ok bg-acr@ .bg-acr 5) remove battery 6) record the printed ACR number somewhere 7) Note time of battery removal 8) Wait 24 hours. 9) repeat steps 1-4 10) subtract the 2 ARC numbers to the the net ACR. According to your log your average draw is 16.4mA. So if you let it sit for 24h I would expect your net acr to be in the range of 390 - 400 mAh (the number is in uAh so thats 39 to 40) If it happens outside the XO then you know its in the battery. If not then its some interesting combination of battery and XO. -- 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
On Fri, Jun 29, 2012 at 12:19 AM, Mikus Grinbergs mi...@bga.com wrote: DISCLAIMER: I am not asking for help; I'm merely sharing my experiences I have an XO-1 which with recent q2f roms might boot up with the power light green, or might boot up with the power light blinking red (and the battery icon in Frame claiming not connected). Blinking Red is error. Next time it happens can you please boot to OFW and do ok watch-battery Then press a key to make watch-battery exit. When it exits it will tell you what the error is. Please pass that on. The last time it booted up with a blinking red power light, I kept on using that XO-1 as is. After 100+ hours of operation (it *was* connected to A/C all the time) the behavior of that XO-1 was perfectly NORMAL (except for the blinking red power light). Sure. Blinking red is basically the same as if you did not have a battery installed. -- 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 21]
After that test, I run bat-recover once more I noticed several strange things. Running bat-recover is unnecessary and for your battery basically useless. Also bat-recover runs outside of normal battery processing so your SoC values (the %) may be invalid until you do a full discharge or charge. What I can decipher from all these is that a) the battery has decreased capacity (or for some reason stops charging after ~70% full) b) at times, the controller is not transmitting/sensing the battery state properly. c) The battery indeed looses too much charge while in the XO and this may not be related to its decreased capacity. You can hopefully see more things from these. d) You have hit a rare EC bug. The gas gauge chip in the battery tracks the ACR value with a signed 16bit number but the counter does not wrap when it reaches the end. The number of ACR counts between charge and discharge is never equal so over time the counter will tend to drift one way or the other. In the 1.75 EC code I deal with this by manually wrapping the count to the other extreme. This keeps the 1% SOC values ticking since they are relative, however, I failed to realize that this totally screws up my logging scripts which measure the net difference in ACR from the start to the finish of the run. I _just_ discovered this last week on my battery testbed. You can see this in the logs: 1340445105,72,6442210,-593359,3126,-13648333,Discharging,-861250,87 1340445125,72,6438550,-597135,3125,-13652083,Discharging,-865000,87 1340445146,72,6425740,-596744,3126,13650416,Discharging,26437499,88 1340445166,72,6439160,-629427,3122,1364,Discharging,26433749,88 Notice it jumped from -number to +number and the net ACR reading went off the scale. XO-1 and 1.5 do not have the manual wrapping code so when they reach and extreme the counter just stops. In theory its self correcting as once you hit a stop then the amount of ACR in the other directly would be much more and would pull the counter back the other way but perhaps there's more to it than that. This may or may not be the source of your original problem but it does prevent the power measurement script from getting an accurate reading. The fix is simple. Put the battery in an XO-1.5 and boot to OFW. Then at the ok prompt do the following. Note that it has to be a 1.5 as batman does not work on a 1.75 ok 0 bg-acr! Thats a zero not an O. This will reset the ACR register to zero. you can then look at it with: ok bg-acr@ .bg-acr After you do that then please run another discharge/charge/discharge cycle while running olpc-pwr-log and resend the results. -- Richard A. Smith One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance
DISCLAIMER: I am not asking for help; I'm merely sharing my experiences I have an XO-1 which with recent q2f roms might boot up with the power light green, or might boot up with the power light blinking red (and the battery icon in Frame claiming not connected). The last time it booted up with a blinking red power light, I kept on using that XO-1 as is. After 100+ hours of operation (it *was* connected to A/C all the time) the behavior of that XO-1 was perfectly NORMAL (except for the blinking red power light). I have since twice booted that XO-1 -- both times the power light came up green (as it should). mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance [Devel Digest, Vol 76, Issue 21]
On 06/12/2012 12:26 PM, Yioryos Asprobounitis wrote: OK Attached are the screenlogs from the serial output screenlog.charging is yesterdays log whith half full to fully charged battery 2339275:LDACR Update request ACR:-19791 LDACR:-19792 2339471:GC_LDACR=-19792 SOC = 58 2470692:LDACR Update request ACR:-19722 LDACR:-19792 2470857:GC_LDACR=-19792 SOC = 95 2477403:LDACR Update request ACR:-19719 LDACR:-19720 2477565:GC_LDACR=-19720 SOC = 96 2665019: LCS:8 CFC:4 CHG=1 Vb:7395 Vavg:0x5eb3 Bat Full Your battery jumped from 58% to Full while only receiving around 30mAh of charge. So it has issues. For an older battery I would suspect charge balance symptom but your serial number starts with 008 which is beyond the lot of problem batteries and you have indicated you already ran bat-recover. So either your battery was not really at 58% or its suffered a lot of capacity loss. The next step would be to do a full discharge/recharge/discharge cycle while running olpc-pwr-log (stop powerd first) to measure the existing capacity. A quick summary of the procedure: - Boot laptop; stop powerd; run olpc-pwr-log; disconnect external power let laptop power off shut off. - Remove battery;connect external power; boot; stop powerd; run olpc-pwr-log; insert battery; let charge to full; - Ctrl-C to stop olpc-pwr-log; re-run olpc-pwr-log; disconnect external power; let laptop power off; You can try to figure out the log files from the code I previously pointed you at or you can send them to me. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Re: XO battery/performance[ Devel Digest, Vol 76, Issue 21]
Could you please do another test, to verify that screen is not configuring the serial port any differently with or without ,n,8,1. You don't need to connect the two laptops together, just use the one you use as the serial terminal. The test uses the stty program to display the serial port configuration. Here you are. However I need to have the the 2 XOs connected because without it /dev/ttyUSB0 does not exist and if I connect just the adapter then stty fails with resource busy $ screen /dev/ttyUSB0 115200 * Today the output was readable! :-? [screen is terminating] [olpc@xo-74-39-1a ~]$ stty --all /dev/ttyUSB0 speed 115200 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^H; eof = ^D; eol = undef; eol2 = undef; swtch = undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 100; time = 2; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke $ screen /dev/ttyUSB0 115200,n,8,1 [screen is terminating] [olpc@xo-74-39-1a ~]$ stty --all /dev/ttyUSB0 speed 115200 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^H; eof = ^D; eol = undef; eol2 = undef; swtch = undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 100; time = 2; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke [olpc@xo-74-39-1a ~]$ screen /dev/ttyUSB0 9600,n,8,1 **HERE I get the questionmark in back diamond output** [screen is terminating] [olpc@xo-74-39-1a ~]$ stty --all /dev/ttyUSB0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^H; eof = ^D; eol = undef; eol2 = undef; swtch = undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 100; time = 2; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Re: XO battery/performance[ Devel Digest, Vol 76, Issue 21]
On Tue, Jun 12, 2012 at 11:07:44PM -0700, Yioryos Asprobounitis wrote: James wrote: Could you please do another test, to verify that screen is not configuring the serial port any differently with or without ,n,8,1. You don't need to connect the two laptops together, just use the one you use as the serial terminal.? The test uses the stty program to display the serial port configuration. Here you are. Thanks. Your results prove the ,n,8,1 is ineffective, and it must have been line noise that caused your unreadable output last time. However I need to have the the 2 XOs connected because without it /dev/ttyUSB0 does not exist and if I connect just the adapter then stty fails with resource busy stty will fail with device or resource busy if screen is running at the time that stty is run. Or, modemmanager may have been trying to send AT commands to the serial adapter to see if it is a modem. This is one reason why I don't like using our OLPC Fedora builds as serial terminals! http://wiki.laptop.org/go/Serial_adapters#Linux has a note about modemmanager. So it probably wasn't connecting the two laptops that resolved the device or resource busy error for you. It was the passing of time, enough to let modemmanager finish probing. $ screen /dev/ttyUSB0 115200 * Today the output was readable! :-? Good. Therefore the problem was line noise, probably caused by the contacts bouncing as they were mated, or by an earth loop. [olpc@xo-74-39-1a ~]$ screen /dev/ttyUSB0 9600,n,8,1 **HERE I get the questionmark in back diamond output** Good. Totally expected, because the EC would be transmitting at 115200 baud, with the serial adapter configured for 9600 baud, and the resulting garbage data is translated by Terminal into black diamonds. (I didn't think to warn you of this, because I had planned that the tests you did were without any connection between the two laptops. Thanks for taking the initiative.) You can reduce the chance of contact noise derailing the transmission by connecting the two laptops in a specific order: - shutdown the target laptop, - remove power cable and batteries from the target laptop, - connect serial cable between laptops, - restart screen, - insert battery into the target laptop, which will start the EC running, and data will begin to appear, - proceed with your test. This ensures that at the time the contacts are mated, there is no software reading the data, and no data being transmitted. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Re: XO battery/performance[ Devel Digest, Vol 76, Issue 21]
You can reduce the chance of contact noise derailing the transmission by connecting the two laptops in a specific order: or maybe adding ,n,8,1 in the command ?... (I still think is a good idea to add it in the wiki. Even with the notion that although not necessary may reduce unexpected results stemming from line noise or race with the modem manager ;) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Re: XO battery/performance[ Devel Digest, Vol 76, Issue 21]
On Wed, Jun 13, 2012 at 12:16:13AM -0700, Yioryos Asprobounitis wrote: You can reduce the chance of contact noise derailing the transmission by connecting the two laptops in a specific order: or maybe adding ,n,8,1 in the command ?... No, that will make no difference. (I still think is a good idea to add it in the wiki. Even with the notion that although not necessary may reduce unexpected results stemming from line noise or race with the modem manager ;) Heh. ,n,8,1 should not be added to the Wiki for the usage of the screen program, because it does nothing, and I would not have the Wiki deceive anybody. The line noise depends on the power supplies being used, and the amount of isolation, and the way in which the contacts are mated ... so many variables, if we documented them all we'd have a tutorial on using serial ports ... in an age where they are rarely used by most people. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Re: XO battery/performance[ Devel Digest, Vol 76, Issue 21]
Perhaps your comm settings are wrong? 115200,n,8,1 is what they should be set to. That did the trick (thus my change in the wiki) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Re: XO battery/performance[ Devel Digest, Vol 76, Issue 21]
On Mon, Jun 11, 2012 at 11:17:06PM -0700, Yioryos Asprobounitis wrote: ? Perhaps your comm settings are wrong?? 115200,n,8,1 is what they should be set to.? That did the trick (thus my change in the wiki) I think it was coincidence. Please try without it. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Re: XO battery/performance[ Devel Digest, Vol 76, Issue 21]
? Perhaps your comm settings are wrong?? 115200,n,8,1 is what they should be set to.? That did the trick (thus my change in the wiki) I think it was coincidence. Please try without it. At least in my setting ie XO-1.75 embedded keyboard model with the problem battery and the adapter connected to the UART 4 port and XO-1.75 HS keyboard running screen, n,8,1 makes all the difference. Someone else may want to try this with XO-1.75s (os13) Here is the log when I was trying with/without 3805384:SDI: Host not ready 3805838: Vb: 6616 I: -454 W: -3003 SOC:87 ACR:-20656 PL:1 L:0 sleep: 0 3806843: Vb: 6634 I: -539 W: -3575 SOC:87 ACR:-20656 PL:1 L:0 sleep: 0 3807004:SDI: Host ready event mask was 0x, is now 0x ÆãąùçîÉåáãáÄÀáÏääìÈÍæŽÎ‡ÂÃÄ%ùÎÂâÆäàùÂàíÀùÃÂãÄÀùÂâãÄàùÂàáÆàùÂÂÃäÅù‚‡€…ùÎâÃÈàùÃÂäÅùîçã‚âƒäàùÂâãæÁùâ‚€…ùâÂäâÂâäâù††€…ù†ãÄùÃâãÄâùâÂÁÄÀùâÃÈàùâ†ÀùââÄàùâàáÄàùÆÂãàùÂÂäàÂâáÄàùÃâãÄÀùÃÂáæâùÂâƒäâùâÂãÄ àùâãäàù‡ÂÃÄÀùâÂãÄÀùÂàÃÄÀù‚‚†ÀÀùÂàãæÀùâàãÀàùâÂÂäâùÃâãäÀùÂâãæÁùâÂÄÀùâÂÂä ùÂâ†ÄÅù‡ÂŠÀùÂàþĄùÃÂäàù‚ÂÄÀùÂâÄàùâàÂäÀùÃàÂäâùÂâáäàù‚ÂÂÄàùâÂãÀùÇáå…ùââãæâùâÂÁäâùÂàÀÁù4030807: Vb: 6584 I: -404 W: -2659 SOC:87 ACR:-20708 PL:1 L:0 sleep: 0 4031813: Vb: 6581 I: -412 W: -2711 SOC:87 ACR:-20708 PL:1 L:0 sleep: 0 4032817: Vb: 6586 I: -404 W: -2660 SOC:87 ACR:-20708 PL:1 L:0 sleep: 0 4033821: Vb: 6584 I: -407 W: -2679 SOC:87 ACR:-20709 PL:1 L:0 sleep: 0 4034826: Vb: 6583 I: -404 W: -2659 SOC:87 ACR:-20709 PL:1 L:0 sleep: 0 4035830: Vb: 6586 I: -404 W: -2660 SOC:87 ACR:-20709 PL:1 L:0 sleep: 0 4036835: Vb: 6582 I: -404 W: -2659 SOC:87 ACR:-20710 PL:1 L:0 sleep: 0 4037839: Vb: 6580 I: -416 W: -2737 SOC:87 ACR:-20710 PL:1 L:0 sleep: 0 4038843: Vb: 6580 I: -404 W: -2658 SOC:87 ACR:-20710 PL:1 L:0 sleep: 0 4039848: Vb: 6580 I: -404 W: -2658 SOC:87 ACR:-20710 PL:1 L:0 sleep: 0 †ÂƒÄàùââãÄÁùÂÂßÄÀùÂÃąùÂÂÍâù ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance [Devel Digest, Vol 76, Issue 21]
From: Richard A. Smith rich...@laptop.org To: devel@lists.laptop.org Subject: Re: XO battery/performance [Devel Digest, Vol 76, Issue 4] Message-ID: 4fd5e76c.3010...@laptop.org Content-Type: text/plain; charset=UTF-8; format=flowed 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. OK Attached are the screenlogs from the serial output screenlog.charging is yesterdays log whith half full to fully charged battery screenlog.23h.brief is the b3-b0 session 23h later screenlog.23h.power_cycle is a full power cycle 23h latter Hopefully will be informative/diagnostic logs.tar.gz Description: GNU Zip compressed data ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Re: XO battery/performance[ Devel Digest, Vol 76, Issue 21]
On Tue, Jun 12, 2012 at 09:15:48AM -0700, Yioryos Asprobounitis wrote: ? Perhaps your comm settings are wrong?? 115200,n,8,1 is what they should be set to.? That did the trick (thus my change in the wiki) I think it was coincidence.?? Please try without it. At least in my setting ie XO-1.75 embedded keyboard model with the problem battery and the adapter connected to the UART 4 port and XO-1.75 HS keyboard running screen, n,8,1 makes all the difference. Thanks for testing again. Richard was using a convention that screen does not use. The reason I thought it was coincidence was that the screen program does not behave any differently for me with or without ,n,8,1 and the source code of screen confirms there should be no difference: http://dev.laptop.org/~quozl/z/1SeZgA.txt This is the function that processes the baud rate option. It is the only place in the code where serial port configuration is set. There is nothing in there that should notice the presence or absence of ,n,8,1 That it works differently for you, reproducibly, means there is some other effect happening, and we should try to get to the bottom of it. Unexplained effects can lead to problems later on. Could you please do another test, to verify that screen is not configuring the serial port any differently with or without ,n,8,1. You don't need to connect the two laptops together, just use the one you use as the serial terminal. The test uses the stty program to display the serial port configuration. 1. start screen /dev/ttyUSB0 115200, 2. exit screen with ctrl+a k, 3. show the serial port configuration with stty --all /dev/ttyUSB0, 4. start screen /dev/ttyUSB0 115200,n,8,1, 5. exit screen with ctrl+a k, 6. show the serial port configuration with stty --all /dev/ttyUSB0, 7. start screen /dev/ttyUSB0 9600,n,8,1, 8. exit screen with ctrl+a k, 9. show the serial port configuration with stty --all /dev/ttyUSB0. When I do this test with an XO-1.75 os13, there is never any difference in the number of bits per character setting, which is shown by stty as cs7 vs cs8, or in the number of stop bits, which is shown as -cstopb (for one), and cstopb (for two). I do see the baud rate difference when I have changed the baud rate. -- 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 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
On Sat, Jun 2, 2012 at 3:12 AM, Samuel Greenfeld greenf...@laptop.org wrote: On Fri, Jun 1, 2012 at 8:07 PM, Richard A. Smith rich...@laptop.org wrote: On 05/30/2012 03:34 AM, Yioryos Asprobounitis wrote: 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). Looking at those numbers I am quite certain that he is using F17 and hardfp on the 1.75. Floating Point performance of the VIA vx855 chipset is a known limitation. It is something that they fixed in the next generation vx900 chipset. As for the integer math. Most the simple integer benchmarks come down to clock frequency and integer pipelines, both of which the x86 processor beats the ARM on. Theoretically these operations could be faster on our ARM processor as it has dual issue instructions, meaning some instructions can be handled by the core at the same time. I don't think we are taking full advantage of this functionality as I believe gcc needs to be told about it and then software recompiled with the proper tuning options. That patch was just submitted by Marvell upstream, and we still have to test it. Once I get everything built I will try to run some tests to compare against your results, or possibly provide some binaries you can run on your system. Overall I believe the ARM chipset is a win on all fronts. Yes it doesn't blow away the previous generation on raw processing power but really the proper metric to look at in our usage scenario is processing per watt. On top of that the ARM SOC is able to do things like encode/decode 720p video using a special DSP. One of the design principles of ARM is to not make a single chip that does everything really fast, but instead combine a group of specialized chips that are efficient at what they do yet provide a good overall computing experience. Thanks for the numbers, it should be good to revisit this as we move forward with other optimizations. -Jon ___ 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
Looking at those numbers I am quite certain that he is using F17 and hardfp on the 1.75. Floating Point performance of the VIA vx855 chipset is a known limitation. It is something that they fixed in the next generation vx900 chipset. Got a reference for this known limitation ? -- 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]
--- 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
On 05/30/2012 03:34 AM, Yioryos Asprobounitis wrote: If you want an idea of low-level performance, I can suggest running LMBench. Got the Debian lmbench_3.0-a7 source that compiles and runs fine w/o bitkeeper. Run the hardware part of the tests on the XO-1.5 (os880) and xo-1.75 (os12- correct kernel) with the same configuration. 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. 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. 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. -- 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
On Fri, Jun 1, 2012 at 8:07 PM, Richard A. Smith rich...@laptop.org wrote: On 05/30/2012 03:34 AM, Yioryos Asprobounitis wrote: 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). ___ 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
Re: XO battery/performance
If you want an idea of low-level performance, I can suggest running LMBench. Got the Debian lmbench_3.0-a7 source that compiles and runs fine w/o bitkeeper. Run the hardware part of the tests on the XO-1.5 (os880) and xo-1.75 (os12- correct kernel) with the same configuration. 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! 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 :-/ But since I did it, here are the results and a comparison based on the best of 3 values for each machine (hopefully the text alignment will be preserved). L M B E N C H 3 . 0 S U M M A R Y (Alpha software, do not distribute) Basic system parameters -- Host OS Description Mhz tlb cache mem scal pages line par load bytes - - --- - - -- xo-1.5Linux 2.6.35. i686-pc-linux-gnu 10006464 2.39001 xo-1.75 Linux 3.0.19_armv7l-linux-gnu 796 832 1.1 Basic integer operations - times in nanoseconds - smaller is better --- Host OS intgr intgr intgr intgr intgr bit addmuldivmod - - -- -- -- -- -- xo-1.5Linux 2.6.35. 1.0100 0.0400 1.3500 96.5 55.2 xo-1.75 Linux 3.0.19_ 1.2600 0.1400 3.8800 153.5 33.8 1.5 1.75 1.2475 3.5 2.874 1.590 0.612 Basic float operations - times in nanoseconds - smaller is better - Host OS float float float float addmuldivbogo - - -- -- -- -- xo-1.5Linux 2.6.35. 7.0300 7.5400 73.3 92.5 xo-1.75 Linux 3.0.19_ 6.2800 7.5400 26.4 50.5 1.75 1.5 1.119 1.0002.777 1.832 Basic double operations - times in nanoseconds - smaller is better -- Host OS double double double double addmuldivbogo - - -- -- -- -- xo-1.5Linux 2.6.35. 7.0300 8.0400 73.5 92.5 xo-1.75 Linux 3.0.19_ 6.2800 7.5400 44.0 76.9 1.75 1.5 1.119 1.0661.670 1.203 *Local* Communication bandwidths in MB/s - bigger is better - HostOS Pipe AFTCP File Mmap Bcopy Bcopy Mem Mem UNIX reread reread (libc) (hand) read write - - -- -- -- -- - xo-1.5Linux 2.6.35. 306.1 307.0 458. 646.6 xo-1.75 Linux 3.0.19_ 151.0 143.6 216. 328.1 1.5 1.752.02 2.13 2.12 1.97 Memory latencies in nanoseconds - smaller is better (WARNING - may not be correct, check graphs) -- Host OS Mhz L1 $ L2 $Main memRand memGuesses - - --- --- xo-1.5Linux 2.6.35. 1000 6.0720 29.1 100.7 361.7 xo-1.75 Linux 3.0.19_ 796 3.8060 19.3 99.8 257.7 1.75 1.51.5951.508 1.009 1.404 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance
--- On Mon, 5/28/12, Martin Langhoff martin.langh...@gmail.com wrote: H. Sorry, I disagree here. You have usage cases, and they are very different from each other. There isn't much normal. I would agree with this. The original test although intended for other things, suggested that the ARM CPU (a major difference in the XO-1.75) is significant more efficient (output/watt) but also less capable (output/time) than the x86 of the XO-1.5. I have the sense that both of these are generally accepted as trends but the extend of gains and losses is not quite clear. I would be happy to try other recommended tests that may be more representative/appropriate to better quantify CPU performance and efficiency differences. In the mean time I'll wrestle with lmbench and see what comes out. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance
--- On Mon, 5/28/12, Jon Nettleton jon.nettle...@gmail.com wrote: From: Jon Nettleton jon.nettle...@gmail.com Subject: Re: XO battery/performance To: Yioryos Asprobounitis mavrot...@yahoo.com Cc: OLPC Devel devel@lists.laptop.org Date: Monday, May 28, 2012, 3:45 AM *snip* http://lists.laptop.org/pipermail/devel/2012-May/035198.html ) I also tried to test the XO-1(os880), XO-1.5(os883) and -1.75(os10) battery life and thought to report it. It might be of help to someone. os10 is very much a development release and not great for testing. In particular graphics acceleration was not working properly, so this test is strictly testing the cpu. *snip* I can appreciate that this is far from a CPU/computer performance test but taking counts just as an *indication* of CPU/FPU performance would imply that the XO-1.75 is 65% faster than the XO-1 but 40% slower(?) than the XO-1.5. see above reasoning as to why this is an incorrect assumption. Although the XO 1.75 will be slightly slower than an XO 1.5 in this test as it is primarily doing glyph compositing in the terminal. The XO 1.5 hardware supports compositing the A8 format via the 3d engine, while the XO 1.75 only supports rgb565 and argb in hardware so a lot of the compositing functions will fall back to software. We are helping to speed up this fallback by enabling iwmmxt optimizations in pixman. Tried to take this out of the equation modifying the script as such `#!/bin/bash let count=0 while [ $count -le 100 ] do ((count++)) done' and then run `time script' The XO-1.75 gave: real2m28.625s user2m22.540s sys 0m1.490s and the XO-1.5: real1m45.648s user1m41.430s sys 0m1.760s So XO-1.75 does take ~40% more than the XO-1.5 in this particular CPU test. I really do not know if this has to do with the ARM libs or the CPU itself but the difference appears to be the same as with the previous scrolling version of the test. Considering counts/discharge however, the XO-1.75 appears 33% more efficient than the XO-1.5 and 320%(!) more efficient than the XO-1 One thing I noticed is that while on the XO-1 and XO-1.5 the output was a constant stream of new lines without and hesitations and the cursor barely visible, on the XO-1.75 were hesitations and the cursor was appearing at the end of the line during these hiccups. These hiccups are probably due to the lack of hardware acceleration. However because the SOC does do more rendering I have also been experimenting with increasing the buffer for libxcb to help prevent hiccups between the Xclients and Xserver. OS12 should be a better image to test on the XO 1.75. Tried it with os12 and got identical results and behavior. -Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance
On Sat, May 26, 2012 at 4:59 AM, Yioryos Asprobounitis mavrot...@yahoo.com wrote: The test was done is Sugar and during the entire test the backlight was on and the rolling count output was displayed in the terminal activity. The XOs were associated with the same AP but no network or other activity was running. That's a crazy test. If you want an idea of low-level performance, I can suggest running LMBench. For battery performance, you want normal use under battery. If you want an aggressive, unrealistic, artificial burn as much battery as fast as possible, try running runin scripts. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - 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: XO battery/performance
--- On Mon, 5/28/12, Martin Langhoff martin.langh...@gmail.com wrote: From: Martin Langhoff martin.langh...@gmail.com Subject: Re: XO battery/performance To: Yioryos Asprobounitis mavrot...@yahoo.com Cc: OLPC Devel devel@lists.laptop.org Date: Monday, May 28, 2012, 2:18 PM On Sat, May 26, 2012 at 4:59 AM, Yioryos Asprobounitis mavrot...@yahoo.com wrote: The test was done is Sugar and during the entire test the backlight was on and the rolling count output was displayed in the terminal activity. The XOs were associated with the same AP but no network or other activity was running. That's a crazy test. I do not think I claimed a sophisticated test. Just used what I needed at the time. The fact that is shows that the XO-1.75 is slower but more efficient than the XO-1.5 does not make it crazy nor wrong, if you are able to evaluate it for what it does. Certainly not worthy of aphorisms If you want an idea of low-level performance, I can suggest running LMBench. Thanks for the advice. If you can point to an lmbench rpm or how to compile it without bitkeeper, by now a commercial software, would be even better. For battery performance, you want normal use under battery. The XOs use 100% CPU, if you do anything with them other than looking at the screen. I would think that a test that uses 100% cpu is as close to normal as it gets when we are talking XO use. If you want an aggressive, unrealistic, artificial burn as much battery as fast as possible, try running runin scripts. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - 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: XO battery/performance
On Mon, May 28, 2012 at 4:43 PM, Yioryos Asprobounitis mavrot...@yahoo.com wrote: I do not think I claimed a sophisticated test. Sorry, I didn't mean to hurt here. But it's really not testing what you thought it was testing, as others have pointed out. If you want an idea of low-level performance, I can suggest running LMBench. Thanks for the advice. If you can point to an lmbench rpm or how to compile it without bitkeeper, by now a commercial software, would be even better. True, it seems to want bitkeeper. I remember I read the makefile, and it uses some bk tellmeversion .version thing to get the a revision or version string. Just put a random string in the generated file, and if you want remove that part of the makefile. The XOs use 100% CPU, if you do anything with them other than looking at the screen. The CPU is only one part of a complex system. Cranking out audio consumes power, reading from the camera consumes lots of pwoer, writing to eMMC or SD consumes power. I would think that a test that uses 100% cpu is as close to normal as it gets when we are talking XO use. H. Sorry, I disagree here. You have usage cases, and they are very different from each other. There isn't much normal. - writing a document - making a drawing - using TurtleArt - using one of the TamTams - recording or playing back video - reading content on websites - watching a video online - reading an ebook Some of those are moderate power consumers, some are big power hogs, some are pretty efficient. A special case needs to be consider for reading a page on a website, which can be extremely efficient or a power hog, depending on animations on the page. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - 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: XO battery/performance
G'day, Your test script is a good test for scrolling performance in Terminal, thanks. I don't agree with the implications you have drawn though. I agree that the scrolling hesitations would ruin the test ... because if the bash process is blocked the counter would not increase. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
XO battery/performance
Since I'm trying to figure this strange battery issue ( http://lists.laptop.org/pipermail/devel/2012-May/035198.html ) I also tried to test the XO-1(os880), XO-1.5(os883) and -1.75(os10) battery life and thought to report it. It might be of help to someone. The strange battery was not part of this test of course (though its results are quite comparable with the good batteries). All batteries were fully charged. The XO-1.75 and thus its battery is ~1.5 years newer that the ones in the XO-1, -1.5 The test was done is Sugar and during the entire test the backlight was on and the rolling count output was displayed in the terminal activity. The XOs were associated with the same AP but no network or other activity was running. Battery level was determined from the power-logs (the second column) For the test, the CPUs were running this simple loop script in terminal: `#!/bin/bash let count=0 while : do echo “Count is: $count” ((count++)) done' Starting from fully charged batteries after ~70 minutes of running the XO-1 was at 60% the XO-1.5 at 55% and the XO-1.75 at 80% (It can really go 5 hours :-) The count displayed at the end of the run from the script was 7575933 for the XO-1.75, 12542538 for the XO-1.5 and 4618306 for the XO-1. I can appreciate that this is far from a CPU/computer performance test but taking counts just as an *indication* of CPU/FPU performance would imply that the XO-1.75 is 65% faster than the XO-1 but 40% slower(?) than the XO-1.5. Considering counts/discharge however, the XO-1.75 appears 33% more efficient than the XO-1.5 and 320%(!) more efficient than the XO-1 One thing I noticed is that while on the XO-1 and XO-1.5 the output was a constant stream of new lines without and hesitations and the cursor barely visible, on the XO-1.75 were hesitations and the cursor was appearing at the end of the line during these hiccups. I was wondering if this might be related to X performance rather but still affects the final result on the XO-1.75. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
