#2743 HIGH Product: In manufacturing, multicast download of images is highly desirable.

[Zarro Boogs per Child]

#2743: In manufacturing, multicast download of images is highly desirable.
----------------------------------+-----------------------------------------
  Reporter:  jg                   |       Owner:  dwmw2           
      Type:  defect               |      Status:  new             
  Priority:  high                 |   Milestone:  Production Start
 Component:  ofw - open firmware  |     Version:                  
Resolution:                       |    Keywords:                  
  Verified:  0                    |  
----------------------------------+-----------------------------------------
Comment (by dwmw2):

 Current implementation.... 2820-byte packets (47 per 128KiB eraseblock).
 50% redundancy added by FEC to make 70 packets. The client is happy when
 it's received any 47 (unique) packets out of the sequence belonging to
 that eraseblock.

 The server multicasts these packets in round-robin mode at a little under
 24Mb/s, sending one packet from each eraseblock in turn. This means that
 burst losses tend to have their effects spread between multiple blocks.

 The clients receive these packets with roughly 5-10% loss, at an effective
 rate of about 1700KiB/s. Raw incoming packets for each eraseblock are
 written directly to that eraseblock as they arrive, with metadata (i.e.
 which packet numbers we have and in which order) kept in RAM.

 The clients listen until they have the required 47 packets for every
 eraseblock. This takes around 140 seconds for the 224MiB os542.img. Then
 they process each eraseblock in turn, reading the raw data, feeding it to
 the FEC decode routine, erasing the block and writing the decoded data
 back again. The naïve implementation under Linux does these operations
 sequentially, but in fact the flash access could be happening in parallel
 to the FEC decoding.

 Again for the 224MiB os542.img, a client typically spends about 65s in the
 fec_decode() routine, and roughly 60s on flash access (13 on reading, 4 on
 erasing, 35 on writing). And 7s checking the crc32 on each block.

 Assuming we can 'hide' the flash access times by interleaving that
 appropriately with the CPU-bound tasks, that gives a total of about 3½
 minutes for downloading and installing a typical image.

 More improvements could be made by streaming the data in a different
 sequence which means that the blocks don't all reach their 47-packet
 target at precisely the same time, so some of the time spent waiting for
 incoming packets could be used for fec_decode(). It's useful to spread out
 the packets across different eraseblocks to amortize the effect of burst
 loss, but we don't necessarily need to spread them out like this across
 _all_ eraseblocks. We could perhaps 'favour' one block at a time by
 sending a sequence like A B C D A E F G A H I J A...

-- 
Ticket URL: <https://dev.laptop.org/ticket/2743#comment:7>
One Laptop Per Child <http://laptop.org/>