Gnutella Forums - hashing speed

Gnutella Forums (https://www.gnutellaforums.com/)

- New Feature Requests (https://www.gnutellaforums.com/new-feature-requests/)

- - hashing speed (https://www.gnutellaforums.com/new-feature-requests/16543-hashing-speed.html)

>I too would like to see a process indicator at the end of downloads. Sometimes it just seems to hang and that kind of worries me because I don't know if it's locked up untill it finishs. I would also like LimeWire to warn me if I try to close it whale it's hashing because I've done it at least once and you lose the download if you do that.

i believe the newest version of limewire has two extra download statuses ... instead of sitting at 100% progress and downloading from 0 hosts, it will first say "Verifying File Contents" (and the progress bar will rise from 0 - 100) and then "Saving File". the first is for while it is hashing the file, the second is for when it is either moving or copying the file from the incomplete to the saved directory.

this lets you know when downloads are hashing.

More to my tastes would be to allow the user to choose, as one option defiantly won't fit everyone.

In my case, I'm running LimeWire on a machine that sits between my LAN and the internet (proxy server), and that's basically all it does. I'm sharing 40+ GB of data, and whenever it has to hash a file (median size is 160MB), it takes a long time... Longer than I would like. Worse, I've noticed that if the file is in the middle of the share directory structure, it will seems to stop searches from finding files further down in the directory structure (RedHat 7.3).

I wouldn't mind being able to flip a toggle, or slide a slider between 33% and 100%. I'd even go so far as to suggest 33-50% highlights in black, 50-75% in green and 76-100% in red.

What the Guy above me posted is a very good idea,Ares has already implemented it,I have a pic atteched at the bottom:)

Simple is always best

The more choices you give the user, the steeper the appearance of the learning curve and the greater the need for proper documentation to explain the whole system. I favour leaving this aspect alone. Hashing is often quite slow because I rarely have Limewire standing alone but once you learn not to mess with it once it has started, I just get on with other things until it has finished. I don't think this aspect is broke enough to need fixing.

IMO the background hashing works good enough in the current version (2.9.8). It shows you "1/200 Files Shared" when it starts the hashing, and the Library view shows unhashed (hence unshared) files in red.

I notice the slow down after limewire hashes 500 + files. I just want more memory management for this enviroment. I would like to share 2500 - 5000 files easily but I really can't at this point.

Re: Simple is always best

Quote:

Originally posted by LeeWare
but Personally, I think that the hashing feature is fine in its current implementation. I do agree however that there should be some type of progress indicator-indicating the file that is currently being hashed and its percentage of completion. Perhaps there should be a message indicating that files are being prepared for sharing. I have a particularly useful recommendation for CPU utilization and file-hashing:

1. Set to default hashing to 50% of the CPU utilization.
2. Create an option in the configurations menu that allows a person to change-on-the-fly the speed in which the hashing is done.

The first option allows you to satisfy the users who are happy with the current implementation and "Out of the box" configuration would support this implementation.

The second option, would give users such as myself the ability to allocate 100% of my CPU utilization to hashing. because I run several servants and the files can range in size from 1 MB to 400 MB in size and these files are stored on a network file server-- hashing can take hours.

Hope this helps.

I Agree With LeeWare And Believe there Should be options to change the hashing priority rather that a pre-defined rate.
But As David Said

Quote:

Originally posted by David91
The more choices you give the user, the steeper the appearance of the learning curve and the greater the need for proper documentation to explain the whole system. I favour leaving this aspect alone. Hashing is often quite slow because I rarely have Limewire standing alone but once you learn not to mess with it once it has started, I just get on with other things until it has finished. I don't think this aspect is broke enough to need fixing.

It Could Confuse the users, So how about This :
1. The hashing priority is selected as the way it currently is. But you can select the hash priority to be higher and a short description about the priorty you selected would appear So people can make a informed decision

How about having LimeWire detect whether someone's computer has been idle for a while (5 to 10 minutes) and base the hashing speed on that? When the computer is actively in use by the user, slowdown the hashing speed so the user wouldn't notice a major slowdown when using other apps on their machine, but when the computer has been idle for 5 to 10 minutes, ramp up the hashing speed to full speed. When the user comes back and starts using their computer again, slow the hashing speed down again so it wouldn't affect the performance of other programs running.

Some Good Ideas Regarding Hashing

Actually, I think the previous posters idea is a pretty good one. there's a simple way to implement exactly what he's talking about. You could use a methodology commonly used in the distributed computing whereas the application uses the computers idle cycles to do it's hashing. obviously, you have to post a message at the beginning of hashing to indicate to the user that the hashing process is using the idle CPU cycles. otherwise, most users will freak out when they see their CPU pegged at 100%. On second thought, they'll freak out anyway if they don't understand what it means to use the idle cycles to do the hashing.

Finally, I think the current implementation is just fine.