Date: Fri, 9 Feb 2007 15:18:29 -0800 From: John-Mark Gurney <gurney_j@resnet.uoregon.edu> To: Sean Bryant <sean@cyberwang.net> Cc: freebsd-stable@freebsd.org, Dominic Marks <dom@helenmarks.co.uk> Subject: Re: dd as an imaging solution. Message-ID: <20070209231829.GJ1620@funkthat.com> In-Reply-To: <45CCC676.9070507@cyberwang.net> References: <45C52C3E.8040204@elgia.com> <20070205101806.b45f4118.dom@helenmarks.co.uk> <45C7EC5F.2030108@cyberwang.net> <45C81A5B.1010608@mawer.org> <20070207055131.GC1620@funkthat.com> <45CCC676.9070507@cyberwang.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Sean Bryant wrote this message on Fri, Feb 09, 2007 at 14:07 -0500: > John-Mark Gurney wrote: > >Antony Mawer wrote this message on Tue, Feb 06, 2007 at 17:04 +1100: > >>On 6/02/2007 1:47 PM, Sean Bryant wrote: > >>>Dominic Marks wrote: > >>>>Check out G4U (NetBSD based) > >>>The only problem I can see here is that multiple parallel reads will > >>>have serious performance impacts, thus greatly increasing the cloning of > >>>the disk. > >>> > >>>The solution with dd, tee and netcat would just daisy chain the copy > >>>across the network which would be way faster. > >>Now all you need is G4U to operate in a multicast manner like Symantec > >>Ghost Corporate Edition, and your transfer speed wouldn't reduce with > >>each additional client (eg. 100mbps for 1 client, 50mbps each for 2 > >>clients, 33.3mbps each for 3 clients, ...) > > > >Add FEC to the multicast, and you can constantly stream the data, and > >not have to worry about dropped segments as much... > > > Can you explain this? FEC stands for Forward Error Correction... Check out: http://info.iet.unipi.it/~luigi/fec.html for some work that Luigi has done wrt FEC. I've even embedded his FEC library in the kernel w/o too much difficulty... Wikipedia also has an article on it... So the idea is that you multicast out the data broken up into x packets.. In addition to x packets, you also transmit y "parity" packets... As long as the end system receives any combination of x and y packets where the total unique packet count is x, you are able to reconstruct the data... You choose y based upon your expected packet drop rate.. This has the advantage that when you are transmitting the data, and a machine fails to receive a packet, you don't have to a) retrainsmit the packet, or b) wait till the same data packet comes along... Because you can replace the missed data packet w/ one of the parity packets to reconstruct the data... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070209231829.GJ1620>