Re: MicroSD Card performance variance on XO-1.5
I am trying to determine whether it is worth us spending this additional $2-3USD. Has anyone tested what the practical difference is when using a C6 card over a C2? Being able to record at high-res is a good start. What about general speed and latency for normal use? I took a look at the SD and USB FLASH Drive Performance wiki page, but it isn't clear what the real difference is for classes. Thanks, Sridhar Sridhar Dhanapalan Technical Manager One Laptop per Child (OLPC) Australia p: +61 425 239 701 w: http://laptop.org.au On 6 August 2010 09:55, John Watlington w...@laptop.org wrote: Early prototypes are built using a wide range of SD cards: I believe we used at least six models in B/C test machines. While individual developers usually only have one or two, we do make sure that all SKUs are distributed to some software developers and testers. Both Quanta and the hardware team are careful to test across all prototype SKUs. When we had a QA department, they too were testing on all SKUs. We could place C2 cards in all prototype SKUs, but then Quanta would refuse to use C6 cards without further testing. I've said it before, and I'll say it again. If you want C6 cards, you will have to pay to get them. OLPCA pushes Quanta for the lowest price, and C2 cards are usually $2-$3 cheaper than C6. BTW, the REAL definition of C2 versus C6 is the resolution of video that can be streamed onto the card. So our higher resolution video encoding problems using C2 cards shouldn't be surprising... wad On Aug 5, 2010, at 2:54 PM, Martin Langhoff wrote: We recently saw that (at least some) XO-1.5 developer machines (C1, ramp units, etc) have SD cards that are significantly faster than what is being shipped to end users. This was a surprise to me (and probably to a few more of us) -- we assumed that most dev machines had a similarly spec'ed SD card to the shipping machines. AIUI, we intended to have an assortment of candidate SD cards on the ramp units, the units I've seen all have pretty fast cards :-) This probably explains the scattered results of testing Record audio/video sync -- with lots of 'works for me' vs definitely doesn't work. The slower SD cards are significantly slower. Deployments can request faster cards (at a cost), but I think it makes sense to test with the lowest common denominator. And we definitely need to understand what SD card is behind each works or doesn't report re Record and other write-intensive tasks. To aid clarity, Mitch has added a .speed test to OFW -- and we've timed a few cards with it: http://wiki.laptop.org/go/SD_and_USB_FLASH_Drive_Performance How to check your internal SD card brand model: http://wiki.laptop.org/go/XO_Debugging_tips 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 ___ 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: MicroSD Card performance variance on XO-1.5
Buy a C6 card and test it out! Applications load faster, boot time is reduced, any file I/O completes faster, and your pictures are more colorful! (Just kidding about the last one.) At the same time, outside of recording higher resolution video a laptop with a C2 card is fully functional. Cheers, wad On Aug 18, 2010, at 6:13 AM, Sridhar Dhanapalan wrote: I am trying to determine whether it is worth us spending this additional $2-3USD. Has anyone tested what the practical difference is when using a C6 card over a C2? Being able to record at high-res is a good start. What about general speed and latency for normal use? I took a look at the SD and USB FLASH Drive Performance wiki page, but it isn't clear what the real difference is for classes. Thanks, Sridhar Sridhar Dhanapalan Technical Manager One Laptop per Child (OLPC) Australia p: +61 425 239 701 w: http://laptop.org.au On 6 August 2010 09:55, John Watlington w...@laptop.org wrote: Early prototypes are built using a wide range of SD cards: I believe we used at least six models in B/C test machines. While individual developers usually only have one or two, we do make sure that all SKUs are distributed to some software developers and testers. Both Quanta and the hardware team are careful to test across all prototype SKUs. When we had a QA department, they too were testing on all SKUs. We could place C2 cards in all prototype SKUs, but then Quanta would refuse to use C6 cards without further testing. I've said it before, and I'll say it again. If you want C6 cards, you will have to pay to get them.OLPCA pushes Quanta for the lowest price, and C2 cards are usually $2-$3 cheaper than C6. BTW, the REAL definition of C2 versus C6 is the resolution of video that can be streamed onto the card. So our higher resolution video encoding problems using C2 cards shouldn't be surprising... wad On Aug 5, 2010, at 2:54 PM, Martin Langhoff wrote: We recently saw that (at least some) XO-1.5 developer machines (C1, ramp units, etc) have SD cards that are significantly faster than what is being shipped to end users. This was a surprise to me (and probably to a few more of us) -- we assumed that most dev machines had a similarly spec'ed SD card to the shipping machines. AIUI, we intended to have an assortment of candidate SD cards on the ramp units, the units I've seen all have pretty fast cards :-) This probably explains the scattered results of testing Record audio/video sync -- with lots of 'works for me' vs definitely doesn't work. The slower SD cards are significantly slower. Deployments can request faster cards (at a cost), but I think it makes sense to test with the lowest common denominator. And we definitely need to understand what SD card is behind each works or doesn't report re Record and other write-intensive tasks. To aid clarity, Mitch has added a .speed test to OFW -- and we've timed a few cards with it: http://wiki.laptop.org/go/SD_and_USB_FLASH_Drive_Performance How to check your internal SD card brand model: http://wiki.laptop.org/go/XO_Debugging_tips 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 ___ 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: MicroSD Card performance variance on XO-1.5
On Sat, Aug 7, 2010 at 02:52, Bernie Innocenti ber...@codewiz.org wrote: El Fri, 06-08-2010 a las 18:50 +0200, Tomeu Vizoso escribió: I also think our vm.dirty_* settings are wrong and likely causing our current fill-buffer-and-stutter behaviour. We are using the defaults and those are for spinning harddrives, with a significant cost to spinning up the disk on a laptop -- hence long expire_centisecs and writeback_centisecs and the assumption that once you've started writing, it'll be written out fast. We have zero seek costs, zero spin disk up costs, but slowish writes -- we have to start writing buffers out ASAP. I had also had the impression for some time that some knobs in the kernel could have been better tuned for the XO-1 and the actual workload. That was also my gut feeling. Swappiness also seems to be set too high. We should probably let the OOM killer kick in before the machine becomes totally unresponsive. Btw, have read that some notifications about available memory have landed in cgroups in recent kernels. The Sugar shell could listen to those and give a chance to background activities to save their state before killing them, thus avoiding OOM in some (most?) cases. Regards, Tomeu Tuning the VM knobs is no joke. We could proceed by applying some reasonable changes early in the next development cycle, then sit back and wait for users to tell us their overall impression of using the system as usual. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: MicroSD Card performance variance on XO-1.5
[cc += sugar-devel, tch] El Sat, 07-08-2010 a las 11:27 +0200, Tomeu Vizoso escribió: Btw, have read that some notifications about available memory have landed in cgroups in recent kernels. The Sugar shell could listen to those and give a chance to background activities to save their state before killing them, thus avoiding OOM in some (most?) cases. We could do this even without an advanced reporting mechanism. The monitoring code in the CPU Memory meter could detect memory shortage and automatically quit the least recently used activity. Or, maybe, we could make this a manual process: pop up a notification when memory is short and ask which activity should be closed. A while ago, Tincho has been working on implementing the Freedesktop notification protocol in Sugar. This feature didn't make it for Dextrose, but perhaps it could be completed in time to be merged into 0.90. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: MicroSD Card performance variance on XO-1.5
On Sat, Aug 7, 2010 at 18:11, Bernie Innocenti ber...@codewiz.org wrote: [cc += sugar-devel, tch] El Sat, 07-08-2010 a las 11:27 +0200, Tomeu Vizoso escribió: Btw, have read that some notifications about available memory have landed in cgroups in recent kernels. The Sugar shell could listen to those and give a chance to background activities to save their state before killing them, thus avoiding OOM in some (most?) cases. We could do this even without an advanced reporting mechanism. The monitoring code in the CPU Memory meter could detect memory shortage and automatically quit the least recently used activity. So we would have a periodic wakeup? The test would be the amount of free memory plus buffers and caches? Or, maybe, we could make this a manual process: pop up a notification when memory is short and ask which activity should be closed. I would just close one of the background activities, the LRU or the biggest one. Regards, Tomeu A while ago, Tincho has been working on implementing the Freedesktop notification protocol in Sugar. This feature didn't make it for Dextrose, but perhaps it could be completed in time to be merged into 0.90. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: MicroSD Card performance variance on XO-1.5
On 08/05/2010 07:55 PM, John Watlington wrote: BTW, the REAL definition of C2 versus C6 is the resolution of video that can be streamed onto the card. So our higher resolution video encoding problems using C2 cards shouldn't be surprising... Whats the qualifications on that? I assume its raw RGB video? -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: MicroSD Card performance variance on XO-1.5
On Fri, Aug 6, 2010 at 12:30 PM, Richard A. Smith rich...@laptop.org wrote: Whats the qualifications on that? I assume its raw RGB video? No, it's compressed vid + uncompressed audio to be stitched later. I have a confession to make: Many years ago I worked in video mixing with mid-range gear (avid and media100, I *don't* miss you) and with cheapskates PC-based rigs (which where hell on wheels compared to avid and media100). My take is that our CPU is perfectly capable of capturing and compressing vid and audio and putting it down to disk, even on a 2MB/s-capable disk, helped a bit by (limited) linux kernel buffering. Most importantly, we need to capture audio + vid together, or at least timestamp them together. Otherwise drift is inevitable. I also think our vm.dirty_* settings are wrong and likely causing our current fill-buffer-and-stutter behaviour. We are using the defaults and those are for spinning harddrives, with a significant cost to spinning up the disk on a laptop -- hence long expire_centisecs and writeback_centisecs and the assumption that once you've started writing, it'll be written out fast. We have zero seek costs, zero spin disk up costs, but slowish writes -- we have to start writing buffers out ASAP. But that's my (naive?) take. I haven't delved into the gstreamer madness. 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: MicroSD Card performance variance on XO-1.5
On Fri, Aug 6, 2010 at 18:43, Martin Langhoff martin.langh...@gmail.com wrote: On Fri, Aug 6, 2010 at 12:30 PM, Richard A. Smith rich...@laptop.org wrote: Whats the qualifications on that? I assume its raw RGB video? No, it's compressed vid + uncompressed audio to be stitched later. I have a confession to make: Many years ago I worked in video mixing with mid-range gear (avid and media100, I *don't* miss you) and with cheapskates PC-based rigs (which where hell on wheels compared to avid and media100). My take is that our CPU is perfectly capable of capturing and compressing vid and audio and putting it down to disk, even on a 2MB/s-capable disk, helped a bit by (limited) linux kernel buffering. Most importantly, we need to capture audio + vid together, or at least timestamp them together. Otherwise drift is inevitable. I also think our vm.dirty_* settings are wrong and likely causing our current fill-buffer-and-stutter behaviour. We are using the defaults and those are for spinning harddrives, with a significant cost to spinning up the disk on a laptop -- hence long expire_centisecs and writeback_centisecs and the assumption that once you've started writing, it'll be written out fast. We have zero seek costs, zero spin disk up costs, but slowish writes -- we have to start writing buffers out ASAP. I had also had the impression for some time that some knobs in the kernel could have been better tuned for the XO-1 and the actual workload. Regards, Tomeu But that's my (naive?) take. I haven't delved into the gstreamer madness. 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: MicroSD Card performance variance on XO-1.5
El Fri, 06-08-2010 a las 18:50 +0200, Tomeu Vizoso escribió: I also think our vm.dirty_* settings are wrong and likely causing our current fill-buffer-and-stutter behaviour. We are using the defaults and those are for spinning harddrives, with a significant cost to spinning up the disk on a laptop -- hence long expire_centisecs and writeback_centisecs and the assumption that once you've started writing, it'll be written out fast. We have zero seek costs, zero spin disk up costs, but slowish writes -- we have to start writing buffers out ASAP. I had also had the impression for some time that some knobs in the kernel could have been better tuned for the XO-1 and the actual workload. That was also my gut feeling. Swappiness also seems to be set too high. We should probably let the OOM killer kick in before the machine becomes totally unresponsive. Tuning the VM knobs is no joke. We could proceed by applying some reasonable changes early in the next development cycle, then sit back and wait for users to tell us their overall impression of using the system as usual. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: MicroSD Card performance variance on XO-1.5
Hi, This probably explains the scattered results of testing Record audio/video sync -- with lots of 'works for me' vs definitely doesn't work. The slower SD cards are significantly slower. It did explain some of the first Record problems, but then we switched to recording into /tmp (on tmpfs) to isolate that variable. (There were still further problems, so SD speed isn't a sole explanation.) - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: MicroSD Card performance variance on XO-1.5
Early prototypes are built using a wide range of SD cards: I believe we used at least six models in B/C test machines. While individual developers usually only have one or two, we do make sure that all SKUs are distributed to some software developers and testers. Both Quanta and the hardware team are careful to test across all prototype SKUs. When we had a QA department, they too were testing on all SKUs. We could place C2 cards in all prototype SKUs, but then Quanta would refuse to use C6 cards without further testing. I've said it before, and I'll say it again. If you want C6 cards, you will have to pay to get them.OLPCA pushes Quanta for the lowest price, and C2 cards are usually $2-$3 cheaper than C6. BTW, the REAL definition of C2 versus C6 is the resolution of video that can be streamed onto the card. So our higher resolution video encoding problems using C2 cards shouldn't be surprising... wad On Aug 5, 2010, at 2:54 PM, Martin Langhoff wrote: We recently saw that (at least some) XO-1.5 developer machines (C1, ramp units, etc) have SD cards that are significantly faster than what is being shipped to end users. This was a surprise to me (and probably to a few more of us) -- we assumed that most dev machines had a similarly spec'ed SD card to the shipping machines. AIUI, we intended to have an assortment of candidate SD cards on the ramp units, the units I've seen all have pretty fast cards :-) This probably explains the scattered results of testing Record audio/video sync -- with lots of 'works for me' vs definitely doesn't work. The slower SD cards are significantly slower. Deployments can request faster cards (at a cost), but I think it makes sense to test with the lowest common denominator. And we definitely need to understand what SD card is behind each works or doesn't report re Record and other write-intensive tasks. To aid clarity, Mitch has added a .speed test to OFW -- and we've timed a few cards with it: http://wiki.laptop.org/go/SD_and_USB_FLASH_Drive_Performance How to check your internal SD card brand model: http://wiki.laptop.org/go/XO_Debugging_tips 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: MicroSD Card performance variance on XO-1.5
On Thu, Aug 05, 2010 at 07:55:11PM -0400, John Watlington wrote: BTW, the REAL definition of C2 versus C6 is the resolution of video that can be streamed onto the card. So our higher resolution video encoding problems using C2 cards shouldn't be surprising... Agreed, it may have some bearing. os850, Record of video is streaming to the SD card. (If it were only going to /tmp I'd have disagreed.) I'll release note it. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: MicroSD Card performance variance on XO-1.5
we definitely need to understand what SD card is behind each works or doesn't report re Record and other write-intensive tasks. Results from motherboard-unmodified B2 XO-1.5 (SHC9370111D): [I bought these SD cards myself; both are 8G, labeled class 6] int:0 Mfg 0x1b OEM 0x534d Micro SD Read: 16.5 Write: 8.3 ext:0 Mfg 0x27 OEM 0x5048 Ext slot Read: 14.9 Write: 4.8 Note: when I ran the OFW command multiple times, the numbers reported for the internal card became lower and lower for each repeat. [Testing Record-86 on os850 on this machine, I was satisfied with how the result looked, when recording a video clip in 'High' quality.] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
