Forgot your password?
Close
typodupeerror
The Internet

Journal turg's Journal: The next killer app: backwards downloading. 21

Journal by turg

I came up with this idea while watching a file download yesterday. As I don't have the technical expertise to implement it myself, I present the idea here in the hope that someone can use it to benefit all net users.

As I watched that progress metre draw near to 100%, I reflected on how the last 10% of a download takes about as much time as the first 30-50% does -- and the last 1% of the file can take as much time as the first 25% or more. I assume that it is not possible to speed up this part of the download, as the same problem has persisted since the BBS systems of the 1980's, despite all the technical advances in the intervening time.

But I have an idea that can greatly improve the experience of network users: download the file in reverse order -- so the slowly-downloading part comes first. While this obviously won't change the total time it takes to download, it can make a big psychological difference for the user, as the download will finish more quickly than they might have expected initially (rather than more slowly).

I am committing this invention to the public domain for the good of humanity.

This discussion has been archived. No new comments can be posted.

The next killer app: backwards downloading. More

The next killer app: backwards downloading.

Comments Filter:
  • That's my big question, FTP, HTTP, what?

    Bit torrent doesn't have the problem you mention, it downloads the segments in random order, and because you download tit-for-tat with upload, it tends to speed up as you go along and connect to more users.

  • Moo (Score:2)

    by Chacham ( 981 ) *
    The slowenss has not to do with the file, but witht he time connected, and the data put out.

    What you are suggesting, has been implemented before as "slow start". It is an algorythm in which all connections get a slow connection at first, and those that are sustained for a certain period of time get a faster connection, until what they can handle. This helps the server in many ways. The simplest, is to get rid of those that can handle the quick downloads first, to reduce overall stress on the system.
  • I have noticed that since IE downloads your file to a temp location and then copies it to your requested location that it starts the download in the background while you fumble with the interface to tell it where to stick the file when done. This often provides the illusion that the beginning of a file goes faster than the ending. This also screws with the reported download speed since the metering doesn't start until you click "ok" yet there's already a large chunk of the file, so the meter thinks you go
    • By the same token, this quirk of Internet Exploder will cause the progress meter to be further thrown off kilter for larger files, since the file you've requested is completely on your hard drive (drive C:\, of course) at 99 percent. The last portion is completed as the file is copied from \temp\crap\ to your requested location.

      Also, this lovely IE "feature" guarantees that you will never be able to download a full-sized ISO file if your C:\ partition/drive only has 200 MB free.

      "No DISK SPACE?!?!?! Th

      • I would guess this idea is probabley portable to windows:

        Find the $TMP environment variable and set it to another drive is you do not have space on your "c" drive. My bet would be that IE stores the temporary file there.

        Mozilla does a similar thing though. I would guess it probably writes the temp file to the cache dir or the $TMP dir that it is using. I have had lynx usually write to /tmp though, which is a real pain.

  • Mouse movement hack. (Score:3, Interesting)

    by rdewald ( 229443 ) * <rdewald&gmail,com> on Sunday September 21, 2003 @11:03PM (#7021708) Homepage Journal
    Much like inching your car forward will make a traffic light change faster, or looking longingly down the subway tracks will make the train come faster, I've found that circling the dialog box with my mouse cursor makes downloads go faster.

    I hereby release this to the pubic domain.

    I have noted the effect you describe while using windows, but I do not notice it in *nix. I always assumed it was just another stupid bit of programming in windows. Some check of the file contents continuing that ends up taking longer as the file gets bigger on the receiving end.

    Back in the BBS days (I was Fidonet 1:382/70), this effect was particularly pronounced as I picked up mail traffic over long distance lines. The last 5% of the transfer would take half the time. But then again, that was probabaly Opus.
    • If you can actually make something go faster by staring it at it or other odd tricks and you can document that scientifically, please let me know. You and I will take a trip to the horse racing track and we're gonna make a TON of money. ;)

      • If you can actually make something go faster by staring it at it or other odd tricks and you can document that scientifically, please let me know. You and I will take a trip to the horse racing track and we're gonna make a TON of money. ;)

        Apparently, something similar is actually true, at least of Windows 3.1: moving the mouse improved performance slightly. (Simply due to a dumb mouse driver, which ate slightly more CPU whenever the mouse was stationary - so unless your horse runs Win 3.1, it won't help

    • BTW--I was FidoNet 1:120/284, later moved to 1:2410/284 in the last few months I ran the board.

      I don't know about Opus, but FroDo seemed to not want to write the file to disk until it got to its buffer size, which we'll call n and everytime it would write n-sized chunks to the disk it would slow down. This would slow things down because back then the processor on my whopping 12-mhz 286 could sometimes barely keep up with the 16450A-based UART chip driving my serial port.

      • Well, you may or may not know there was a lot of clamor at that time around the issue of whether or not OPUS would support being run with just 640k of RAM. Many sysops, myself included, were running it with old MB architecture that didn't support more RAM. We would have had to upgrade the box hardware (which was not so easy or cheap back in 1988) to support a release that would require more RAM, and this was running counter to the "BBS-Free or Die" implied social contract for the Opus community.

        So the pr
        • Mine went down officially in March of 1992. It was still going strong then, but I figured bring it down BEFORE it got old and stale and nobody cared anymore...go out with a BANG. Ya know?

          I was using a Unix shell account as well, but I got Newsgroups via a FTN => UUCP gateway. We were lucky enough to have one of those in our Net back in those days.

    • I've found that circling the dialog box with my mouse cursor makes downloads go faster.

      Hehehe, while that may be true, for even faster downloads nothing beats the "lead the progress bar w\ your mouse pointer" trick! Think of the fine olympic sport "curling", same effect!

    • Hmm. Your examples might be useful for EU's idea (see below) for a water-boiler-accelerator for watched pots. (If watching can hasten the arrival of the train, we just need to filter out the boil-delaying effect and amplify the train-quickening effect)
  • :)

    The time taken to download any particular chunk of stuff is randomly affected by lots of things. Downloading it in reverse order would just have the funky effect of downloading in reverse order.

    Although, there is one case I can think of where you might get faster downloads for the start of large files, not the ends... sadly it'd not help you at all. That is, if your ISP is caching downloads, and the files have been partially cached before. Yeah, loading in reverse would actually make it worse at firs

  • Uhr? (Score:1)

    by Sloppy ( 14984 ) *
    As I watched that progress metre draw near to 100%, I reflected on how the last 10% of a download takes about as much time as the first 30-50% does -- and the last 1% of the file can take as much time as the first 25% or more.
    I've never observed anything like that. What are you talking about? Is this some specific protocol or app?
  • ...the Water-Boiler-Accelerator. Thus, a watched pot will boil faster. (Patent pending.)

    Cheers,

    Ethelred

    • By faster do you mean faster than a watched pot otherwise boils or even faster than an unwatched pot? The former should not be difficult to achieve -- you could come up with some goggles that filter out whatever it is about watching that slows down the boiling process.
    • easy to do.

      Get some infrared lamps and attach them to a headset so that they shine directly on whatever the wearer is facing.

      Put the water on to boil and turn on the lamps. The water that gets watched by the wearer of this technical innovation will boil demonstrably faster. It's not just a good idea, it's the law [nasa.gov].

      I hereby release this into the public domain.

      Sorry.
      • Get some infrared lamps and attach them to a headset so that they shine directly on whatever the wearer is facing.

        Mmmm, why am I compelled to think of sharks with frickin' lasers on their heads?

        Cheers,

        Ethelred

Slashdot Top Deals

"Love is a snowmobile racing across the tundra and then suddenly it flips over, pinning you underneath. At night, the ice weasels come." --Matt Groening

Close