Re: updatinator benchmarking (Was: rsync benchmarking)
On Wed, 2007-07-11 at 23:47 +1000, [EMAIL PROTECTED] wrote: > Alexander, > > I should mention that doing better than rsync with a custom solution > is not unexpected. rsync tries to be fairly general purpose, and > special purpose delta tools can almost always do better, as they can > take advantage of more information about the data. Well, what we're more concerned about is spreading around the load of updates, both from a network traffic perspective and a server-utilization perspective than any type of "beating" of rsync. More of a peer-to-peer model using standard protocols like HTTP. Nothing against rsync, it's quite appropriate for a centrally-managed system with fairly reliable network connections, but that's not the problem that updatinator is actually attempting to solve... different approaches to the same problem really. Dan > At least rsync provides a harder target to beat than scp or ftp would, > so its useful in that way :-) > > One thing to watch is round trips. Large numbers of http GET requests > means lots of round trips. rsync uses very few round trips, so it > tends to do well on high latency links. > > Cheers, Tridge > ___ > 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: Can't load image 466 on my B1 machine
Ivan, > On Jul 11, 2007, at 5:37 PM, Yoshiki Ohshima wrote: > > It seems that (by looking at Received-by: headers) some emails (to > > @laptop.org?) was disrupted intermittently. > > Stuck in the moderation queue which has to be manually flushed. Ah, ok. I saw one of such emails was Eben's (from June 2nd) so I thought it was less likely, but thank you for clearing it out. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Can't load image 466 on my B1 machine
On Jul 11, 2007, at 5:37 PM, Yoshiki Ohshima wrote: > It seems that (by looking at Received-by: headers) some emails (to > @laptop.org?) was disrupted intermittently. Stuck in the moderation queue which has to be manually flushed. -- Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Can't load image 466 on my B1 machine
Hi, Jim, > You need to download and add a .crc file found with the build. I don't > remember what build those got added in. > > Why, specifically, are you loading 466, rather than 496, if I may ask? Notice the date of original email. Around that time, 466 was the "latest ok version" to play with Etoys. It seems that (by looking at Received-by: headers) some emails (to @laptop.org?) was disrupted intermittently. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Unwanted RPM dependencies
On 7/11/07, Bernardo Innocenti <[EMAIL PROTECTED]> wrote: > C. Scott Ananian wrote: > If the image contains modules and we want to allow kernel > updates through rpm, then we need to ship this fork of > mkinitrd with the system. Kernel updates aren't through rpm. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Unwanted RPM dependencies
C. Scott Ananian wrote: > We do/will have an initrd which is used for activation, but it does > not use mkinitrd and certainly doesn't require its binary to be on the > XO. If the image contains modules and we want to allow kernel updates through rpm, then we need to ship this fork of mkinitrd with the system. I've not yet figured out whether rpm and yum are only meant for us developers or also for the end users. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Early boot, activation, upgrades
On Jul 11, 2007, at 3:50 PM, Mitch Bradley wrote: > It wasn't obvious how to coerce the code to do 256-bit truncated > Whirlpool, so I don't have a number for that. Whirlpool doesn't matter for the general boot case anyway. Looks like if we go with SHA-256 and ECC-256 we can do the verification in about 0.6 seconds, which is fine by me. -- Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Early boot, activation, upgrades
More benchmarks for bios_crypto on LX: Whirlpool: 1.16 sec / MiB SHA512: 0.42 sec / MiB SHA256: 0.28 sec / MiB <<--- New result (SHA256 is 1.5x the speed of SHA512) RSA verification: 0.025 sec / hash ECC521 verification: 1.13 sec / hash ECC256 verification: 0.31 sec / hash <<--- New result (ECC256 is 3.5x the speed of ECC521) It wasn't obvious how to coerce the code to do 256-bit truncated Whirlpool, so I don't have a number for that. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Test Group release notes
Just a reminder to developers and testers working off the latest builds for Trial-2. When we get a new build, we add information to the 'Test Group Release Notes' on the wiki: http://wiki.laptop.org/go/Test_Group_Release_Notes I have also added a link to these release notes on the standard Software Release Notes page, so you can search for 'release notes' and you should be able to get this link. It will probably save you some time when you ready to upgrade your machine to check that page and see what kind of problems are already known. Please feel free to update that page as well with things that you have found if you are one of the early ones to try out a new build. Thanks, Kim ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Early boot, activation, upgrades
On Jul 11, 2007, at 1:25 AM, Jonathan Herzog wrote: > Now that I've looked through the code for LTC SHA-512, I'm pretty > sure that I can examine LTC SHA-256 in a day or two. Is there an > imminent deadline I should know about? I don't want to change the crypto going in the Trial-2 firmware at this point so there isn't an imminent 2-day deadline, but if we're changing the primitives, I'd like to get it done very soon. To provide context: the bios-crypto was originally going to be solely used to ascertain integrity of BIOS updates, but we're now planning to use it for kernel integrity verification as well (which happens on every boot), and it's too slow for that. To accommodate both use cases without adding primitives to the library, I proposed going from the current state (Whirlpool, SHA-512, ECC-521, RSA-2048) to 256-bit truncated Whirlpool, SHA-256, ECC-256, and RSA-2048 (no change there). I'm perfectly comfortable with this not meaningfully reducing the overall security of the BIOS update verification, while letting us use just SHA-256 and ECC-256 to do kernel integrity verification, which should prove substantially faster (benchmark is pending). > As for the 256-bit curve: yes, it will trigger unaudited code > paths, but that's because I haven't yet audited every function used > by the ECC package. ECC uses a lot of math, for example, and I > haven't yet looked at each mathematical function yet. However, I > can say that the 256-bit curve defined in LTC matches the NIST > recommendation, and that the unaudited code paths triggered by that > curve will be in the underlying math functions, not LTC itself. Right. The math functions are in your queue to be audited, correct? Cheers, -- Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: updatinator benchmarking (Was: rsync benchmarking)
On Wed, 2007-07-11 at 23:47 +1000, [EMAIL PROTECTED] wrote: > One thing to watch is round trips. Large numbers of http GET requests > means lots of round trips. rsync uses very few round trips, so it > tends to do well on high latency links. > To pick a nit: HTTP/1.1 supports pipelining, and you can use it in a relatively efficient manner (once you get beyond the fact a typical request is > 120 bytes on the wire), avoiding tons of round trips. But most of the random HTTP libraries are not written well enough to support pipelining, so what you say is in practice true much more often than not. (says this happy to be former HTTP/1.1 specification editor :-)). - Jim -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Can't load image 466 on my B1 machine
Ted, You need to download and add a .crc file found with the build. I don't remember what build those got added in. Why, specifically, are you loading 466, rather than 496, if I may ask? - Jim On Fri, 2007-06-29 at 06:54 -0700, Ted Kaehler wrote: > Folks, > I am trying to upgrade a B1 XO using a Mac and a memory > stick. I successfully upgraded to C11 and 435. > When I tried the same thing with C17 and 466, I have a > problem. It installed C17 firmware just fine. > Then it says > > Updating OS image on NAND FLASH from build 435 to build 466 > > Evaluating: copy-nand [... a path etc] > Can't open CRC file > > I tried typing > copy-nand disk:\boot\nand466.img > it says > fe > ok > > What does "Can't open CRC file" indicate? > How can I get 466 onto the machine? > Thanks! > Please reply to me privately, since I am not on the devel list. > > --Ted. > -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #31 BLOC Trial-2: OHM Power Manager for OLPC laptops
X itself will take care of dealing with the dcon.
All Ohm has to do is ensure the right screen saver parameters get set.
- Jim
On Wed, 2007-07-11 at 14:55 +, Zarro Boogs per Child wrote:
> #31: OHM Power Manager for OLPC laptops
> -+--
> Reporter: jg | Owner: [EMAIL PROTECTED]
> Type: task| Status: new
> Priority: blocker | Milestone: Trial-2
> Component: infrastructure | Version:
> Resolution: |Keywords: power
> Verified: 0 |
> -+--
> Comment (by cjb):
>
> Hi Richard,
>
> Replying to [comment:23 [EMAIL PROTECTED]:
> > > * power button support -- we should suspend whenever the power button
> is pressed
> >
> > I'll do this today. I guess it's exposed in HAL as a button of type
> power.
>
> (See below about us probably needing a kernel change here.)
>
> > > * lid event -- we should suspend *and* set the dcon to "sleep" mode
> via sysfs on lid close
> >
> > How to set dcon to sleep and suspend? What's the _exact_ commands on a
> B3?
>
> DCON sleep is:
> {{{
> echo 1 > /sys/devices/platform/dcon # sleep
> echo 0 > /sys/devices/platform/dcon # wake
> }}}
>
> And, CPU suspend is the usual:
> {{{
> echo mem > /sys/power/state
> }}}
>
> > > * ebook event -- we should `xrandr -o left` on ebook=1, `xrandr -o
> normal` on ebook=0
> >
> > What is the ebook event - a HAL button press or dbus api?
>
> Lid and ebook are already being broadcast by HAL as the appropriate
> signals: if you install the latest build and close/open lid and
> flip/unflip into ebook, lshal --monitor gives:
>
> {{{
> -bash-3.2# lshal --monitor
>
> Start monitoring devicelist:
> -
> 14:56:51.815: computer_logicaldev_input_0 property button.state.value =
> true
> 14:56:51.822: computer_logicaldev_input_0 condition ButtonPressed = lid
> 14:56:52.389: computer_logicaldev_input_0 property button.state.value =
> false
> 14:56:52.397: computer_logicaldev_input_0 condition ButtonPressed = lid
> 14:56:56.328: computer_logicaldev_input_1 property button.state.value =
> true
> 14:56:56.429: computer_logicaldev_input_1 condition ButtonPressed =
> tablet_mode
> 14:56:57.370: computer_logicaldev_input_1 property button.state.value =
> false
> 14:56:57.377: computer_logicaldev_input_1 condition ButtonPressed =
> tablet_mode
> }}}
>
> > Can we do the xranr stuff in c bindings rather than run a command - it
> would be much faster.
>
> That sounds fine, though I don't have sample code for doing it with the
> bindings, and would be happy with getting the exec going now and
> optimizing it later given our time constraints. Whichever you prefer.
>
> > > HAL doesn't currently see/broadcast the power button -- maybe that's
> because X uses the grab ioctl on the pm_inputdev device, which would mean
> we need to split out the power button into its own (correctly labeled)
> device like we did with lid and ebook. That's a simple kernel patch; if
> we need to do that, I can get it done quickly.
> >
> > Yup, it needs to be a separate device, ala ACPI.
>
> Yeah, makes sense. I'll get a kernel RPM with the extra device for the
> lid switch ready for when you get in tomorrow.
>
> > I'll make this stuff priority one this morning.
>
> You rock. :) Thanks so much!
>
--
Jim Gettys
One Laptop Per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: updatinator benchmarking (Was: rsync benchmarking)
On Wed, 2007-07-11 at 23:47 +1000, [EMAIL PROTECTED] wrote: > Alexander, > > I should mention that doing better than rsync with a custom solution > is not unexpected. rsync tries to be fairly general purpose, and > special purpose delta tools can almost always do better, as they can > take advantage of more information about the data. Yeah, I didn't expect that rsync would be better. It clearly doesn't have enought data to do that. Don't take this work as a complaint about rsync. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: updatinator benchmarking (Was: rsync benchmarking)
Alexander, I should mention that doing better than rsync with a custom solution is not unexpected. rsync tries to be fairly general purpose, and special purpose delta tools can almost always do better, as they can take advantage of more information about the data. At least rsync provides a harder target to beat than scp or ftp would, so its useful in that way :-) One thing to watch is round trips. Large numbers of http GET requests means lots of round trips. rsync uses very few round trips, so it tends to do well on high latency links. Cheers, Tridge ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Unwanted RPM dependencies
On 6/4/07, David Zeuthen <[EMAIL PROTECTED]> wrote: > On Mon, 2007-06-04 at 03:37 -0400, Bernardo Innocenti wrote: > > - mkinitrd depends on lvm2 and dmraid. Both could easily > >be made optional. > You most probably don't need mkinitrd on OLPC as the kernel got all the > drivers built-in and IIRC OLPC don't even use the initrd (when I was > working on it, it didn't). So you could have some OLPC specific package > that provides mkinitrd and symlinks /sbin/mkinitrd -> /bin/true or > something. We do/will have an initrd which is used for activation, but it does not use mkinitrd and certainly doesn't require its binary to be on the XO. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: updatinator benchmarking (Was: rsync benchmarking)
On Tue, 2007-07-10 at 16:21 +0200, Alexander Larsson wrote: > > 464-to-465: > > Full contents of tree: 429,302,610 bytes > > rsync --whole-file: sent 32,034 bytes; received 13,153,813 bytes. > > Standard rsync: sent 96,720 bytes; received 10,047,524 bytes. 9.0s > > user, 64.9s real > > Rsync-with-manifest: sent 79,192 bytes; received 9,139,515 bytes. 4.3 > > user, 11.5s real. > > Updatinator: > sent 596,681 bytes > recieved 7,545,281 bytes So, i took a deeper look into what all the sent bytes are from by using a network sniffer, transfering from a local http server. Using wireshark I got slightly different (likely more accurate) bytecounts for just the download. sent: 421,134 bytes received: 7,974,280 bytes About the same download size, but slightly different sent count. Probably because I only counted the actual transfer and not other things happening on the machine. However, its still pretty large. So, what kind of data are we sending? We're doing 357 http GET requests, at about an average request packet size of 245.613 bytes, totalling 87,684 bytes. The rest of the data sent is tcp control flow packets (ACK, SYN, FIN etc), totalling at 333,450 bytes. We send so many of these packets (66 byte each) because we're recieving a lot of data to ack. Actually the http request size above includes the packet headers etc, so the numer of bytes sent at the application level (the tcp payload) is only 64,122 bytes. I believe the numbers above for rsync is just the tcp payload data, so updatinator is actually at about the same size for sent bytes. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Early boot, activation, upgrades
Timings for OFW access to JFFS2 files in NAND FLASH: First access (scanning NAND to create memory index of nodes): 7 seconds Subsequent accesses: 0.5 seconds fixed + 0.5 sec / MiB (approximately) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
