On Thu, Jun 30, 2005 at 12:22:11PM -0400, Robert G. Brown wrote: > And in the end, you will USUALLY save at most a relatively few seconds, > at the risk of actually taking longer. Serialized connections/downloads > are so much simpler and performance limitations are easy to understand > and work around. To begin, I want to say that I largely agree with the conclusion, although I may disagree on some fine points. THE DOWNSIDE: I think that, implemented well, parallel downloading would VERY VERY RARELY (I just removed "NEVER" because I'm me, but the fact that I typed in the first place should tell you something) significantly slow things down. Sure, there are extra cycles being spent, but usually when downloading, the network is the real bottleneck and not the processor/client code. I think the REAL downside is (a) that it's really not simple code to write given all of the other stuff urlgrabber does and does well. All the people in the world can tell me "it shouldn't be too hard", but (like most interesting problems) the devil is in the details, and trust me, there are plenty of details to go around. This complexity doesn't just mean PITA for the programmer (me), but it would also adversely affect the user by increasing the complexity of the program, adding bugs, and making those bugs harder to find. As Seth correctly recalled, reporting on parallel downloads is harder, and that means diagnosis is harder. THE UPSIDE I think the most common annoyance for people, and the event that drives most of them to say "hey, this should be parallelized" is when they have 50 packages queued for download and EVERYTHING halts for a single slow server. Now, in practice the difference between "low bandwidth server" and "high latency server" is pretty minor, but there's a big psychological difference. MY INTEREST Mostly, I'm interested in this problem for intellectual reasons. It's hard. That would be my primary drive. Also, it would "fill out" urlgrabber nicely. I agree that there would not be much benefit for most yum users. -Michael -- Michael D. Stenner mstenner@xxxxxxxxxxxxxxx ECE Department, the University of Arizona 520-626-1619 1230 E. Speedway Blvd., Tucson, AZ 85721-0104 ECE 524G
