Segmented downloading : Why the big deal?

Site Announcements
arnetheduck
Newbie
Posts: 8
Joined: 17 Mar 2009, 13:37

Re: Segmented downloading : Why the big deal?

Post by arnetheduck » 03 Jan 2011, 20:08

Ah, misunderstanding then, I was suggesting doing a separate benchmark app in any language (in the end, they all hit the os), not actually modifying dc++...

Quicksilver
Member
Posts: 56
Joined: 17 Aug 2009, 21:32

Re: Segmented downloading : Why the big deal?

Post by Quicksilver » 07 Jan 2011, 07:53

I would have not choosen a different program.

Especially as I am still not sure how this all interacts with the cache on the hdd.
I don't know if we could properly map the behaviour of DC++ to a simple program.

Flow84
Newbie
Posts: 6
Joined: 18 Oct 2008, 11:05

Re: Segmented downloading : Why the big deal?

Post by Flow84 » 07 Jan 2011, 18:10

arnetheduck wrote:Ah, misunderstanding then, I was suggesting doing a separate benchmark app in any language (in the end, they all hit the os), not actually modifying dc++...
I have developed a test app.
Please test and give me feedback.
It is writen in C# and should give you accurate speeds and so.

http://files.flowertwig.org/FlowerBench.7z

/Flow84

Quicksilver
Member
Posts: 56
Joined: 17 Aug 2009, 21:32

Re: Segmented downloading : Why the big deal?

Post by Quicksilver » 09 Jan 2011, 16:26

What does the program do? Its not selfexploratory!

Flow84
Newbie
Posts: 6
Joined: 18 Oct 2008, 11:05

Re: Segmented downloading : Why the big deal?

Post by Flow84 » 23 Jan 2011, 02:01

Quicksilver wrote:What does the program do? Its not selfexploratory!
Sorry for late answer.
This forum doesn't send out notifications...

It basically tries to read/write data to/from disk and show speed.
You can set buffer size, access type and more.

If I understand this thread right, it is what you wanted.
You can see speed impact depending on buffer size and more :)

Big Muscle
Junior Member
Posts: 39
Joined: 01 Jul 2008, 19:27

Re: Segmented downloading : Why the big deal?

Post by Big Muscle » 24 Jan 2011, 15:00

I reimplemented shared file stream into StrongDC++ : http://strongdc.svn.sf.net/viewvc/stron ... te#dirlist

However, one question comes to my mind. Shared file stream fixes the problem when file handle is destroyed at the end of each segment and new one is created at the beginning of next segment. But now it needs locking critical section for each read/write to ensure that changing file position and file operations are atomic. Now the question - doesn't such critical section bring more overhead than separate file handles?

Locked