Re: XO-1 vs Sugar 0.104 performance, and swap to NAND Flash
On Mon, Apr 13, 2015 at 05:56:22AM +, Yioryos Asprobounitis wrote: James wrote: To check, make sure the laptop is unlocked, and add this to the second line of the boot/olpc.fth file: dev /sd patch 2drop cb! sdhci-card-power-off dend Does this keep the SD slot powered only when is occupied or regardless? Regardless, but only if the slot is powered up for access. Does the OS takes over the SD slot power management after boot? Yes. The firmware driver is not used by the kernel. If not, can OFW detect the presence of an external SDcard early, and keep it powered only then or detect its absence latter in the boot sequence and revert? Not answered. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 vs Sugar 0.104 performance, and swap to NAND Flash
Very nice job James. Thanks to give us these details. Numbers give sometimes more than tons of words ! Lionel. 2015-04-08 18:00 GMT+02:00 devel-requ...@lists.laptop.org: Date: Wed, 8 Apr 2015 13:47:27 +1000 From: James Cameron qu...@laptop.org To: support-g...@lists.laptop.org, devel@lists.laptop.org, sugar-de...@lists.sugarlabs.org Subject: Re: XO-1 vs Sugar 0.104 performance, and swap to NAND Flash Message-ID: 20150408034727.gi9...@us.netrek.org Content-Type: text/plain; charset=us-ascii Browse is one of the most heavily used activities when internet or local content is available. Tests were run over many hours on several XO-1 laptops. The XO-1 is an old design which is slow enough to give useful statistics. The results show a continued improvement to startup time over the recent versions of Sugar, and a very small advantage to using swap memory. -- The first test was to reboot, wait for Sugar to start, then automatically start the Browse activity, and time how long it took to start. Then the results of hundreds of tests were averaged. Browse-140 on 12.1.0 with Sugar 0.94 took 25 seconds. Browse-149.4 on 13.2.1 with Sugar 0.98 took 23 seconds. Browse-157 on 13.2.4 with Sugar 0.104 and no swap took 21 seconds. Browse-157 on 13.2.4 with Sugar 0.104 and NAND swap took 20 seconds. This shows continued improvement to Browse startup time, in the scenario where the libraries have to be loaded into memory. (Reference: test #8, and #9) -- Another test started and stopped the Browse activity 25 times without rebooting. Then the results were averaged. Browse-140 on 12.1.0 with Sugar 0.94 took 14 seconds. Browse-149.4 on 13.2.1 with Sugar 0.98 took 15 seconds. Browse-157 on 13.2.4 with Sugar 0.104 and NAND swap took 13 seconds. This shows some improvement to Browse startup time, in the scenario where the needed libraries are already loaded into memory. (Reference: test #6) -- The same test also started and stopped most of the other activities 25 times without rebooting. Then the results were averaged. For Sugar 0.96 the average startup time was 15 seconds the first time, and 11 seconds each subsequent time. For Sugar 0.98 the average startup time was 17 seconds the first time, and 13 seconds each subsequent time. For Sugar 0.104 the average startup time was 14 seconds the first time, and 11 seconds each subsequent time. Detailed results by activity below. The key for these tables is: cold = startup time for first start after sugar restart. warm = average of startup time for subsequence starts. std = population standard deviation for warm starts. ratio = a ratio comparing warm start to cold start times. tests = number of warm start tests recorded. For Sugar 0.96 the results by activity were: bundle_idcoldwarmstd ratio tests com.garycmartin.Moon 10.595 10.643 0.531 1.005 24 com.jotaro.ImplodeActivity 6.691 6.486 0.045 0.969 24 org.laptop.AbiWordActivity 19.474 14.459 0.804 0.743 24 org.laptop.AcousticMeasure 11.984 7.761 0.045 0.648 24 org.laptop.Calculate 9.809 9.560 0.065 0.975 24 org.laptop.HelpActivity 19.487 11.342 0.688 0.582 24 org.laptop.MeasureActivity 12.478 10.246 0.085 0.821 24 org.laptop.Memorize 16.229 13.243 0.539 0.816 24 org.laptop.Oficina 10.421 9.490 0.431 0.911 24 org.laptop.Pippy 6.421 6.150 0.050 0.958 24 org.laptop.RecordActivity 12.563 11.179 0.346 0.890 24 org.laptop.TamTamMini 16.676 14.414 0.338 0.864 24 org.laptop.WebActivity 23.335 14.260 0.241 0.611 24 tv.alterna.Clock 8.782 8.631 0.067 0.983 24 vu.lux.olpc.Maze 11.699 8.731 0.269 0.746 24 vu.lux.olpc.Speak 15.187 11.460 0.261 0.755 24 For Sugar 0.98 the results by activity were: bundle_idcoldwarmstd ratio tests com.garycmartin.Moon 12.946 11.039 0.372 0.853 24 com.jotaro.ImplodeActivity 11.494 11.352 0.499 0.988 24 org.laptop.AbiWordActivity 26.611 21.501 1.041 0.808 24 org.laptop.AcousticMeasure 14.865 12.949 0.351 0.871 24 org.laptop.Calculate 12.063 10.220 0.207 0.847 24 org.laptop.HelpActivity 18.378 11.101 0.311 0.604 24 org.laptop.MeasureActivity 19.566 13.791 0.308 0.705 24 org.laptop.Memorize 20.977 14.462 0.791 0.689 24 org.laptop.Oficina 14.216 13.948 0.246 0.981 24 org.laptop.Pippy 11.793 10.983 0.141 0.931 24 org.laptop.RecordActivity 18.459 13.165 0.514 0.713 24 org.laptop.sugar.Jukebox 16.346 11.466 0.292 0.701
Re: XO-1 vs Sugar 0.104 performance, and swap to NAND Flash
On Wed, Apr 08, 2015 at 07:35:34PM -0400, Kevin Gordon Gmail wrote: Perhaps silly Q... Any benefit just putting swap and static content on the SD? No question is silly. ;-) I'm guessing you are asking about performance, or response times. If so, the short answer is no. Details below. If you are looking for benefits other than performance, the main benefit is total size. NAND flash is only 1 GB. By adding an 128 GB SD card, the total content stored on the XO-1 can increase dramatically. -- Details #1 It has to do with when data moves, and how much concurrency occurs. A counter question is ... when is it that the XO-1 will both read from NAND flash _and_ from SD card at the same time? Probably never. Data that moves from NAND flash to memory happens during Sugar startup, and the first time an activity is started. It can also happen if a different activity is started. Once an activity is started, usually no further demand occurs. Memory data that moves to swap does so because it isn't being used. In my tests of Sugar 0.104 on Fedora 18, about 12 MB of data moves to swap, and no more. This happens during Sugar startup, and the first activity startup, then it doesn't happen any more until the next reboot. This data generally does not return from swap. So with swap on SD card, it only benefits during Sugar startup and first activity startup, and before content is accessed. Content data, such as videos, web pages, audio, images, and so on, is accessed after the Browse activity has started. So with content on SD card, there should be no significant difference. While the system is capable of much more concurrency (see below), Sugar and the activities just don't make that demand. You could test it by timing how long before content is visible. -- Details #2 Proof the NAND flash and SD card do not block each other. The camera, SD card reader slot, and NAND flash all hang off the CAFE ASIC which presents through a PCI bus to the CPU. Does filling the data channel to one device block the other device in any way? Read test from NAND flash yields about 8 MB/s. When the SD card is doing a read test, a simultaneous read test from NAND flash yields about 5.8 MB/s. The decrease is due to contention for CPU and bus. At the same time, the SD card read test result is mostly unchanged, falling from 6.9 MB/s to 6.6 MB/s. Read from filesystem cache of NAND flash yields about 45 MB/s. When the SD card is doing a read test, a read from filesystem cache of NAND flash yields about 32 MB/s. The decrease is due to contention for CPU and bus. At the same time, the SD card read test result is mostly unchanged, falling from 6.9 MB/s to 6.7 MB/s. This means the bus path to the SD card is mostly idle, and the kernel is waiting for the SD card to respond. So the CAFE ASIC and PCI bus are easily able to handle an aggregate of about 12.4 MB/s, and perhaps much more. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 vs Sugar 0.104 performance, and swap to NAND Flash
Perhaps silly Q... Any benefit just putting swap and static content on the SD? Kg Sent from my currently functioning gadget Original Message From: James Cameron Sent: Wednesday, April 8, 2015 19:31 To: devel@lists.laptop.org; sugar-de...@lists.sugarlabs.org; support-g...@lists.laptop.org Subject: Re: XO-1 vs Sugar 0.104 performance, and swap to NAND Flash What benefit is an SD card on an XO-1? My tests of about 400 starts show some benefit of using an SD card, on activity startup time. The benefits are: - boot time was decreased by several seconds; because of reduced demand for memory, - first activity start after boot was decreased by several seconds; because of reduced demand for memory, - when there is no contention for memory, mean cold activity startup time is decreased by between 1 and 2 seconds; because of both different data rates and no decompression, and; - writing journal entries is slightly faster. There was no benefit on activity startup time where caches were warm; everything needed by the activity was already in memory, so there was no extra wait. The SD card was a SanDisk Ultra 8GB, class 10, 30 MB/s. Sequential read speed on a modern desktop is 18.5 MB/s. But on the XO-1 the speed is 6.3 MB/s. There may be little advantage to using a faster card. For Sugar 0.104 comparing results by activity, between NAND flash and SD card: bundle_id cold warm std ratio tests com.garycmartin.Moon 11.928 10.294 0.492 0.863 24 com.garycmartin.Moon 11.809 10.585 0.516 0.896 24 sd com.jotaro.ImplodeActivity 9.084 9.017 0.498 0.993 24 com.jotaro.ImplodeActivity 9.560 8.904 0.501 0.931 24 sd org.laptop.AbiWordActivity 20.868 16.862 0.376 0.808 24 org.laptop.AbiWordActivity 19.326 16.441 0.277 0.851 24 sd org.laptop.AcousticMeasure 12.330 10.513 0.137 0.853 24 org.laptop.AcousticMeasure 11.854 10.552 0.254 0.890 24 sd org.laptop.Calculate 11.591 9.920 0.120 0.856 24 org.laptop.Calculate 12.152 9.975 0.205 0.821 24 sd org.laptop.HelpActivity 14.654 8.981 0.329 0.613 24 org.laptop.HelpActivity 13.025 9.027 0.345 0.693 24 sd org.laptop.MeasureActivity 16.381 11.364 0.135 0.694 24 org.laptop.MeasureActivity 15.000 11.634 0.344 0.776 24 sd org.laptop.Memorize 17.961 14.550 0.183 0.810 24 org.laptop.Memorize 16.442 14.724 0.240 0.896 24 sd org.laptop.Oficina 12.231 12.029 0.351 0.983 24 org.laptop.Oficina 13.250 12.270 0.585 0.926 24 sd org.laptop.Pippy 8.752 8.202 0.128 0.937 24 org.laptop.Pippy 9.897 8.404 0.467 0.849 24 sd org.laptop.RecordActivity 16.956 12.652 0.145 0.746 24 org.laptop.RecordActivity 15.341 12.501 0.255 0.815 24 sd org.laptop.sugar.Jukebox 9.666 8.986 0.108 0.930 24 org.laptop.sugar.Jukebox 9.821 9.287 0.472 0.946 24 sd org.laptop.sugar.ReadActivity 11.296 10.477 0.165 0.928 24 org.laptop.sugar.ReadActivity 11.080 10.618 0.463 0.958 24 sd org.laptop.TamTamMini 18.628 14.734 0.576 0.791 24 org.laptop.TamTamMini 19.838 14.615 0.288 0.737 24 sd org.laptop.WebActivity 19.425 12.527 0.217 0.645 24 org.laptop.WebActivity 17.935 12.937 0.274 0.721 24 sd tv.alterna.Clock 10.061 7.124 0.123 0.708 24 tv.alterna.Clock 21.226 7.522 0.316 0.354 24 sd ? vu.lux.olpc.Maze 8.366 8.265 0.120 0.988 24 vu.lux.olpc.Maze 8.998 8.646 0.370 0.961 24 sd vu.lux.olpc.Speak 24.555 12.075 0.208 0.492 24 ? vu.lux.olpc.Speak 16.526 11.946 0.358 0.723 24 sd The cold results for Clock and Speak are unexpected, but this may be related to gst-plugin-scan. (Reference: test #6, vs #10) -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 vs Sugar 0.104 performance, and swap to NAND Flash
What benefit is an SD card on an XO-1? My tests of about 400 starts show some benefit of using an SD card, on activity startup time. The benefits are: - boot time was decreased by several seconds; because of reduced demand for memory, - first activity start after boot was decreased by several seconds; because of reduced demand for memory, - when there is no contention for memory, mean cold activity startup time is decreased by between 1 and 2 seconds; because of both different data rates and no decompression, and; - writing journal entries is slightly faster. There was no benefit on activity startup time where caches were warm; everything needed by the activity was already in memory, so there was no extra wait. The SD card was a SanDisk Ultra 8GB, class 10, 30 MB/s. Sequential read speed on a modern desktop is 18.5 MB/s. But on the XO-1 the speed is 6.3 MB/s. There may be little advantage to using a faster card. For Sugar 0.104 comparing results by activity, between NAND flash and SD card: bundle_idcoldwarmstd ratio tests com.garycmartin.Moon 11.928 10.294 0.492 0.863 24 com.garycmartin.Moon 11.809 10.585 0.516 0.896 24 sd com.jotaro.ImplodeActivity 9.084 9.017 0.498 0.993 24 com.jotaro.ImplodeActivity 9.560 8.904 0.501 0.931 24 sd org.laptop.AbiWordActivity 20.868 16.862 0.376 0.808 24 org.laptop.AbiWordActivity 19.326 16.441 0.277 0.851 24 sd org.laptop.AcousticMeasure 12.330 10.513 0.137 0.853 24 org.laptop.AcousticMeasure 11.854 10.552 0.254 0.890 24 sd org.laptop.Calculate 11.591 9.920 0.120 0.856 24 org.laptop.Calculate 12.152 9.975 0.205 0.821 24 sd org.laptop.HelpActivity 14.654 8.981 0.329 0.613 24 org.laptop.HelpActivity 13.025 9.027 0.345 0.693 24 sd org.laptop.MeasureActivity 16.381 11.364 0.135 0.694 24 org.laptop.MeasureActivity 15.000 11.634 0.344 0.776 24 sd org.laptop.Memorize 17.961 14.550 0.183 0.810 24 org.laptop.Memorize 16.442 14.724 0.240 0.896 24 sd org.laptop.Oficina 12.231 12.029 0.351 0.983 24 org.laptop.Oficina 13.250 12.270 0.585 0.926 24 sd org.laptop.Pippy 8.752 8.202 0.128 0.937 24 org.laptop.Pippy 9.897 8.404 0.467 0.849 24 sd org.laptop.RecordActivity 16.956 12.652 0.145 0.746 24 org.laptop.RecordActivity 15.341 12.501 0.255 0.815 24 sd org.laptop.sugar.Jukebox 9.666 8.986 0.108 0.930 24 org.laptop.sugar.Jukebox 9.821 9.287 0.472 0.946 24 sd org.laptop.sugar.ReadActivity 11.296 10.477 0.165 0.928 24 org.laptop.sugar.ReadActivity 11.080 10.618 0.463 0.958 24 sd org.laptop.TamTamMini 18.628 14.734 0.576 0.791 24 org.laptop.TamTamMini 19.838 14.615 0.288 0.737 24 sd org.laptop.WebActivity 19.425 12.527 0.217 0.645 24 org.laptop.WebActivity 17.935 12.937 0.274 0.721 24 sd tv.alterna.Clock 10.061 7.124 0.123 0.708 24 tv.alterna.Clock 21.226 7.522 0.316 0.354 24 sd ? vu.lux.olpc.Maze 8.366 8.265 0.120 0.988 24 vu.lux.olpc.Maze 8.998 8.646 0.370 0.961 24 sd vu.lux.olpc.Speak 24.555 12.075 0.208 0.492 24 ? vu.lux.olpc.Speak 16.526 11.946 0.358 0.723 24 sd The cold results for Clock and Speak are unexpected, but this may be related to gst-plugin-scan. (Reference: test #6, vs #10) -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: xo-1
Some of the beta units (B1s) are not multicolored. -walter On Sat, Nov 8, 2014 at 1:38 PM, Jhon Diaz linuxs...@gmail.com wrote: are all xo-1 multi colored on the back ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 wireless tests
On Sat, Feb 15, 2014 at 05:57:56PM +0100, Jon Nettleton wrote: Tim wrote: So I think the answer is yes to 1) and yes to 2), especially if you are unlucky enough to have your target AP and the active mesh on the same channel. Does the mesh get disabled or moved when you connect to an AP on a different channel? I studied this last week with monitor mode, tcpdump and wireshark. When the wireless adapter has been commanded to associate with an access point on a specific channel, mesh beacons and mesh probe responses are seen from that adapter on that channel. This can be verified by scanning. So in my opinion, you are always going to have your target AP and the active mesh on the same channel. The variability of Tim's results are probably determined by the environment the test is being done in. Take the test back to Haiti where it failed. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 wireless scan test Tim-2
Tim followed up privately with some more results, testing with the new wireless driver gave this: Linux: 699 scans, 694 pass, 5 fail, 1% failure to see SSID. Open Firmware: 1019 scans, 1019 pass, 0 fail, 0% failure to see SSID. Which was a drop from 59% failure to 1% failure, and is consistent with the earlier Open Firmware test at 4% failure. So the effect of the new wireless driver was to decrease the scan failure significantly, as monitored by one XO-1 in a group of 12 XO-1s. This result mirrors the results that Terry and I have achieved, so it looks like it is solved. New kernels are available with the new wireless driver, for all XO laptops, but only for the Fedora 18 builds of OLPC OS. Deployment builds with an automatic updater, such as the Dextrose updater, may upgrade their kernel some time in the next week. http://wiki.laptop.org/go/12757 describes how to upgrade. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 wireless scan test Tim-1
iwlist on 11.3 does not return Extra:Last Beacon. I tried yum upgrade, but there was no later package. So I upgraded the monitor xo only to 12.1 and am re-running. Tim -Original Message- From: James Cameron Sent: Monday, February 10, 2014 6:53 PM To: Tim Moody Cc: devel@lists.laptop.org ; server-de...@lists.laptop.org ; xsce-de...@googlegroups.com ; support-g...@lists.laptop.org ; unleashk...@googlegroups.com Subject: Re: XO-1 wireless scan test Tim-1 Thanks. The Open Firmware test results look valid and I shall process them. The Linux test results don't seem to be working. Each line contains timestamp only, and no last beacon time. I wonder if the script won't work properly on 11.3. I haven't tested it there. Can you check that script for me, especially whether the iwlist command is working and if it includes a last beacon time in the output. If 11.3 hasn't got what it takes, try again with 12.1.0 or 13.2.0, thanks. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 wireless scan test Tim-2
Very good data, thanks. Your test results are: Open Firmware: 1334 scans, 1328 pass, 6 fail, 4% failure to see SSID. Linux: 346 scans, 142 pass, 204 fail, 59% failure to see SSID. This result confirms the problem is happening; the wireless card works fine, but Linux does not. Next, please do not change the test configuration at all, but upgrade the monitor to 13.2.0, and I will send you a kernel module file that will fix the problem, and you can then retest. Will send in separate private mail. You may also upgrade the rest of the XO-1s to 13.2.0 for this next test, and apply the kernel module there as well. On Tue, Feb 11, 2014 at 01:41:02PM -0500, Tim Moody wrote: TPLink WDR4300 SSID: WDR4300 Channel: 9 MAC: 10:FE:ED:9B:66:2F Firmware: SECN v 2 RC3d router's dhcp server is on router's mesh is off 2.4Hz only and set to G only no internet access 11 XO-1s with 12th a logger XO OS: Kevin Gordon custom based on 11.3, fc14 with Q2F19 ROM Monitor XO OS 12.1 Powered off previous AP, powered on WDR4300, and tried switching all XO-1s without powering off and on individually: 1 - 4 new AP visible in NN and connected with no problem 5 - took more time to appear 6 -7 new AP visible and connected with no problem 8 - 11 never became visible 8 - discarded network history without effect 8 - powered off and on and new AP visible and easily connected 9 - powered off and on and new AP visible and easily connected 10 -11 done together with success All XO-1s powered off and powered on sequentially All connected to the AP OFW test run Linux test run 1392139305 220 1392139310 5250 1392139315 10250 1392139350 220 1392139355 5210 1392139360 10210 1392139375 170 1392139380 5050 1392139385 10060 1392139420 2147489028 1392139425 2147493998 1392139450 220 1392139455 230 1392139460 5220 1392139465 10210 1392139505 220 1392139510 230 1392139515 5220 1392139520 10200 1392139565 220 1392139570 5220 1392139575 10220 1392139590 230 1392139595 230 1392139600 220 1392139605 210 1392139610 5200 1392139615 10220 1392139635 220 1392139640 5330 1392139645 10300 1392139650 220 1392139655 5220 1392139660 10210 1392139675 220 1392139680 220 1392139685 5230 1392139690 10210 1392139700 230 1392139705 5320 1392139710 10180 1392139725 220 1392139735 10150 1392139760 230 1392139765 5210 1392139770 10200 1392139775 220 1392139780 5220 1392139785 10230 1392139840 220 1392139845 5220 1392139850 10200 1392139865 230 1392139870 5230 1392139875 10250 1392139920 230 1392139925 5200 1392139930 10190 1392139960 220 1392139965 220 1392139970 5220 1392139975 230 1392139980 5240 1392139985 10210 1392140010 220 1392140015 5230 1392140020 10210 1392140090 230 1392140095 5230 1392140100 220 1392140105 5210 1392140110 10290 1392140115 220 1392140120 230 1392140125 5230 1392140130 10210 1392140150 220 1392140155 5230 1392140160 10230 1392140180 220 1392140185 5230 1392140190 220 1392140195 230 1392140200 220 1392140205 220 1392140210 5220 1392140215 10220 1392140230 220 1392140235 5240 1392140240 10230 1392140330 220 1392140335 5230 1392140340 220 1392140345 210 1392140350 5220 1392140355 10210 1392140365 230 1392140370 5220 1392140375 10330 1392140475 220 1392140480 5230 1392140485 10250 1392140495 230 1392140500 5210 1392140505 10300 1392140515 190 1392140520 5070 1392140525 10060 1392140530 230 1392140535 5230 1392140540 10230 1392140560 220 1392140565 5110 1392140570 230 1392140575 5210 1392140580 220 1392140585 5220 1392140590 10210 1392140645 220 1392140650 5220 1392140655 10210 1392140690 230 1392140695 5150 1392140700 10160 1392140715 220 1392140720 5220 1392140725 10230 1392140760 220 1392140765 230 1392140770 220 1392140775 5240 1392140780 10250 1392140785 220 1392140790 5200 1392140795 10190 1392140815 230 1392140820 220 1392140825 220 1392140830 5210 1392140835 10190 1392140840 220 1392140845 230 1392140850 5290 1392140855 10280 1392140865 220 1392140870 5210 1392140875 10190 1392140890 230 1392140895 5230 1392140900 10230 1392140915 220 1392140920 5230 1392140925 230 1392140930 5230 1392140935 220 1392140940 230 1392140945 220 1392140950 5220 1392140955 10300 1392140980 220 1392140985 220 1392140995 10240 1392141050 220 1392141055 5220 1392141060 10220 1392141080 210 1392141085 5210 1392141090 10200 1392141140 220 1392141145 5240 1392141150 10220 1392141180 230 1392141185 5230 1392141190 210 1392141195 5210 1392141200 10200 1392141215 220 1392141220 220 1392141225 5250 1392141230 10240 1392141235 220 1392141240 5220 1392141245 10220 1392141265 230 1392141270 5220 1392141275 10200 1392141310 220 1392141315 5210 1392141320 230 1392141325 5210 1392141330 10210 1392141340 220 1392141345 5330 1392141350 10300 1392141365 230 1392141370 5240 1392141375 10220 1392141385 210 1392141390 5220 1392141395 10220 1392141455
Re: XO-1 wireless scan test Tim-1
Thanks. The Open Firmware test results look valid and I shall process them. The Linux test results don't seem to be working. Each line contains timestamp only, and no last beacon time. I wonder if the script won't work properly on 11.3. I haven't tested it there. Can you check that script for me, especially whether the iwlist command is working and if it includes a last beacon time in the output. If 11.3 hasn't got what it takes, try again with 12.1.0 or 13.2.0, thanks. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 wireless scan test Tim-1
I've verified your Open Firmware test log. Number of scans: 1201 Number of scans that included the SSID: 1172 Proportion of scans that did not include the SSID: 2.4% Please run the Linux half of the test again once you have fixed the cause of the missing last beacon time. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 classrooms don't reliably connect to many/most Wifi AP's
On Tue, Feb 11, 2014 at 07:24:33AM +0100, Jon Nettleton wrote: On Tue, Feb 11, 2014 at 7:08 AM, James Cameron qu...@laptop.org wrote: On Mon, Feb 10, 2014 at 11:31:39AM +1100, James Cameron wrote: On Sun, Feb 09, 2014 at 07:18:49PM -0500, Kevin Gordon Gmail wrote: Tp link set as 3g router mode, with usb Sierra wireless usb modem, set to channel 11, 80211g only, wpa2 pal security. Running stock f/w. Terry found that channel 1 was the most afflicted. I suspect, but I haven't checked, that the idle mesh only uses channel 1, but it also use whatever channel the laptop is associated with. Tim's results from Open Firmware show that the idle mesh switches to whatever channel is being used for association with an access point. This has to be the case because there is only one radio, so both 802.11s and 802.11b/g have to be configured for the same channel. And being off-channel would be too costly. So while we would normally see an operating mesh on 1, 6 and 11, it can be seen on other channels as well. The underlying fault was somewhat channel specific ... because the scans are done in sets; (1,2,3,4), (5,6,7,8), (9,10,11,12). If a mesh was heard on channel 1 then the scan results for channels 2, 3 and 4 will have been lost. If a mesh was heard on channel 9, then the scan results for channels 10, 11 and 12 will have been lost. I think really what we need to do is have a better workflow for detecting connectivity, not much different from how we are handling ad-hoc on the later model XO's I think on initial boot, or waking from suspend and the previous wifi state was not connected, we need to disable the mesh interface and scan for infrastructure AP's. Then if this fails we can either scan for ad-hoc or bring up the mesh interface and look for a mesh network to connect to. I think besides driver bugs we have a general problem of trying to do too much at the same time with a single radio. any takers on this workflow for network discovery? Sounds interesting, but can't commit myself. But it may be something that Sugar Labs might be interested in. It does look like it would be possible to scan for APs, ad-hoc, and mesh at the same time, without having to bring up the mesh interface first. All within about 440ms. Those mesh probe responses are useful after all. ;-) -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
Is in shell.log file OK thanks. Unfortunately this entry is not created when activities are launched by sugar-launch. Any line of code that could mend this? Gonzalo On Fri, Jul 5, 2013 at 1:07 PM, Yioryos Asprobounitis mavrot...@yahoo.com wrote: Metodology: * Changed SUGAR_LOGGER_DEVEL * The activities were started from the listview, then are new instances * The start up time is the time reported by sugar in the log. Looked throughout $HOME/.sugar/default and could not find the launched in time reported anywere Could you please specify which log(s) Thx ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
Metodology: * Changed SUGAR_LOGGER_DEVEL * The activities were started from the listview, then are new instances * The start up time is the time reported by sugar in the log. Looked throughout $HOME/.sugar/default and could not find the launched in time reported anywere Could you please specify which log(s) Thx ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
Is in shell.log file Gonzalo On Fri, Jul 5, 2013 at 1:07 PM, Yioryos Asprobounitis mavrot...@yahoo.comwrote: Metodology: * Changed SUGAR_LOGGER_DEVEL * The activities were started from the listview, then are new instances * The start up time is the time reported by sugar in the log. Looked throughout $HOME/.sugar/default and could not find the launched in time reported anywere Could you please specify which log(s) Thx ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
- Original Message - From: James Cameron qu...@laptop.org To: Yioryos Asprobounitis mavrot...@yahoo.com Cc: OLPC Devel devel@lists.laptop.org Sent: Thursday, July 4, 2013 8:44 AM Subject: Re: XO-1(.75) On Wed, Jul 03, 2013 at 10:02:15PM -0700, Yioryos Asprobounitis wrote: - Original Message - From: James Cameron qu...@laptop.org To: Yioryos Asprobounitis mavrot...@yahoo.com Cc: OLPC Devel devel@lists.laptop.org Sent: Thursday, July 4, 2013 2:10 AM Subject: Re: XO-1(.75) On Wed, Jul 03, 2013 at 02:21:08PM -0700, Yioryos Asprobounitis wrote: I'm using the XO-1.75 a bit more these days and gives me a sense of XO-1 performance wise. So I compared my (500/200 overclocked) XO-1 running F14/os885/Sugar-0.94 to XO-1.75 running F-18/13.2.0-11/Sugar-0.98. Since some general performance work was done between those software versions, the comparison is uninteresting. Compare 13.2.0-11 across XO-1 and XO-1.75, or compare XO-1 across os885 and 13.2.0-11, depending on what you are looking to prove. This comparison has been done a couple of months ago and is clear that F18/S0.98 taxes the systems considerably. Yes, it does seem that way. I tried 13.2.0-n on XO-1 recently and felt it was quite slow, but I couldn't be sure it wasn't because my XO-1.75 and XO-4 experience influenced me. What I found interesting in this unmatched comparison was the inconsistency. I don't see any inconsistency though, because the comparison was unmatched to begin with. Variables you changed included overclocking, the CPU, the memory, the internal storage, the touchpad, the kernel, the base operating system, the frame buffer, the X server, the OLPC utilities, and Sugar. All I can draw from the results is that you changed a lot of things and a lot of things were different. But this is exactly the point! When a _lot_ of things are changing and you have two groups of activities one going one way and the other the opposite, you look for the least common denominator that will hopefully point to the problem (this is is a very common approach in multi-variable problems). They might point to specific stacks in the architecture and/or core OS that may need attention (I originally thought was that activities with an extended non-python component or proportionally less gtk3, fair better on the XO-1.75 - but what do I know ;). Anyway, if the knowledgeable believe there is nothing to it or anything to be done about it,' there goes the comparison. We wait for someone who seems interested in fixing performance problems on the old hardware. It requires quite a depth of knowledge and a lot of time. It isn't something that we can justify a huge investment in. I would think that the performance of newer hardware may be the one that needs attention but certainly can not prioritize it (unless if XO-1.75 classifies under older by now). Best ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
On Thu, Jul 4, 2013 at 8:19 AM, James Cameron qu...@laptop.org wrote: On Wed, Jul 03, 2013 at 11:03:17PM -0700, Yioryos Asprobounitis wrote: - Original Message - From: James Cameron qu...@laptop.org To: Yioryos Asprobounitis mavrot...@yahoo.com Cc: OLPC Devel devel@lists.laptop.org Sent: Thursday, July 4, 2013 8:44 AM Subject: Re: XO-1(.75) On Wed, Jul 03, 2013 at 10:02:15PM -0700, Yioryos Asprobounitis wrote: - Original Message - From: James Cameron qu...@laptop.org To: Yioryos Asprobounitis mavrot...@yahoo.com Cc: OLPC Devel devel@lists.laptop.org Sent: Thursday, July 4, 2013 2:10 AM Subject: Re: XO-1(.75) On Wed, Jul 03, 2013 at 02:21:08PM -0700, Yioryos Asprobounitis wrote: I'm using the XO-1.75 a bit more these days and gives me a sense of XO-1 performance wise. So I compared my (500/200 overclocked) XO-1 running F14/os885/Sugar-0.94 to XO-1.75 running F-18/13.2.0-11/Sugar-0.98. Since some general performance work was done between those software versions, the comparison is uninteresting. Compare 13.2.0-11 across XO-1 and XO-1.75, or compare XO-1 across os885 and 13.2.0-11, depending on what you are looking to prove. This comparison has been done a couple of months ago and is clear that F18/S0.98 taxes the systems considerably. Yes, it does seem that way. I tried 13.2.0-n on XO-1 recently and felt it was quite slow, but I couldn't be sure it wasn't because my XO-1.75 and XO-4 experience influenced me. What I found interesting in this unmatched comparison was the inconsistency. I don't see any inconsistency though, because the comparison was unmatched to begin with. Variables you changed included overclocking, the CPU, the memory, the internal storage, the touchpad, the kernel, the base operating system, the frame buffer, the X server, the OLPC utilities, and Sugar. All I can draw from the results is that you changed a lot of things and a lot of things were different. But this is exactly the point! When a _lot_ of things are changing and you have two groups of activities one going one way and the other the opposite, you look for the least common denominator that will hopefully point to the problem (this is is a very common approach in multi-variable problems). Oh good, now I understand. They might point to specific stacks in the architecture and/or core OS that may need attention (I originally thought was that activities with an extended non-python component or proportionally less gtk3, fair better on the XO-1.75 - but what do I know ;). Anyway, if the knowledgeable believe there is nothing to it or anything to be done about it,' there goes the comparison. We wait for someone who seems interested in fixing performance problems on the old hardware. It requires quite a depth of knowledge and a lot of time. It isn't something that we can justify a huge investment in. I would think that the performance of newer hardware may be the one that needs attention but certainly can not prioritize it (unless if XO-1.75 classifies under older by now). XO-1.75 and XO-4 are current, but XO-1.5 and XO-1 are old. We are certainly interested in any ways to make clear performance improvements on XO-1.75 and XO-4. There is performance work that has been done for the XO-1.75 that is still in the queue to be implemented in the OLPC builds. It is on my list for the summer to get this work cleaned up and published in a repo for developer and end user consumption. The performance gains are due to work done by Matt Turner implementing iWMMXt acceleration in pixman, as well as other libraries that when compiled with this support get some performance boosts. Mostly graphics and multimedia apps will benefit from this tuning. On top of that both the XO-1.75 and XO-4 will get graphics performance boosts when I finish up my graphics driver that allows cached pixmaps to be used. We have to do some graphics rendering and manipulations with the CPU instead of the 2D core and we hit a performance bottleneck with the way pixmaps are allocated for use by the graphics engine. -Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
This comparison has been done a couple of months ago and is clear that F18/S0.98 taxes the systems considerably. What I found interesting in this unmatched comparison was the inconsistency. They might point to specific stacks in the architecture and/or core OS that may need attention (I originally thought was that activities with an extended non-python component or proportionally less gtk3, fair better on the XO-1.75 - but what do I know ;). Anyway, if the knowledgeable believe there is nothing to it or anything to be done about it,' there goes the comparison. No inconsistency here. Most of the activities you see slower were ported to Gtk3. Tam-tam suit, speak, calculate, turtle art, maze, moon, record were not ported scratch and etoys are not related with Gtk Browse received a lot of care this months. Sadly, while the port to Gtk3 and dynamic bindings promised faster start up time (in theory) that was never true. Dsd found performance problems and pushed changes upstream. and 13.2.0 is better than 13.1.0, but anyway more work is needed. Maybe some work can be done in the activities to improve it. Do you have numbers to share? Gonzalo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
On Thu, Jul 4, 2013 at 2:53 AM, Gonzalo Odiard gonz...@laptop.org wrote: No inconsistency here. Most of the activities you see slower were ported to Gtk3. Tam-tam suit, speak, calculate, turtle art, maze, moon, record were not ported scratch and etoys are not related with Gtk Browse received a lot of care this months. Sadly, while the port to Gtk3 and dynamic bindings promised faster start up time (in theory) that was never true. Dsd found performance problems and pushed changes upstream. and 13.2.0 is better than 13.1.0, but anyway more work is needed. Maybe some work can be done in the activities to improve it. Do you have numbers to share? Yes, this is the interesting point in this thread. If you take an old release, on any platforms where we have old releases available, and do a side-by-side comparison with the latest release, we may well have a performance regression. However the possible performance regression is not documented in technical terms. People have mentioned a slowdown in previous threads, but nobody posted any numbers. Last time, a video was posted, but that link is no longer working and I'm not sure if it had numbers in it. Last time it was discussed I did generate numbers myself and then solved the problem. However that discussion was focused around Sugar startup time. This discussion now turns to activity startup time. So, having someone generate activity startup time numbers in a fair test (i.e. same platform, different software versions) would be of value. If there is a performance regression here, we don't have a technical diagnosis that I know of. It seems like some people suspect GTK3/gobject-introspection as the cause, and those may be likely candidates, but I don't think we have real diagnosis supporting that (yet), nor any explanation for why those new technologies might be slower than the old ones. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
So, having someone generate activity startup time numbers in a fair
test (i.e. same platform, different software versions) would be of
value.
Tried the following little script but I can not find a way to get the output of
'time' command to the output.txt file.
Any suggestions?
#!/bin/bash
rm -f output.txt
for x in $(cat Activities/*/activity/activity.info | grep bundle | cut -f 2 -d
'=')
do
echo $x output.txt
echo output.txt
time sugar-launch $x 2 output.txt # 'time -o' does not work neither with
at the end
sleep 30
ME=$(ps aux | grep $x | grep -v grep | awk '{print $2}')
kill -9 $ME 2 output.txt
done
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
On Thu, Jul 4, 2013 at 12:48 PM, Yioryos Asprobounitis mavrot...@yahoo.com wrote: Tried the following little script but I can not find a way to get the output of 'time' command to the output.txt file. Not really sure what you are trying to do here - sugar-launch will not return until the activity exits. I ran a couple of experiments here, with XO-1s running 12.1.0 and 13.2.0. Clock (which is a GTK2 activity on both versions) does start 0.5 - 1 second slower on 13.2.0. On 12.1.0 it starts in 10.5 seconds. That is approx 5% change. Running under perf, the most noticable difference is that X uses 5% of CPU time on 12.1.0, and 10% on 13.2.0. A 5% change. Unfortunately perf doesn't tell me which part of X is eating CPU, apart from the fact that it is not in the kernel. Need to figure out why perf can't be more specific. The risk to this work is that we might fix the 5% X issue and see no noticable difference. But I will try to continue a bit of investigation here next week. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
On Thu, Jul 4, 2013 at 2:00 PM, Yioryos Asprobounitis mavrot...@yahoo.com wrote: The following script appears to work as expected, but is the result valid? That's hard to judge without having an explanation for what you are trying to measure. I can't immediately see your intentions from reading the script. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
On Thu, 2013-07-04 at 13:57 -0600, Daniel Drake wrote: On Thu, Jul 4, 2013 at 12:48 PM, Yioryos Asprobounitis mavrot...@yahoo.com wrote: Tried the following little script but I can not find a way to get the output of 'time' command to the output.txt file. Not really sure what you are trying to do here - sugar-launch will not return until the activity exits. I ran a couple of experiments here, with XO-1s running 12.1.0 and 13.2.0. Clock (which is a GTK2 activity on both versions) does start 0.5 - 1 second slower on 13.2.0. On 12.1.0 it starts in 10.5 seconds. That is approx 5% change. Running under perf, the most noticable difference is that X uses 5% of CPU time on 12.1.0, and 10% on 13.2.0. A 5% change. Of the total available, would that not be a 100% increase in CPU time used by the process running X? Unfortunately perf doesn't tell me which part of X is eating CPU, apart from the fact that it is not in the kernel. Need to figure out why perf can't be more specific. The risk to this work is that we might fix the 5% X issue and see no noticable difference. But I will try to continue a bit of investigation here next week. Jerry Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
While more manual, you can get the activity startup time
uncommenting the line
export SUGAR_LOGGER_LEVEL=debug
in the file .sugar/debug
Gonzalo
On Thu, Jul 4, 2013 at 3:48 PM, Yioryos Asprobounitis
mavrot...@yahoo.comwrote:
So, having someone generate activity startup time numbers in a fair
test (i.e. same platform, different software versions) would be of
value.
Tried the following little script but I can not find a way to get the
output of 'time' command to the output.txt file.
Any suggestions?
#!/bin/bash
rm -f output.txt
for x in $(cat Activities/*/activity/activity.info | grep bundle | cut -f
2 -d '=')
do
echo $x output.txt
echo output.txt
time sugar-launch $x 2 output.txt # 'time -o' does not work neither
with at the end
sleep 30
ME=$(ps aux | grep $x | grep -v grep | awk '{print $2}')
kill -9 $ME 2 output.txt
done
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
The following script appears to work as expected, but is the result valid? That's hard to judge without having an explanation for what you are trying to measure. I can't immediately see your intentions from reading the script. Daniel My intention is to get a list of the user and system time that takes to launch the activities. The attachments show the results on XO-1 running os885 and 13.2.0-4 (no overclocking or other mods). It stops at Terminal (ooops) but you get the idea.org.sugarlabs.AbacusActivity org.laptop.WebActivity ./test: line 3: 943 Killed sugar-launch $x 2 /dev/null real0m30.344s user0m20.100s sys 0m0.830s org.laptop.Calculate ./test: line 3: 1011 Killed sugar-launch $x 2 /dev/null real0m30.170s user0m14.610s sys 0m7.830s org.sugarlabs.SimpleGraph ./test: line 3: 1092 Killed sugar-launch $x 2 /dev/null real0m30.175s user0m8.630s sys 0m2.420s org.laptop.Chat ./test: line 3: 1161 Killed sugar-launch $x 2 /dev/null real0m30.166s user0m11.510s sys 0m0.670s tv.alterna.Clock ./test: line 3: 1234 Killed sugar-launch $x 2 /dev/null real0m30.185s user0m7.810s sys 0m0.680s org.laptop.AcousticMeasure ./test: line 3: 1308 Killed sugar-launch $x 2 /dev/null real0m30.414s user0m9.670s sys 0m8.260s org.vpri.EtoysActivity ./test: line 3: 1374 Killed sugar-launch $x 2 /dev/null real0m30.237s user0m10.450s sys 0m2.710s org.eq.FotoToon ./test: line 3: 1403 Killed sugar-launch $x 2 /dev/null real0m30.250s user0m16.510s sys 0m6.600s org.sugarlabs.HelloWorld ./test: line 3: 1467 Killed sugar-launch $x 2 /dev/null real0m30.170s user0m10.780s sys 0m1.080s org.laptop.HelpActivity ./test: line 3: 1524 Killed sugar-launch $x 2 /dev/null real0m30.176s user0m7.800s sys 0m0.460s org.laptop.ImageViewerActivity ./test: line 3: 1599 Killed sugar-launch $x 2 /dev/null real0m30.208s user0m9.750s sys 0m4.490s com.jotaro.ImplodeActivity ./test: line 3: 1689 Killed sugar-launch $x 2 /dev/null real0m30.236s user0m9.070s sys 0m0.680s org.sugarlabs.JournalShare ./test: line 3: 1769 Killed sugar-launch $x 2 /dev/null real0m30.246s user0m9.600s sys 0m0.550s org.laptop.sugar.Jukebox ./test: line 3: 1842 Killed sugar-launch $x 2 /dev/null real0m30.266s user0m9.850s sys 0m1.690s org.laptop.Log ./test: line 3: 1913 Killed sugar-launch $x 2 /dev/null real0m30.176s user0m9.820s sys 0m0.890s vu.lux.olpc.Maze ./test: line 3: 1973 Killed sugar-launch $x 2 /dev/null real0m30.177s user0m9.950s sys 0m0.560s org.laptop.MeasureActivity ./test: line 3: 2046 Killed sugar-launch $x 2 /dev/null real0m30.290s user0m13.100s sys 0m3.730s org.laptop.Memorize ./test: line 3: 2114 Killed sugar-launch $x 2 /dev/null real0m30.528s user0m14.830s sys 0m2.400s com.garycmartin.Moon ./test: line 3: 2216 Killed sugar-launch $x 2 /dev/null real0m30.200s user0m11.080s sys 0m2.410s org.sugarlabs.MusicKeyboard ./test: line 3: 2297 Killed sugar-launch $x 2 /dev/null real0m30.175s user0m8.230s sys 0m0.890s org.laptop.Oficina ./test: line 3: 2369 Killed sugar-launch $x 2 /dev/null real0m30.210s user0m11.290s sys 0m2.040s org.laptop.Pippy ./test: line 3: 2437 Killed sugar-launch $x 2 /dev/null real0m30.191s user0m13.980s sys 0m1.210s org.sugarlabs.PortfolioActivity ./test: line 3: 2519 Killed sugar-launch $x 2 /dev/null real0m30.260s user0m11.710s sys 0m1.340s org.laptop.sugar.ReadActivity ./test: line 3: 2594 Killed sugar-launch $x 2 /dev/null real0m30.204s user0m11.390s sys 0m0.770s org.laptop.RecordActivity ./test: line 3: 2665 Killed sugar-launch $x 2 /dev/null real0m30.190s user0m11.340s sys 0m0.750s com.laptop.Ruler ./test: line 3: 2756 Killed sugar-launch $x 2 /dev/null real0m30.296s user0m9.830s sys 0m2.480s edu.mit.media.ScratchActivity ./test: line 3: 2835 Killed sugar-launch $x 2 /dev/null real0m30.176s user0m9.200s sys 0m0.550s vu.lux.olpc.Speak ./test: line 3: 2910 Killed sugar-launch $x 2 /dev/null real0m30.423s user0m9.270s sys 0m2.110s org.laptop.TamTamEdit ./test: line 3: 2990 Killed sugar-launch $x 2 /dev/null real0m30.218s user0m10.180s sys 0m1.760s org.laptop.TamTamJam ./test: line 3: 3076 Killed
Re: XO-1(.75)
I did another comparison, between 13.2.0 os11 and os883 (sugar 0.94) You can see the results here: https://docs.google.com/spreadsheet/ccc?key=0As_jQJX0Me6XdDI2clFpX1FFRHhKMHVFZGkyakdST2cusp=sharing Metodology: * Changed SUGAR_LOGGER_DEVEL * The activities were started from the listview, then are new instances * The start up time is the time reported by sugar in the log. The column start up difference, if negative, the time was improved. I added a column to show what activities were ported from Gtk2 to Gtk3. In the case of Read activity, the mechanism is confused, because the old activity opened the ObjectChooser in a new instance. I don't know what happen with Scratch. Some activities had a lot of changes, but other like Distance or Implode not, and looks like the change to Gtk3 add a penalty. Gonzalo On Thu, Jul 4, 2013 at 5:38 PM, Yioryos Asprobounitis mavrot...@yahoo.comwrote: The following script appears to work as expected, but is the result valid? That's hard to judge without having an explanation for what you are trying to measure. I can't immediately see your intentions from reading the script. Daniel My intention is to get a list of the user and system time that takes to launch the activities. The attachments show the results on XO-1 running os885 and 13.2.0-4 (no overclocking or other mods). It stops at Terminal (ooops) but you get the idea. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
On Thu, Jul 4, 2013 at 2:13 PM, Jerry Vonau jvo...@shaw.ca wrote: Of the total available, would that not be a 100% increase in CPU time used by the process running X? What do you mean by the process running X? The parent process of the X process? Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
On Thu, Jul 04, 2013 at 01:00:09PM -0700, Yioryos Asprobounitis wrote:
So, having someone generate activity startup time numbers in a fair
test (i.e. same platform, different software versions) would be of
value.
OK.
The following script appears to work as expected, but is the result valid?
ie does the call through sugar-lunch as well as grep, awk, kill etc add to
the time result?
#!/bin/bash
rm -f output.txt
for x in $(cat Activities/*/activity/activity.info | grep bundle | cut -f 2
-d '=')
do
echo $x output.txt
{ time sugar-launch $x 2/dev/null
sleep 30
ME=$(ps aux | grep $x | grep -v grep | awk '{print $2}')
kill -9 $ME ; } 2 output.txt
echo output.txt
done
Interesting, thanks. An explanation was asked for, so here's one:
This script uses CPU time accounting to measure the time the process
and children spend scheduled on the CPU.
Now on to comment:
This measurement would be fine for minimising the startup CPU time of
the activity, but we know that the CPU time of the X server is as
critical to the situation for many activities.
Measuring only the CPU time doesn't take into account the
wait times due to I/O, such as read and write from internal storage,
audio device opening (which has a depop delay on some platforms), and
possible network delays.
A better measurement to look for is the elapsed time of activity
startup.
This is a most interesting value, but it is difficult to obtain
without changing the activity source so that the point of startup
completion is identified. (That task is made more difficult since
some activities schedule some of their startup _after_ their main
startup.)
--
James Cameron
http://quozl.linux.org.au/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
On Thu, Jul 04, 2013 at 07:16:11PM -0300, Gonzalo Odiard wrote: I did another comparison, between 13.2.0 os11 and os883 (sugar 0.94) You can see the results here: https://docs.google.com/spreadsheet/ccc?key= 0As_jQJX0Me6XdDI2clFpX1FFRHhKMHVFZGkyakdST2cusp=sharing Good data, thanks. Metodology: * Changed SUGAR_LOGGER_DEVEL * The activities were started from the listview, then are new instances * The start up time is the time reported by sugar in the log. A few questions to help with interpreting this data: - was this on an XO-1 or XO-1.5? I ask because it would help with comparing against other models. - what memory size? I ask because if memory is scarce, startup time will be increased. - if it is an XO-1.5, what microSD device? I ask because the access time and transfer rate of the card can have a dramatic effect on I/O bound startups, - did you start these activities twice and measure the second startup in order to exclude caching effects, or did you only measure the first startup? - was the system rebooted between each test, or were caches already populated? - if it is an XO-1.5, does the test /switches heat spreader test pass? I ask because if it fails, the CPU may slow momentarily during an activity startup, causing a non-linearity in the test results; longer startups become longer. The column start up difference, if negative, the time was improved. I added a column to show what activities were ported from Gtk2 to Gtk3. In the case of Read activity, the mechanism is confused, because the old activity opened the ObjectChooser in a new instance. I don't know what happen with Scratch. Some activities had a lot of changes, but other like Distance or Implode not, and looks like the change to Gtk3 add a penalty. However there was also a change to kernel and Fedora version. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
qu...@laptop.org said: A better measurement to look for is the elapsed time of activity startup. This is a most interesting value, but it is difficult to obtain without changing the activity source so that the point of startup completion is identified. (That task is made more difficult since some activities schedule some of their startup _after_ their main startup.) Would it be worth adding a small chunk of code to Sugar to help this area? I'm thinking of an API to say OK, I'm really started now. so Sugar can log a line of data on how long it took to get started. There should probably be an environment variable to or similar enable that performance logging. -- These are my opinions. I hate spam. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
On Thu, Jul 4, 2013 at 9:55 PM, James Cameron qu...@laptop.org wrote: On Thu, Jul 04, 2013 at 07:16:11PM -0300, Gonzalo Odiard wrote: I did another comparison, between 13.2.0 os11 and os883 (sugar 0.94) You can see the results here: https://docs.google.com/spreadsheet/ccc?key= 0As_jQJX0Me6XdDI2clFpX1FFRHhKMHVFZGkyakdST2cusp=sharing Good data, thanks. Metodology: * Changed SUGAR_LOGGER_DEVEL * The activities were started from the listview, then are new instances * The start up time is the time reported by sugar in the log. A few questions to help with interpreting this data: - was this on an XO-1 or XO-1.5? I ask because it would help with comparing against other models. - what memory size? I ask because if memory is scarce, startup time will be increased. This was with a XO-1 C2 with 256 MB (SN SHC84203538) Is the only XO-1 I have. - did you start these activities twice and measure the second startup in order to exclude caching effects, or did you only measure the first startup? Only run one time every activity - was the system rebooted between each test, or were caches already populated? Didn't rebooted after every activity. The column start up difference, if negative, the time was improved. I added a column to show what activities were ported from Gtk2 to Gtk3. In the case of Read activity, the mechanism is confused, because the old activity opened the ObjectChooser in a new instance. I don't know what happen with Scratch. Some activities had a lot of changes, but other like Distance or Implode not, and looks like the change to Gtk3 add a penalty. However there was also a change to kernel and Fedora version. Yes. And changes in libraries, then is difficult point to any particular place. About how the time is measured, I am using the time printed by jarabe/model/shell.py line 566 The shell monitors the window opened event, and have some logic to detect if is the splash screen or the main window activity. I think is similar to what Hal is proposing. Gonzalo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
On Wed, Jul 03, 2013 at 02:21:08PM -0700, Yioryos Asprobounitis wrote: I'm using the XO-1.75 a bit more these days and gives me a sense of XO-1 performance wise. So I compared my (500/200 overclocked) XO-1 running F14/os885/Sugar-0.94 to XO-1.75 running F-18/13.2.0-11/Sugar-0.98. Since some general performance work was done between those software versions, the comparison is uninteresting. Compare 13.2.0-11 across XO-1 and XO-1.75, or compare XO-1 across os885 and 13.2.0-11, depending on what you are looking to prove. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
On Wed, Jul 3, 2013 at 7:10 PM, James Cameron qu...@laptop.org wrote: versions, the comparison is uninteresting. +1 -- we got some performance gains in drivers... and we lost some performance in the GTK3 PyGI battle. So it is paramount to compare matched sw versions. m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
All good for performance testing from a developer point of view. However, from a user experience point of view, taking an XO 1.0 running an old version and replacing it with an XO1.75 running a new version and seeing performance decrease I can be 'interesting'. In fact, I would argue that it is a necessary piece of knowledge to properly manage user expectations. Cheers,KG Sent from my currently functioning gadget From: Martin LanghoffSent: Wednesday, July 3, 2013 19:15To: James Cameron; Yioryos Asprobounitis; OLPC DevelSubject: Re: XO-1(.75)On Wed, Jul 3, 2013 at 7:10 PM, James Cameron qu...@laptop.org wrote: versions, the comparison is uninteresting.+1 -- we got some performance gains in drivers... and we lost someperformance in the GTK3 PyGI battle.So it is paramount to compare matched sw versions.m-- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff___Devel mailing listDevel@lists.laptop.orghttp://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
I don't think many users would get that luxury, and of those that do I don't think managing user expectations will be done. p.s. no such thing as XO-1.0 ;-) On Wed, Jul 03, 2013 at 07:23:52PM -0400, Kevin Gordon Gmail wrote: All good for performance testing from a developer point of view. However, from a user experience point of view, taking an XO 1.0 running an old version and replacing it with an XO1.75 running a new version and seeing performance decrease I can be 'interesting'. In fact, I would argue that it is a necessary piece of knowledge to properly manage user expectations. Cheers, KG Sent from my currently functioning gadget From: Martin Langhoff Sent: Wednesday, July 3, 2013 19:15 To: James Cameron; Yioryos Asprobounitis; OLPC Devel Subject: Re: XO-1(.75) On Wed, Jul 3, 2013 at 7:10 PM, James Cameron qu...@laptop.org wrote: versions, the comparison is uninteresting. +1 -- we got some performance gains in drivers... and we lost some performance in the GTK3 PyGI battle. So it is paramount to compare matched sw versions. m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
- Original Message - From: James Cameron qu...@laptop.org To: Yioryos Asprobounitis mavrot...@yahoo.com Cc: OLPC Devel devel@lists.laptop.org Sent: Thursday, July 4, 2013 2:10 AM Subject: Re: XO-1(.75) On Wed, Jul 03, 2013 at 02:21:08PM -0700, Yioryos Asprobounitis wrote: I'm using the XO-1.75 a bit more these days and gives me a sense of XO-1 performance wise. So I compared my (500/200 overclocked) XO-1 running F14/os885/Sugar-0.94 to XO-1.75 running F-18/13.2.0-11/Sugar-0.98. Since some general performance work was done between those software versions, the comparison is uninteresting. Compare 13.2.0-11 across XO-1 and XO-1.75, or compare XO-1 across os885 and 13.2.0-11, depending on what you are looking to prove. This comparison has been done a couple of months ago and is clear that F18/S0.98 taxes the systems considerably. What I found interesting in this unmatched comparison was the inconsistency. They might point to specific stacks in the architecture and/or core OS that may need attention (I originally thought was that activities with an extended non-python component or proportionally less gtk3, fair better on the XO-1.75 - but what do I know ;). Anyway, if the knowledgeable believe there is nothing to it or anything to be done about it,' there goes the comparison. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 Sugar startup profiling
On Mon, Mar 18, 2013 at 8:26 AM, Daniel Drake d...@laptop.org wrote:
2. Do python-level profiling of sugar to figure out why we are also
spending a lot of time executing pure Python code.
Its easy to hook up the python profiler:
Change the last line of /usr/bin/sugar to
exec python -m cProfile -o /tmp/sugar.prof /bin/sugar-session
Then after sugar exits (e.g. if you add the idle gtk.main_quit call
mentioned earlier) you can run:
python -m pstats /tmp/sugar.prof
and play away.
The top offender in the startup (which now takes 12 seconds on XO-1.5)
is {method 'send_message_with_reply_and_block' of
'_dbus_bindings.Connection' objects}
Seems to be called 171 times and takes a total of 2.47 seconds.
I guess this means we are sending 171 synchronous dbus messages during
startup. Would be nice to make them async.
Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: XO-1 Sugar startup profiling
On Mon, Mar 18, 2013 at 8:26 AM, Daniel Drake d...@laptop.org wrote: I then re-ran the test through perf on 13.2.0 build 1. 8.66% of this time is spent in g_typelib_get_dir_entry (libgobject-introspection). 6.79% is spent in pure Python (EvalFrameEx) 5.8% of the time is spent in libc. Oops, I meant to write g_typelib_get_dir_entry_by_gtype(). Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 update to 885
On Fri, Jun 15, 2012 at 10:54 AM, Yioryos Asprobounitis mavrot...@yahoo.com wrote: I was actually monitoring free space at 15sec intervals during olpc-update. Updating from os883 to os885 requires just 30MB free space. It is likely that from older builds will be a problem but not from the last official release. That's a good data point. Thanks! 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-1 disk space and 12.1 offline update
On Mon, Jun 18, 2012 at 01:39:47AM -0700, S Page wrote:
On an XO-1 running a freshly installed os883 release 11.3.0 with
nothing in ~/Documents and hardly any Journal entries I was unable to
successfully update using
sudo olpc-update 12.1.0d_xo1-12
, it ran out of space. The 12.1.0 build is now up to 14, but I don't
think it shrank between build 12 and 14. I had 297MB free beforehand,
and only 14MB free after the update failed.
This is unfortunate. I couldn't find a ticket for that, so I've
raised #11955.
I wanted to try an upgrade using OLPC's simple offline update[1], but
the download directory
http://download.laptop.org/xo-1/os/candidate/12.1.0-14/ lacks a
21014o0.usb file. It does have a 21014o0.toc , what's that for if
there's no .usb file?
The .usb file should be included in the next build, now that Daniel
has enabled the [usb_update] setting:
http://dev.laptop.org/git/projects/olpc-os-builder/commit/?id=252aa2a3c2859e2677e05675f7eaff2b5b430e54
But due to #11946, there might be a problem using it.
I had nothing important on the XO so I can just do a fresh install of
12.1.0, but if someone else is able to try an XO-1 online update from
a fresh-ish 11.3.0 to 12.1.0 and has similar problems I think the
release notes could usefully caution You will *not* be able to update
an XO-1 running 11.3.x unless you delete material from the standard
installation so that you have over NNN MB free.
Agreed. Changed. Let me know how much you need free.
Also, after a failed olpc-update, is there a guide to where the cruft
I can remove is? Since 11.3.0 is a recent build, the guide to
purging[2] doesn't apply; /versions/{contents,pristine,run} all only
contain 883. `sudo du -sh /versions/*` says I have 901MB in
/versions/pristine and 649MB in /versions/updates; combined that's
more than the 1024MB flash size, so either they overlap or JFFS2
compression really works! Is it safe to remove the contents of
/versions/updates?
Yes, but olpc-update will just download it again. Better is to free
up space and repeat olpc-update. Already downloaded data will be kept.
The combined size may be larger because of the use of hard links
between files that have not changed.
--
James Cameron
http://quozl.linux.org.au/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: XO-1 update to 885
--- On Fri, 6/15/12, James Cameron qu...@laptop.org wrote: From: James Cameron qu...@laptop.org Subject: Re: XO-1 update to 885 To: Yioryos Asprobounitis mavrot...@yahoo.com Cc: OLPC Devel devel@lists.laptop.org Date: Friday, June 15, 2012, 12:56 AM On Thu, Jun 14, 2012 at 09:35:20PM -0700, Yioryos Asprobounitis wrote: With the opportunity of 12.1.0/os14 update in the one of my XO-1s, I also tried to update my F14 XO-1 to 11.3.1/os885 but I get `can not download update contents' Indeed rsync://updates.laptop.org/ does not list build-885. Actually the only 885 build there is the for the XO-1.75. Gave it some time in case it pulls it after the request, but no result :-/ It pulls in at time of request, but you have to make the right request. (I would not use online update with an XO-1 because the amount of effort to make free space exceeds the time it would take to download an installation kit. But, please do test it if you can, and report your results.) I was actually monitoring free space at 15sec intervals during olpc-update. Updating from os883 to os885 requires just 30MB free space. It is likely that from older builds will be a problem but not from the last official release. So please try sudo olpc-update candidate_xo1-885 Yeh, that did it. Thx ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: XO-1 update to 885
The 885 are for XO-1: http://download.laptop.org/xo-1/os/candidate/885/ XO-1.5: http://download.laptop.org/xo-1.5/os/candidate/885/ and XO-1.75: http://download.laptop.org/xo-1.75/os/candidate/885/ Regards! Alan Date: Thu, 14 Jun 2012 21:35:20 -0700 From: mavrot...@yahoo.com Subject: XO-1 update to 885 To: devel@lists.laptop.org With the opportunity of 12.1.0/os14 update in the one of my XO-1s, I also tried to update my F14 XO-1 to 11.3.1/os885 but I get `can not download update contents' Indeed rsync://updates.laptop.org/ does not list build-885. Actually the only 885 build there is the for the XO-1.75. Gave it some time in case it pulls it after the request, but no result :-/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: XO-1 update to 885
Thanks.But I do not want to reflash the XO. Just to update it with olpc-update. --- On Fri, 6/15/12, Alan Jhonn Aguiar Schwyn alan...@hotmail.com wrote: From: Alan Jhonn Aguiar Schwyn alan...@hotmail.com Subject: RE: XO-1 update to 885 To: mavrot...@yahoo.com, devel@lists.laptop.org Date: Friday, June 15, 2012, 12:39 AM The 885 are for XO-1: http://download.laptop.org/xo-1/os/candidate/885/ XO-1.5: http://download.laptop.org/xo-1.5/os/candidate/885/ and XO-1.75: http://download.laptop.org/xo-1.75/os/candidate/885/ Regards! Alan Date: Thu, 14 Jun 2012 21:35:20 -0700 From: mavrot...@yahoo.com Subject: XO-1 update to 885 To: devel@lists.laptop.org With the opportunity of 12.1.0/os14 update in the one of my XO-1s, I also tried to update my F14 XO-1 to 11.3.1/os885 but I get `can not download update contents' Indeed rsync://updates.laptop.org/ does not list build-885. Actually the only 885 build there is the for the XO-1.75. Gave it some time in case it pulls it after the request, but no result :-/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 update to 885
On Thu, Jun 14, 2012 at 09:35:20PM -0700, Yioryos Asprobounitis wrote: With the opportunity of 12.1.0/os14 update in the one of my XO-1s, I also tried to update my F14 XO-1 to 11.3.1/os885 but I get `can not download update contents' Indeed rsync://updates.laptop.org/ does not list build-885. Actually the only 885 build there is the for the XO-1.75. Gave it some time in case it pulls it after the request, but no result :-/ It pulls in at time of request, but you have to make the right request. (I would not use online update with an XO-1 because the amount of effort to make free space exceeds the time it would take to download an installation kit. But, please do test it if you can, and report your results.) You said you used updates.laptop.org via rsync to test for the presence of a build. updates.laptop.org uses rsync but is not an ordinary rsync server ... while you can use the displayed list as evidence of a build existing, you can't use the list as evidence of a build missing. This is because when a name is presented, it looks for the build in another place. You aren't shown that other place. Given that the existing name for XO-1.75 is build-candidate_xo1.75-885 it is likely that the correct name for XO-1 would be build-candidate_xo1-885 ... I've tried this, and got a suitably long delay while the updates.laptop.org server unpacked the build, and the response looks good. So please try sudo olpc-update candidate_xo1-885 http://wiki.laptop.org/go/Release_notes/12.1.0#XO-1_2 -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 update to 885
On Fri, Jun 15, 2012 at 02:56:24PM +1000, James Cameron wrote: [...] So please try sudo olpc-update candidate_xo1-885 http://wiki.laptop.org/go/Release_notes/12.1.0#XO-1_2 Sorry, wrong link. http://wiki.laptop.org/go/Release_notes/11.3.1#XO-1_2 -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 SD card access during boot-up
On Wed, May 30, 2012 at 12:08:40AM +0200, Sascha Silbe wrote: James Cameron qu...@laptop.org writes: The XO-1 SD card slot power supply circuit does not have a discharge clamping function, and so when the firmware or software turns off the power to the slot, the voltage falls slowly. The fall rate violates the specification for cards. [...] When an SD card is used as the boot media, it remains powered, and so one would typically not see this symptom. I understand this is only once Linux has taken over; OFW always powers down the card after each access? Yes, after each access, where access is a directory search or a file open and close. That is, if a file is opened, the power is not dropped until the file is closed. Open Firmware briefly powers the SD card slot during boot, as part of the search for an operating system to boot. [...] Would it be possible to avoid powering down the card after the first power-up in OFW? Yes. Or is a software reset (i.e. CMD0) insufficient for reinitialisation in Linux? (The standard suggests [2] it is, but actual cards may or may not be behave that way.) I don't know. Let me know if you test it. We know that a power cycle will reset a card. Would something like ' noop to card-power-off be sufficient or does OFW rely on the card getting powered down? Open Firmware does not entirely rely on the card getting powered down, in that on hardware that does not power the card down it works fine. I may have hit this problem again recently [1], if the SD card containing the image to be flashed indeed gets powered down intermittently during flashing. It should not be powered down intermittently during flashing, but it should be powered down at the end of flashing. Regarding USB SD card readers in [1], these will not work with Open Firmware if they present USB interfaces unlike a USB flash or hard drive. A card reader here has two interfaces, one of which is used by the host to select which slot will be bound to the other interface. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 SD card access during boot-up
On Wed, May 30, 2012 at 03:14:49AM -0400, John Watlington wrote: On May 30, 2012, at 2:04 AM, James Cameron wrote: On Wed, May 30, 2012 at 12:08:40AM +0200, Sascha Silbe wrote: Or is a software reset (i.e. CMD0) insufficient for reinitialisation in Linux? (The standard suggests [2] it is, but actual cards may or may not be behave that way.) I don't know. Let me know if you test it. We know that a power cycle will reset a card. Probably not. If a card suffers a brownout, which is what is happening here, all bets are off. You have to power cycle the card (leaving it powered off long enough to ensure the supply voltage drops close to zero) to ensure proper operation. Agreed. I meant a proper power cycle, not the type provided by XO-1 without supply discharge. My point is that it is hard to know if leaving the power on and using CMD0 is any better than turning the power off. We already have a delay in the firmware to provide 250ms fall time for XO-1 and XO-1.5. We could increase that, but it will slow booting still further. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 SD card access during boot-up
On May 30, 2012, at 3:42 AM, James Cameron wrote: Agreed. I meant a proper power cycle, not the type provided by XO-1 without supply discharge. My point is that it is hard to know if leaving the power on and using CMD0 is any better than turning the power off. We already have a delay in the firmware to provide 250ms fall time for XO-1 and XO-1.5. We could increase that, but it will slow booting still further. I misunderstood the question, and can answer that one. CMD0 only works if the card is already in a working state. Power cycling will always reset the card to a working state. A while back, Microsoft finally got tired of the number of computers that could get themselves wedged into a state which required a hard power cycle, and starting insisting that the ability to power cycle the SD/MMC card was required for Windows certification. Cheers, wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 SD card access during boot-up
On Sun, May 27, 2012 at 11:22 AM, Mikus Grinbergs mi...@bga.com wrote: For three years now, as part of my XO customization I've had an initialization script in /etc/rc.d/init.d/ that issues an explicit 'mount' This is a shot in the dark, but might be of use.Your mount script was racing with the automounter -- and perhaps winning always/most of the time. The startup sequence and the automounter have changed *radically* in 12.1.0 with the introduction of systemd. The closest I have to a clue is that /media appears to be empty. It probably doesn't exist anymore _and_ you are racing with some init script from the new, wild and wooly systemd world. The user removable device automounter mountpoints are now under /run/ (I think /run/user/username/media or somesuch). hth, 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-1 SD card access during boot-up
James Cameron qu...@laptop.org writes: The XO-1 SD card slot power supply circuit does not have a discharge clamping function, and so when the firmware or software turns off the power to the slot, the voltage falls slowly. The fall rate violates the specification for cards. [...] When an SD card is used as the boot media, it remains powered, and so one would typically not see this symptom. I understand this is only once Linux has taken over; OFW always powers down the card after each access? Open Firmware briefly powers the SD card slot during boot, as part of the search for an operating system to boot. [...] Would it be possible to avoid powering down the card after the first power-up in OFW? Or is a software reset (i.e. CMD0) insufficient for reinitialisation in Linux? (The standard suggests [2] it is, but actual cards may or may not be behave that way.) Would something like ' noop to card-power-off be sufficient or does OFW rely on the card getting powered down? I may have hit this problem again recently [1], if the SD card containing the image to be flashed indeed gets powered down intermittently during flashing. Sascha [1] message-id:toeobphnrh2@twin.sascha.silbe.org http://lists.laptop.org/pipermail/devel/2012-May/035137.html [2] https://www.sdcard.org/downloads/pls/simplified_specs/Part_1_Physical_Layer_Simplified_Specification_Ver_3.01_Final_100518.pdf Figure 4-1, PDF page 32 -- http://sascha.silbe.org/ http://www.infra-silbe.de/ pgpw6KlTBjmSC.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 to switch back to JFFS2
+1 -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 to switch back to JFFS2
On Wed, Apr 4, 2012 at 5:33 PM, Daniel Drake d...@laptop.org wrote: Hi, I'm planning on moving the XO-1 back to JFFS2 for 12.1.0 - and likely for the future too. The reasons being: 1. UBIFS is considerably less space-efficient than JFFS2. http://www.linux-mtd.infradead.org/faq/ubifs.html#L_jffs2_space We needed the disk space already, and we're battling constant growth of the Fedora platform. Deployments will also appreciate not losing 50mb of space which can be used for content, user data, etc. 2. UBIFS is less robust in the face of bad blocks. At image creation time, UBIFS allocates a number of blocks that are used when other blocks go bad. When that allocation is exceeded (i.e. when blocks go bad), UBI goes read-only and there is no simple recovery except another reflash. JFFS2 is more robust here. The ubifs_image module will remain in olpc-os-builder for those who wish to try it, but the OLPC configs and images will switch back to JFFS2 (which is what we've used in all stable releases til now). Comments/objections? From my narrow perspective, more space and robustness are more important than a boost in re-flash speed or boot speed. So +1 from here. Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 to switch back to JFFS2
On Apr 4, 2012, at 10:37 PM, Martin Langhoff wrote: On Wed, Apr 4, 2012 at 5:33 PM, Daniel Drake d...@laptop.org wrote: Comments/objections? JFFS2 worked well enough when those laptops were built and tested! It's sad that this space (raw NAND filesystems) isn't seeing more attention from filesystems people. But it seems a pretty established trend, now that FTLs have gotten better and their cost has for all practical purposes disappeared. I started looking at ubifs expecting to at least have the chance to use it on larger raw devices. The nine-month technology cycle time of the NAND Flash industry just doesn't fit well with the larger SoC design time. The notable point, IMO, is the growing acceptance of FTLs everywhere, through SSDs. Cheers, wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 cpu temperature [Devel Digest, Vol 71, Issue 43]
On 01/23/2012 02:56 AM, Yioryos Asprobounitis wrote: The thing is that XO-1.5 has about twice the XO-1 processing power and is quite usable. So getting another 50%+ out of the XO-1 (albeit with risks) may keep it in stride with the new software versions a bit longer. Of course I do realize that this should have nothing to do with OLPC, thus the vague questions ;) It won't work that way. Although in some cases you can increase the clock frequency a bit and have it still function the system is designed to run at the specified frequency. We didn't use parts that were rated for 1Ghz and then dial it down. We used the highest speed parts that we could get in our cost range and designed for that operating frequency. But may be all this is irrelevant now as pushing the XO-1 to 600MHz (extrapolating from these guys) results in kernel panics and/or errors. If this is because of the protection mechanisms I would appreciate if someone lets me know off-list (I promise not to tell) of a possible way around it. Its not a protection mechanism. Its because one of the system buses is corrupted because its being forced to operate above its design rating. A thermal shutdown will be a hang since the clock to the CPU is stopped. The thermal shutdown is not configurable and you can't bypass it. -- 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-1 cpu temperature [Devel Digest, Vol 71, Issue 43]
if you don't feel like hunting down the correct
block device on the linux side
But there __is__ no block device defined by the 12.1.0 operating system
when running on the XO-1. { Raw /dev/ubi0, whose partition contains the
root file system, is defined as a character device. } I don't want to
get into making my own major and minor inode numbers, etc., etc.
[ I normally don't run Gnome. When I now switched over to Gnome -- it
saw the same devices (and only those devices) as when running Sugar. ]
you can probably edit it from OFW
I will liken finding out OFW capabilities (and commands) to pulling
hen's teeth. When I inquired in 2008, the answer was read the code.
Still haven't gotten around to doing that.
Thank you for responding, mikus
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: XO-1 cpu temperature [Devel Digest, Vol 71, Issue 43]
On Mon, Jan 23, 2012 at 6:03 PM, Mikus Grinbergs mi...@bga.com wrote: I will liken finding out OFW capabilities (and commands) to pulling hen's teeth. When I inquired in 2008, the answer was read the code. Still haven't gotten around to doing that. And then January 2012 came, and some lunatic gave you an exact command to type! Man, that's so different! Maybe it even works -- now that'd be a change! ;-) 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-1 cpu temperature [Devel Digest, Vol 71, Issue 43]
Access to the jffs2 boot partition of the XO-1 NAND Flash is required for any kernel upgrade ... so having it missing should be breaking olpc-update. I expect this will need to be fixed during development of 12.1.0, and when it is fixed your access to the boot partition should be easier. It isn't a matter of hunting down a correct block device. I don't think there should be any block devices for the XO-1 NAND Flash ... they will be mtd or character devices. We did have mtdblock by mistake once, fixed in #11234. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 cpu temperature [Devel Digest, Vol 71, Issue 43]
On 01/23/2012 04:20 PM, Mikus Grinbergs wrote: Please (I'm trying to ask nicely!), can you all tell me what I need to tweak to make customizing the olpc.fth (plus run 'rpm -U kernel...') be effective on 12.1.0. [ I know how to make them work on 11.3.0. ] Ah.. I misunderstood you. When you said device I thought you were referring a to an OFW device tree device, like the device that lets you do MSR access. I didn't realize you were talking about access to the boot partition. I could help you with a firmware issue but I'm afraid I can't help much with 12.1.0. The boot partition is supposed to be accessible via /bootpart/boot or /boot if its not then its just a bug that will get fixed up later. 12.1.0 is still in its infancy. I wouldn't expect much to work for quit a few more builds. Like Martin's e-mail suggested you can open 'olpc.fth' in a small editor under OFW. You can edit the file there and make your changes. No Linux involved. Although I'm not sure if that version of firmware can edit files on the bootpart correctly. There have recently been a bunch of fixes for OFW ext2/3/4 support. Alternatively you could decompress the os image file on a desktop machine, edit the file and then re-compress it. -- 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-1 cpu temperature
On 01/21/2012 09:58 AM, Yioryos Asprobounitis wrote: I was wondering if there is anyway to monitor the geode temperature on the XO-1. I would like to test how far I can push it without ruining it. The CPU is protected by a thermal shutdown circuit it will shutdown before you cause any thermal damage. Unless you are trying hardware modifications I doubt you will do anything worse than these guys. http://www.olpcnews.com/forum/index.php?topic=2389.0 What exact are you going to try and push? -- 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-1 cpu temperature [Devel Digest, Vol 71, Issue 43]
I was wondering if there is anyway to monitor the geode temperature on the XO-1. I would like to test how far I can push it without ruining it. The CPU is protected by a thermal shutdown circuit it will shutdown before you cause any thermal damage. Unless you are trying hardware modifications I doubt you will do anything worse than these guys. http://www.olpcnews.com/forum/index.php?topic=2389.0 What exact are you going to try and push? -- Richard A. Smith rich...@laptop.org One Laptop per Child Something worse than these guys! ;) With the XO-1 being EOL some time now and the ones in the field aging some dangerous playing might not be unthinkable. As you know kids are notorious for not playing safe... The thing is that XO-1.5 has about twice the XO-1 processing power and is quite usable. So getting another 50%+ out of the XO-1 (albeit with risks) may keep it in stride with the new software versions a bit longer. Of course I do realize that this should have nothing to do with OLPC, thus the vague questions ;) But may be all this is irrelevant now as pushing the XO-1 to 600MHz (extrapolating from these guys) results in kernel panics and/or errors. If this is because of the protection mechanisms I would appreciate if someone lets me know off-list (I promise not to tell) of a possible way around it. Thanks ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 touchpad once more [Devel Digest, Vol 64, Issue 28]
Anyway to quantify touchpad use and behaivor in F9 builds? I don't know of any way that involves only the laptop or software. Quantifying use and behaviour would require a video camera on both the touchpad and the screen. Or accurate reporting from both people who experience a problem and those who do not. Self selected reporting from community enthusiasts isn't as reliable. It might be possible for testers to tape a small mirror on their XO camera (perhaps 1cm square), so it can see the touchpad. Run a test program in the background that records the video into a circular RAM buffer, and saves a chunk of it whenever it sees the pointer jump. Then go on doing what you usually do on the XO. An engineer can later look at those saved videos to see how many of the pointer jumps happened without a corresponding finger motion. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 touchpad once more [Devel Digest, Vol 64, Issue 28]
--- On Tue, 6/14/11, James Cameron qu...@laptop.org wrote: From: James Cameron qu...@laptop.org Subject: Re: XO-1 touchpad once more [Devel Digest, Vol 64, Issue 28] To: Yioryos Asprobounitis mavrot...@yahoo.com Cc: devel@lists.laptop.org Date: Tuesday, June 14, 2011, 6:01 PM On Tue, Jun 14, 2011 at 12:35:52AM -0700, Yioryos Asprobounitis wrote: I do not know why you say we certainly seem to have reduced the frequency of the problem overall but here is some numbers to compare. The overall frequency of reports of the problem. Not the frequency on your laptop. But that could also represent a smaller community. Or people just gave up on expecting a fix on this well known and publicized problem and use an external mouse. However, I do not think that is not a big issue if newer builds indeed make it worse. On that matter, I was thinking that the kbdshim debug option could provide touchpad use data and compare it to jumping events. Anyway to quantify touchpad use and behaivor in F9 builds? -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 touchpad once more [Devel Digest, Vol 64, Issue 28]
On Tue, Jun 14, 2011 at 11:28:54PM -0700, Yioryos Asprobounitis wrote: Or people just gave up on expecting a fix on this well known and publicized problem and use an external mouse. Yes, that's a possibility too. One child I test with insists on an external mouse, even if I'm offering them an XO-1.5 - which has an entirely different touchpad model that has never shown the symptom. However, I do not think that is not a big issue if newer builds indeed make it worse. I don't see enough data that newer builds make it worse, but data would be useful. I'd like this to be evidence based. How would you capture the data reliably? On that matter, I was thinking that the kbdshim debug option could provide touchpad use data and compare it to jumping events. Ah, you're beyond my knowledge at this point. Anyway to quantify touchpad use and behaivor in F9 builds? I don't know of any way that involves only the laptop or software. Quantifying use and behaviour would require a video camera on both the touchpad and the screen. Or accurate reporting from both people who experience a problem and those who do not. Self selected reporting from community enthusiasts isn't as reliable. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 touchpad once more [Devel Digest, Vol 64, Issue 28]
From: James Cameron qu...@laptop.org Or accurate reporting from both people who experience a problem and those who do not. Self selected reporting from community enthusiasts isn't as reliable. I would certainly agree on that. And is (unfortunately) true that reporting problems is much more frequent than reporting successes. However, you would expect if touchbad behavior was indeed improved some random reports would have appeared, and I honestly have not seen one. Of course this does not mean that got worse either, but that's the so far _indications_ Without accurate measurement on F9 builds will be hard to compare and conclude, so indication maybe the only thing we can have. Best -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 touchpad once more [Devel Digest, Vol 64, Issue 28]
On Wed, Jun 15, 2011 at 01:48:20AM -0700, Yioryos Asprobounitis wrote: However, you would expect if touchbad behavior was indeed improved some random reports would have appeared, and I honestly have not seen one. No, I wouldn't have expected that. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 touchpad once more [Devel Digest, Vol 64, Issue 28]
On Wed, Jun 15, 2011 at 2:28 AM, Yioryos Asprobounitis mavrot...@yahoo.com wrote: However, I do not think that is not a big issue if newer builds indeed make it worse. If you think newer builds make it worse, and can help us keeping track of it in detail, yes, we need and want your help. But your testing of a different OS means you have a different stack from what we ship. Can you test with a recent 11.2.0 dev image? Maybe running it from an SD card to preserve your internally-installed OS... 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-1 touchpad once more [Devel Digest, Vol 64, Issue 28]
The newer builds are close to unusable. That is one of the reason I do not use them. (The other is that the gamepad does not work and it kills the XO-1 as an ebook reader...) On 2011.06.15. 14:09, Martin Langhoff wrote: On Wed, Jun 15, 2011 at 2:28 AM, Yioryos Asprobounitis mavrot...@yahoo.com wrote: However, I do not think that is not a big issue if newer builds indeed make it worse. If you think newer builds make it worse, and can help us keeping track of it in detail, yes, we need and want your help. But your testing of a different OS means you have a different stack from what we ship. Can you test with a recent 11.2.0 dev image? Maybe running it from an SD card to preserve your internally-installed OS... cheers, m ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 touchpad once more [Devel Digest, Vol 64, Issue 28]
--- On Wed, 6/15/11, Martin Langhoff martin.langh...@gmail.com wrote: From: Martin Langhoff martin.langh...@gmail.com Subject: Re: XO-1 touchpad once more [Devel Digest, Vol 64, Issue 28] To: Yioryos Asprobounitis mavrot...@yahoo.com Cc: James Cameron qu...@laptop.org, devel@lists.laptop.org Date: Wednesday, June 15, 2011, 8:09 AM On Wed, Jun 15, 2011 at 2:28 AM, Yioryos Asprobounitis mavrot...@yahoo.com wrote: However, I do not think that is not a big issue if newer builds indeed make it worse. If you think newer builds make it worse, and can help us keeping track of it in detail, yes, we need and want your help. But your testing of a different OS means you have a different stack from what we ship. Can you test with a recent 11.2.0 dev image? Why do you say that? The attachment did have data from virgin os860 and 1.2.0 dev builds (os18-os22). It even indicates if Sugar or Gnome was used at the given 5-7 minutes segment. The puppy data was because I was testing the touchpad power-cycle idea. Could be easily done in official/dev builds too but tried to keep them as pristine as possible. As I mentioned, better testing can be done using kbdshim debug data (assuming they do not affect behavior), but without a way to test in F9 builds the comparison will always be inconclusive and (correctly) labeled subjective. However, if anybody thinks that recording/knowing touchpad spur events pet touchpad transmitted bids could be of any value and triggers another look at the touchpad, I could try it. Maybe running it from an SD card to preserve your internally-installed OS... 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-1 touchpad once more [Devel Digest, Vol 64, Issue 28]
On Wed, Jun 15, 2011 at 9:06 AM, Yioryos Asprobounitis mavrot...@yahoo.com wrote: from what we ship. Can you test with a recent 11.2.0 dev image? Why do you say that? The attachment did have data from virgin os860 and 1.2.0 dev builds (os18-os22). Because I didn't look into the attachment -- oops. I just read your email and understood you were just using puppy linux. thanks, and apologies! 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-1 touchpad once more [Devel Digest, Vol 64, Issue 28]
yioryos wrote: Date: Tue, 14 Jun 2011 09:45:08 +1000 From: James Cameron qu...@laptop.org Subject: Re: XO-1 touchpad once more Well, we certainly seem to have reduced the frequency of the problem overall, even if a few people who never had the problem now have it. ;-) It's the overall frequency that matters. I do not know why you say we certainly seem to have reduced the frequency of the problem overall but here is some numbers to compare. james' statement surprised me a bit, too, since i'm not sure that we have data to back that up. but regardless... I'm not using my XO-1s as much lately, since the XO-1.5 is much more pleasant to use :-) but still managed to gather touchpad events through several hours of use from my 2 XO-1s. One is running os860 while the other different OLPC 11.2.0 development builds. Both are also running Puppy linux from an SDcard. The data record re-calibration events and in most cases CPU load and memory use, in 5 or 7 minutes intervals. When running puppylinux there are also some logs where the touchpad is powered cycled in 5 or 7 minutes intervals during a sudo anti-RSI step that appears to improve touchpad behavior [1]. Unfortunately the data are not processed in any meaningful way but the frequency and the extend of the events is evident. Maybe it i guess i don't see it. just skimming your logs, i'm not having trends jump out at me. but as you say, that's not really fair without having the data plotted in some meaningful way. perhaps someone listening with good data visualization skills could help us out here? paul could be compared with F7/F9 data if available. [1] http://www.murga-linux.com/puppy/viewtopic.php?p=513017#513017 =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 touchpad once more [Devel Digest, Vol 64, Issue 28]
On Tue, Jun 14, 2011 at 12:35:52AM -0700, Yioryos Asprobounitis wrote: I do not know why you say we certainly seem to have reduced the frequency of the problem overall but here is some numbers to compare. The overall frequency of reports of the problem. Not the frequency on your laptop. But that could also represent a smaller community. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 touchpad once more
On 13 Jun 2011, at 20:36, Yioryos Asprobounitis mavrot...@yahoo.com wrote: I came across a forum post [1] (last sentence) that remind it me once more the ALPS XO-1 touchpad issue. In all the post os802 builds, OLPC 10.1.x, Dextrose 2x and OLPC 11.2.0, the problem is *considerably* worse eg much more often and persistent than in F9 builds. The fact that the touchpad was jumpy before, may result in labeling this not a regression. But is clearly NOT the case. With post F9 builds is really hard to use first generation XO-1s without a mouse. Before was bad, now is close to intolerable. Just wanted to chime in that I've been switching between 802 and os19/os21 while testing/debugging some of the activities I maintain on XO-1 hardware. The trackpad reliability does seem to have taken a step or two back from where we were with 802 (more frequently grinds to near stationary, and more frequently decides to drift when no fingers are near the trackpad). Sorry, no hard numbers. I wouldn't go as far as to say it is close to intolerable, but it is more frustrating than before. I did wonder if it could be due to the debugging level for these test builds? Lots more getting written to the logs. Not sure how to change logging level these days, is it now hidden in gconf somewhere? Regards, --Gary I can appreciate that ALPS XO-1s are long EOL and newer builds and hardware are more pressing matters, but we are talking probably half the OLPC installed base here that may not be able to be fully benefited by the newer builds. I do not think that should be seen as a secondary issue or something that there is nothing to be done about. Yes, it is a hardware problem in its core but it was not that bad in older builds. So something should/could be done to at least go back to that level of discomfort. What about going back to the 2.6.25 driver? Even without auto-recalibration provided a better user experience apparently. [1] http://www.olpcnews.com/forum/index.php?topic=5000 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 touchpad once more
Well, we certainly seem to have reduced the frequency of the problem overall, even if a few people who never had the problem now have it. ;-) It's the overall frequency that matters. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Re: XO-1 touchpad once more
My experience is that the xo1 touchpad previously had infrequent periods of total unusability, that is you just had to shut the lid and do something else for an hour but this was a relatively rare event, maybe once a week Now the touchpad auto-recalibrates, there are frequent periods of unusability that last for round 30 seconds, maybe 4 times an hour This no doubt varies from laptop to laptop. I suspect that for my XO1, the error sensing for the recalibrate is more aggressive than optimum. I recollect that the driver's author issued the invitation for people to mess with the settings and report what settings work best for them. Maybe if anybody is unhappy with current performance, the best contribution would be to look at the source and experiment with the settings Tony Well, we certainly seem to have reduced the frequency of the problem overall, even if a few people who never had the problem now have it. ;-) It's the overall frequency that matters. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1: Lid close/open
qu...@laptop.org said: But the network doesn't come back. I was expecting it to reconnect to my AP. Nothing to do with #10402. Continue to investigate. It works with GNOME so I expect Sugar is missing a few lines of code. http://bugs.sugarlabs.org/ticket/2808 --- Speaking of WiFi... My /var/log/messages has several clumps of things like this: Apr 27 01:46:12 xo-0d-57-33 kernel: [ 2510.094064] libertas: submit 802_11_GET_LOG (#10748 diag) grep finds 566 in about an hour I've also got one of these: Apr 27 01:54:24 xo-0d-57-33 kernel: [ 2998.013473] [ cut here ] Apr 27 01:54:24 xo-0d-57-33 kernel: [ 2998.018132] WARNING: at net/sched/sch_generic.c:258 dev_watchdog+0xf0/0x176() Apr 27 01:54:24 xo-0d-57-33 kernel: [ 2998.025368] Hardware name: XO Apr 27 01:54:24 xo-0d-57-33 kernel: [ 2998.028346] NETDEV WATCHDOG: eth0 (usb): transmit queue 0 timed out ... Does anybody want those log files? If so, who? ... -- These are my opinions, not necessarily my employer's. I hate spam. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 hangs upon yum update in Gnome
On Sun, Apr 03, 2011 at 03:43:46PM +0800, Carlos Nazareno wrote: The machine will download the info + list of files to be update, asks if I want to continue, then when I say yes, at around the 3rd (out of 23 updates), the machine will go sluggish and more or less hang/be unusable and I have to do a hard power-off. Any tips? Expected, normal. See http://wiki.laptop.org/go/Yum#Memory_Limitations -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 hangs upon yum update in Gnome
On Sun, Apr 3, 2011 at 7:59 PM, James Cameron qu...@laptop.org wrote: Expected, normal. Known bug. sudo umount /var/cache/yum before using yum and you'll be fine. 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-1 OFW occasionally has difficulty reading from my permanent SD card [Devel Digest, Vol 61, Issue 38]
You might try patching OpenFirmware to not turn off the card between subsequent accesses. To do this, assuming you are using Q2E45, add the following early in your olpc.fth file: dev /sd patch 2drop cb! card-power-off Is this also true for the XO-1.5 q3a62? or is an XO-1-only issue? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 developer key does not work
If your laptops contain your deployment keys, I would recommend using this [1] so you can easily generate and manage your activations in situations like this :). 1. http://wiki.paraguayeduca.org/index.php/Yaas_documentation kind regards, tch On Sat, Mar 12, 2011 at 1:46 AM, Sridhar Dhanapalan srid...@laptop.org.au wrote: On 12 March 2011 05:10, C. Scott Ananian csc...@cscott.net wrote: Posting your machine's serial number as well as then contents of your develop.sig might help; your developer key might be malformed or correspond to a different XO than the one you are trying to use it on. You can also try the collection key method, as one more check on the process by which you are generating the developer key. This is a bit strange - I am getting a different result for each method. Printed in the battery compartment is the serial number SHC83102126 /home/.devkey.html contains: SN - SHC8320373E UUID - D5576981-BDA0-4271-ABFE-0183633847D1 /ofw/serial-number contains SHC832038CC laptops.dat (created with a collection key) contains: SHC832038CC C95B2B75-18A6-4860-B834-9AEAC7A4C47F 20110312T034351Z laptops.dat concurs with /ofw/serial-number. I've used the laptop.dat details to request a developer key. The page says that it'll be available in 24 hours. There are three main questions raised by this process: 1. why am I getting different readings for each method? 2. what is the most trustworthy method? 3. why must I wait 24 hours to get the developer key? Thanks, Sridhar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 developer key does not work
Nice, you pre-empted my next question! :D Thanks, Sridhar On 15 March 2011 00:03, Martin Abente martin.abente.lah...@gmail.com wrote: If your laptops contain your deployment keys, I would recommend using this [1] so you can easily generate and manage your activations in situations like this :). 1. http://wiki.paraguayeduca.org/index.php/Yaas_documentation kind regards, tch On Sat, Mar 12, 2011 at 1:46 AM, Sridhar Dhanapalan srid...@laptop.org.au wrote: On 12 March 2011 05:10, C. Scott Ananian csc...@cscott.net wrote: Posting your machine's serial number as well as then contents of your develop.sig might help; your developer key might be malformed or correspond to a different XO than the one you are trying to use it on. You can also try the collection key method, as one more check on the process by which you are generating the developer key. This is a bit strange - I am getting a different result for each method. Printed in the battery compartment is the serial number SHC83102126 /home/.devkey.html contains: SN - SHC8320373E UUID - D5576981-BDA0-4271-ABFE-0183633847D1 /ofw/serial-number contains SHC832038CC laptops.dat (created with a collection key) contains: SHC832038CC C95B2B75-18A6-4860-B834-9AEAC7A4C47F 20110312T034351Z laptops.dat concurs with /ofw/serial-number. I've used the laptop.dat details to request a developer key. The page says that it'll be available in 24 hours. There are three main questions raised by this process: 1. why am I getting different readings for each method? 2. what is the most trustworthy method? 3. why must I wait 24 hours to get the developer key? Thanks, Sridhar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 OFW occasionally has difficulty reading from my? permanent SD card [Devel Digest, Vol 61, Issue 38]
On Sun, Mar 13, 2011 at 11:27:44PM -0700, Yioryos Asprobounitis wrote: You might try patching OpenFirmware to not turn off the card between subsequent accesses.? To do this, assuming you are using Q2E45, add the following early in your olpc.fth file: ??? dev /sd ??? patch 2drop cb! card-power-off Is this also true for the XO-1.5 q3a62? or is an XO-1-only issue? The workaround you quoted above is not correct for XO-1.5 Q3A62, it was correct only for Q2E45. The root cause of the problem (failure to discharge the power supply to the card) is also present in XO-1.5 hardware. This is described in http://dev.laptop.org/ticket/10512 A workaround is in Q3A62 which increases the time that the firmware waits after turning off the power to the card. http://tracker.coreboot.org/trac/openfirmware/changeset/2065 shows the time was increased from 20ms to 40ms. This was so that a new batch of cards in manufacturing would pass testing. It is not possible for me to predict the behaviour on other cards, since I don't have them. This change also adds support for changing the delay: dev /sd d# 60 to power-off-time The change is lost on reboot. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 developer key does not work
On 14 March 2011 10:58, James Cameron qu...@laptop.org wrote: On Sat, Mar 12, 2011 at 03:46:02PM +1100, Sridhar Dhanapalan wrote: There are three main questions raised by this process: [...] 3. why must I wait 24 hours to get the developer key? Presuming you are asking about an OLPC developer key rather than a deployment developer key ... the delay is to allow time for the laptop to be reported to OLPC as stolen. If an XO has both the OLPC and our own deployment developer keys, would it be correct to say that it can receive a developer key from either OLPC or us? Hence, an XO theft must be reported to both OLPC and OLPCAU? Sridhar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 developer key does not work
Sridhar - Yes, that's correct. Multiple valid keys weakens security, since the same rights can be obtained from multiple sources. Handling your own key-issuing authority is something we fully support, but it is a complex and substantial undertaking. It requires a reasonable commitment to both initial and ongoing staffing infrastructure on your end. I won't advise you not to consider it, but if you're considering it you should take it very seriously. That is particularly true if you are interested in replacing OLPC's various keys with your own (rather than adding to them). If you do so you can get yourself into situations in which no one else can help you. The very well-organized and professional team at Plan Ceibal (who replace OLPC's keys with their own) have had a few difficulties in the field. It's also important to realize that you'll need to provide support to Quanta's manufacturing team. Sometimes laptops require reworking due to test failures, and that can require them to be unlocked; if they're not using OLPC's keys you'll have to be able to provide those keys yourself. - Ed On Mar 14, 2011, at 7:46 PM, Sridhar Dhanapalan wrote: On 14 March 2011 10:58, James Cameron qu...@laptop.org wrote: On Sat, Mar 12, 2011 at 03:46:02PM +1100, Sridhar Dhanapalan wrote: There are three main questions raised by this process: [...] 3. why must I wait 24 hours to get the developer key? Presuming you are asking about an OLPC developer key rather than a deployment developer key ... the delay is to allow time for the laptop to be reported to OLPC as stolen. If an XO has both the OLPC and our own deployment developer keys, would it be correct to say that it can receive a developer key from either OLPC or us? Hence, an XO theft must be reported to both OLPC and OLPCAU? Sridhar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 developer key does not work
On 15 March 2011 11:01, Ed McNierney e...@laptop.org wrote: Sridhar - Yes, that's correct. Multiple valid keys weakens security, since the same rights can be obtained from multiple sources. Handling your own key-issuing authority is something we fully support, but it is a complex and substantial undertaking. It requires a reasonable commitment to both initial and ongoing staffing infrastructure on your end. I won't advise you not to consider it, but if you're considering it you should take it very seriously. That is particularly true if you are interested in replacing OLPC's various keys with your own (rather than adding to them). If you do so you can get yourself into situations in which no one else can help you. The very well-organized and professional team at Plan Ceibal (who replace OLPC's keys with their own) have had a few difficulties in the field. It's also important to realize that you'll need to provide support to Quanta's manufacturing team. Sometimes laptops require reworking due to test failures, and that can require them to be unlocked; if they're not using OLPC's keys you'll have to be able to provide those keys yourself. Thanks for that, Ed. At this point, we are having our deployment keys applied to XOs in the factory and field in addition to the standard OLPC keys. Our XOs are not developer locked, but I'm creating the option to lock them later on should the situation ask for it. It likely will be quite a while before we seriously consider it. Sridhar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 OFW occasionally has difficulty reading from my permanent SD card
G'day Mikus, Fristly, use disable-security so that the developer key is not required to be present. Is there a good reason for not disabling the security system? However, if you are booting the laptop from the SD card this may merely move the problem from developer key recognition to booting. Secondly, there is a design oversight in the XO-1 powering of the SD card, in that the laptop does not force the power off quickly enough (#10512); the power can remain at a voltage that can trigger unpredictable behaviour of an SD card. This wasn't much of a problem with SD cards some years ago, but I have found more reports of it with modern cards. OpenFirmware powers off the SD card between the access to the root directory and the access to the security directory. It also does the same between the access to the root directory and the boot directory. It would take a new release of OpenFirmware for XO-1 to add a workaround for this. You might try patching OpenFirmware to not turn off the card between subsequent accesses. To do this, assuming you are using Q2E45, add the following early in your olpc.fth file: dev /sd patch 2drop cb! card-power-off However this doesn't prevent power off events that will occur before olpc.fth is executed. That's a good reason to disable-security perhaps, but there will remain the access to sd:\ and then sd:\boot in order to read olpc.fth. I have no explanation for why the external USB cables change the behaviour of your symptom. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 developer key does not work
On Sat, Mar 12, 2011 at 03:46:02PM +1100, Sridhar Dhanapalan wrote: There are three main questions raised by this process: [...] 3. why must I wait 24 hours to get the developer key? Presuming you are asking about an OLPC developer key rather than a deployment developer key ... the delay is to allow time for the laptop to be reported to OLPC as stolen. The delay only occurs on the first request for the serial number. Subsequent requests after the delay generate instant response. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 developer key does not work
Posting your machine's serial number as well as then contents of your develop.sig might help; your developer key might be malformed or correspond to a different XO than the one you are trying to use it on. You can also try the collection key method, as one more check on the process by which you are generating the developer key. --Scott On Friday, March 11, 2011, Sridhar Dhanapalan srid...@laptop.org.au wrote: I am trying to put a permanent developer key on an XO-1. I have been following the steps at http://wiki.laptop.org/go/Activation_and_developer_keys First, I created the key using devkey.html. Then I copied develop.sig to /security on the XO. After rebooting, I still see a wp tag in /ofw/mfg-data. Then I copied develop.sig to /security to a USB drive. Turning the XO on with the drive plugged in makes no difference. If I hold down the tick key while turning on, I get the messages: trying disk:\security\develop.sig Devel key No matching records ... Trying nand:\security\develop.sig Devel key No matching records I tried several FAT32-formatted USB drives, including one that I have used to upgrade to the latest signed firmware. Can anyone help out? Thanks, Sridhar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 developer key does not work
On 12 March 2011 05:10, C. Scott Ananian csc...@cscott.net wrote: Posting your machine's serial number as well as then contents of your develop.sig might help; your developer key might be malformed or correspond to a different XO than the one you are trying to use it on. You can also try the collection key method, as one more check on the process by which you are generating the developer key. This is a bit strange - I am getting a different result for each method. Printed in the battery compartment is the serial number SHC83102126 /home/.devkey.html contains: SN - SHC8320373E UUID - D5576981-BDA0-4271-ABFE-0183633847D1 /ofw/serial-number contains SHC832038CC laptops.dat (created with a collection key) contains: SHC832038CC C95B2B75-18A6-4860-B834-9AEAC7A4C47F 20110312T034351Z laptops.dat concurs with /ofw/serial-number. I've used the laptop.dat details to request a developer key. The page says that it'll be available in 24 hours. There are three main questions raised by this process: 1. why am I getting different readings for each method? 2. what is the most trustworthy method? 3. why must I wait 24 hours to get the developer key? Thanks, Sridhar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 DCON trouble with new kernels
On 13 November 2010 23:41, Daniel Drake d...@laptop.org wrote: Will study the LX docs and geode X driver for more clues. The X driver doesn't seem to do anything of relevance, but studying the docs leads me to conclude that the identified commit is wrong. Submitted a fix here: http://marc.info/?l=linux-fbdevm=128974396029942w=2 Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 DCON trouble with new kernels
The DCON does not see video memory directly - it works with the real-time display data that is driven onto the wires that would normally go to an LCD panel. I wonder if, in the VT case, the driver is stopping the display controller soon after clearing the DCONLOAD pin? In that case, I can imagine that the DCON would be unable to capture new data because it would no longer have PIXCLK, HYSNC, and VSYNC to time its acquisition of a frame of data. Naively, I would think that the loss of those timing signals might prevent the switched interrupt, but I can't think of any other possibility offhand, so check that. Maybe as a quick test you could add a 40 ms delay right after clearing DCONLOAD, thus ensuring that the display controller doesn't turn off until a couple of frame times have elapsed. On 11/13/2010 1:08 PM, Daniel Drake wrote: Hi, I'm hoping that someone can point me in the right direction, regarding how the DCON works. On new kernels, XO-1 DCON freeze doesn't work when you are on the virtual terminal. The current display does not seem to get loaded into the DCON memory, but then the freeze (video source switch) does happen. The DCON code has not changed between these kernel versions. It still works OK when you are in X. To illustrate more: 1. Boot up XO 2. Change to virtual terminal 3. echo 1 /sys/devices/platform/dcon/freeze You now see the image that OFW froze the screen with before booting Linux 4. echo 0 /sys/devices/platform/dcon/freeze Unfreeze works fine. 5. Go into X 6. echo 1 /sys/devices/platform/dcon/freeze Display freezes fine, with the X display contents 7. echo 0 /sys/devices/platform/dcon/freeze 8. Go to virtual terminal 9. echo 1 /sys/devices/platform/dcon/freeze Display freezes fine, with the X display contents that were frozen in step 6 I have examined the steps taken between the working (X) and non-working (VT) cases. They appear the same - after requesting the switch, an interrupt arrives, and status is read back as 2 at that time (switch to DCON mode complete). Any idea what could be the cause of this? For example, does the DCON only copy a certain region of video memory? Perhaps Linux VT is now using a different region. Or, any suggested diagnostics? Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 DCON trouble with new kernels
On 13 November 2010 23:30, Mitch Bradley w...@laptop.org wrote: I wonder if, in the VT case, the driver is stopping the display controller soon after clearing the DCONLOAD pin? In that case, I can imagine that the DCON would be unable to capture new data because it would no longer have PIXCLK, HYSNC, and VSYNC to time its acquisition of a frame of data. Thanks, will check. We also suspect it could be related to syncing. We identified that reverting this new commit solves the issue: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b5c26f97ec4a17c650055c83cfc1f2ee6d8818eb Will study the LX docs and geode X driver for more clues. Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: xo-1 os300 -- switch off mesh?
martin wrote: Hi all, Is there a way to tweak the os300 build so that it brings up the Libertas device just as eth0 (and doesn't enable the 802.11s features in the firmware)? echo 0 /sys/class/net/eth0/lbs_mesh as per http://wiki.laptop.org/go/Mesh_Network_Details#Disabling_the_mesh_network Not sure what it does exactly but the msh0 interface is gone and the wireless led does not randomly blink when in suspend mode (laptop closed). ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: xo-1 os300 -- switch off mesh?
Is there a way to tweak the os300 build so that it brings up the Libertas device just as eth0 I presume you are asking about installing a distribution which embodies that definition - I myself do not understand how to modify the build process. But if the question refers only to hacking an existing build for someone's use - my answer is 'yes': * File /etc/udev/rules.d/70-persistent-net.rules lists the names assigned to the device interfaces. [These names appear to be assigned in the order in which the respective devices were presented to the system -- I ran into this problem in 2008, with my no-wireless setup. Randomly a new build would initialize itself with my ethernet on eth0 (instead of on eth1) -- but there was code in the system which assumed the XO's radio HAD TO BE at eth0. Plus I found that if I had been using an external ethernet adapter with a particular XO, but then plugged in a different adapter -- that connection got assigned the next name (e.g., eth2). Nowadays I always check this file to verify name assignments - and manually edit names if they're not what my procedures expect.] * And names are merely parameters specifiable on whatever command causes that device interface to be created. For instance, 'wlan_' gets assigned by command 'iw interface add' (or equivalent). (and doesn't enable the 802.11s features in the firmware)? I'm not familiar with the various methods implemented in the software. But (for hacking an existing build) there might well exist a 'service' (reachable via DBUS) which disables the XO's 802.11s feature. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: xo-1 os300 -- switch off mesh?
On 12 July 2010 17:59, Martin Langhoff martin.langh...@gmail.com wrote: Hi all, Is there a way to tweak the os300 build so that it brings up the Libertas device just as eth0 (and doesn't enable the 802.11s features in the firmware)? Just curious, why? The usual NetworkManager methods (if any?) should work, google for network manager ignore device type thing. You could delete the hal fdi file that identifies the device as mesh (in which case it will come up as a regular wifi device). Not really sure how the mesh on/off thing works at the firmware level, there's no obvious way to turn it on or off. I guess it will always forward packets as it hears them etc. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: xo-1 os300 -- switch off mesh?
On Jul 12, 2010, at 11:03 PM, Martin Langhoff wrote: On Mon, Jul 12, 2010 at 10:42 PM, Paul Fox p...@laptop.org wrote: Is there a way to tweak the os300 build so that it brings up the Libertas device just as eth0 (and doesn't enable the 802.11s features in the firmware)? was there a way to do that in 802? Good question -- no there wasn't. But the f11 builds for xo-1 only did 802.11b/g for a long time. I have this silly assumption that there's a kmod to blacklist or a kmod option to set/change to completely disable the 802.11s support. As far as I know, there is NO way to completely disable mesh support on XO-1 without holding the WLAN card in reset. Even if you don't support it at the OS level, the firmware will still behave badly if it receives a mesh broadcast packet. IIRC, we settled for trying to ensure that no mesh packets were ever broadcast, but if one did get sent, everyone would still help relay it. wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: xo-1 os300 -- switch off mesh?
On Tue, Jul 13, 2010 at 10:22 AM, John Watlington w...@laptop.org wrote: As far as I know, there is NO way to completely disable mesh support on XO-1 without holding the WLAN card in reset. Boo. Ok. Even if you don't support it at the OS level, the firmware will still behave badly if it receives a mesh broadcast packet. Interesting. Given that we had mesh disabled on XO-1 kernel builds for quite a while, my understanding was that we were using a different driver (thinfirmware?) or that there was a way to disable 802.11s. The nasty bit is that even with an established 802.11b/g connection (infra or adhoc), it'll forward packets. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: xo-1 os300 -- switch off mesh?
On Tue, Jul 13, 2010 at 12:15 PM, Reuben K. Caron reu...@laptop.org wrote: Um, I think this should send a mesh stop command to the firmware. echo 0 /sys/class/net/eth1/lbs_mesh From: http://dev.laptop.org/ticket/5144 I like hearing from people who know stuff :-) Excellent, so adding that to an init-script that runs before NM starts up (ie: /etc/init.d/olpc-configure) would nuke msh0. The reason for this is testing -- there is a team testing throughput and reliability (and maybe dense environments) for the XO-1 hardware and they are interested in disabling the mesh forwarding to see if it changes things. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: xo-1 os300 -- switch off mesh?
martin wrote: Hi all, Is there a way to tweak the os300 build so that it brings up the Libertas device just as eth0 (and doesn't enable the 802.11s features in the firmware)? was there a way to do that in 802? paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: xo-1 os300 -- switch off mesh?
On Mon, Jul 12, 2010 at 10:42 PM, Paul Fox p...@laptop.org wrote: Is there a way to tweak the os300 build so that it brings up the Libertas device just as eth0 (and doesn't enable the 802.11s features in the firmware)? was there a way to do that in 802? Good question -- no there wasn't. But the f11 builds for xo-1 only did 802.11b/g for a long time. I have this silly assumption that there's a kmod to blacklist or a kmod option to set/change to completely disable the 802.11s support. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
